续费的话，如果没有什么活动优惠，那么 Cloudflare 是最便宜的，毕竟是按批发价卖的，一分钱也没加。
注册的话，便宜的好像挺多的，建议注册后如果打算续费就转到 Cloudflare ~

这些都是扫描出来的。

都是一些个人搭建的 Cloudflare CDN 反代 /端口转发，因为没做限制导致被扫描出来并公开了。

因此这些 IP 都无法保证稳定性，用的多了，迟早会被搭建者发现，到时候搭建者无论是直接将其关闭还是加上限制，都意味着失效。

@cue 楼主写的是 200Mbp/S ，虽然单位格式上有点问题（ ps=/s=每秒，因此这个 / 多余了），但指的是 200Mbps 即常说的 200 兆宽带，毕竟如果是 200MB/s 、470MB/s 的话，楼主就没必要发帖了。。。

很早就恢复了。
jsdelivr 是我见到的唯一一个，被 DNS 污染，然后过一段时间恢复了，然后过一段时间又被 DNS 污染，又恢复，来来回回重复了 3 次，才一直恢复正常到现在，没有再反复了。。。

另一个被污染后很快恢复的，还有上个月开会前，谷歌的一些国内可使用的域名被 DNS 污染（很多原本都是指向谷歌国内服务器的），不过好像第二天还是第三天就恢复了，这个应该只是单纯的失误。

@Takizawa .com 无法访问时，浏览器报错内容是什么？

@googlefans 你理解错了，/ncr 是用来解决访问 .com 被重定向至 .hk 的问题用的。。。
而楼主的意思是 .hk 能正常访问，但是 .com 的不能访问。


楼主，你说的 “经常不能访问” 到底是一直完全不行？还是偶尔时不时的不行？
确定走代理了吗。

Cloudflare 自己用上这个了么？我好像见过动图里这种，不过往往还需要再来一次 hCaptcha 验证。。。

如果这个分叉的位置移动能更自由点就好了，目前我试了试，一些分叉离得太近（就像向左躺着的 h 一样），感觉很别扭，如果可以拖动节点调整位置（间隙）就更好了（不用多么精细）。

另外，如果开 DMZ （指定为某设备的内网 IP ），那就相当于把所有端口都映射到局域网内的某个设备上了，访问 "公网 IP:任意端口" 都会访问到该设备上的服务。

公网 IP 不是分配到你的宽带上的么？。。。它是你的网络出口呀。。。

路由器端口映射指向某个设备的内网 IP ，这样通过 "公网 IP:端口" 就能访问到该设备上的服务了。

@A01514035 感谢分享，不过我觉得单纯的 黑名单 或 白名单 都存在维护麻烦的问题，所以我目前用的是基于 IP 的国内外分流，即我前面说的那样，判断域名解析 IP 是不是国内的，如果是就直连，反之走代理~

因为我个人需求较复杂，所以我用的是 SwitchyOmega 自定义规则 + GFWList + PAC 复合方案（一般人不需要这样）。可以省略了我前面说的 2 、3 甚至 1 步骤，直接在 系统 / 浏览器 的代理设置中配置 PAC 地址。
或者在 SwitchyOmega 中添加 PAC 情景模式来使用 PAC 规则。

@Eagleyes
@Macolor21
我做了个简单的思维导图，看起来比较直观 https://s1.ax1x.com/2022/11/16/zVotnP.png

左半边的是只使用 PAC 规则判断的（省略了我前面说的 2 、3 甚至 1 步骤），右半边是我个人在用的 SwitchyOmega 自定义规则 + GFWList + PAC 复合方案（我个人需求较复杂，一般人不需要这样）。

其中，
左上角的是，直接在 系统 /浏览器 的代理设置中配置 PAC 地址。
左下角的是，在 SwitchyOmega 中添加 PAC 情景模式来使用 PAC 规则。
右边的则是，SwitchyOmega 自动切换模式 自定义规则 + GFWList 规则 + PAC 规则

反正上线这么久了，除了最开始时被夸过（当时还没有那么多限制，毕竟国内速度会快很多，而且还有免费的国内 pages ），后续不是因为这个原因被吐槽，就是因为那个原因被吐槽~

怪就怪它生错了地方吧~

@Eagleyes 你去那个 PAC 里看吧，我不太懂这个，反正判断效率挺高的，平均不到 0.02ms 。

@Macolor21 我个人需求比较复杂，因为一些原因 /需求我必须要使用 SwitchyOmega ，所以看起来 “略显复杂”，但其实很简单，而且不用 SwitchyOmega 的话，直接 系统 /浏览器 的代理设置为 PAC 即可。
而且就像我前面说的，第 3 、4 步骤也是可以省略的，直接 SwitchyOmega 里添加一个 PAC 情景模式用也行。

每个人有每个人的需求，适合自己的才是最好的~

@XIU2 #93 刚刚测试了下，PAC 规则匹配（即排除国内常见域名 + 判断 IP 是国内还是国外）整个过程耗时 X ms ，而这其中，绝大部分时间都是等待 DNS 解析请求，真正 JS 代码判断只有平均不到 0.04 ms
而 SwitchyOmega 中的 自定义 规则很少，也是依靠 JS 判断，所以估计也是 0.0X ms 级别的。

至于 GFWList 规则足足有 8000+ 条，这个我没有做测试，估计它可能是除了 DNS 解析请求时间外的最大耗时环节了，可以考虑省略，不过想想也就顶多 X ms ，影响不大，完全感知不到。。。

所以，简单总结，上面这 3 、4 步骤，可要可不要，对性能、速度影响不大~

@XIU2 #42 刚刚给测试了下，PAC 规则匹配（即排除国内常见域名 + 判断 IP 是国内还是国外）整个过程耗时 几 ms ，而这其中，绝大部分时间都是等待 DNS 解析请求，真正 JS 代码判断只用平均不到 0.04 ms
而 SwitchyOmega 中的 自定义 规则很少，也是依靠 JS 判断，所以估计也是 0.0X ms 级别的。

至于 GFWList 规则足足有 8000+ 条，这个我没有做测试，估计它可能是除了 DNS 解析请求时间外的最大耗时环节了，可以考虑省略，不过想想也就顶多 几 ms ，影响不大，完全感知不到。。。

所以，简单总结，这 3 、4 步骤，可要可不要，影响不大~

我当初用了好多年很便宜的薄膜键盘，导致习惯后练就了 大力金刚指。

后来打算买个机械键盘，考虑到我的 大力金刚指，于是选了个黑轴，结果刚开始用起来感觉好 “轻”，感觉没用力就按下去了。。。不过时间长了又习惯了~

目前唯一感觉不舒服的地方就是空格键太轻，我有时候大拇指放上去一不小心就压下去了，搞得我玩 CSGO 的那段时间，老是静步走着走着就跳了一下，特别尴尬。。。

“我有两个域名都通过 cloudflare 的 DNS 解析到服务器的同一 IP”
“我这个网站的日活流量等于 A 域名和 B 域名相加的结果吗？”

你是一个网站绑定了这两个域名吗？
也就是通过这两个域名，访问的是同一个网站？

如果是的话，那你的网站流量就是这两组数据相加。

@followztx #39 你截图给的这个方案，就是我以前用的方案，GFWList 匹配到的走代理，其他的直连。而我想要的是国外域名走代理，国内域名直连~

我昨晚折腾了下，把隔壁帖子别人分享的 PAC 设置为 SwitchyOmega 的情景模式，来实现 “绕过大陆”。
https://v2ex.com/t/895078#r_12341968
https://gist.github.com/weijarz/a76641504c97f0c3e48e207ec4df7db5
我看这个 PAC 文件里还内置了一些国内常见域名白名单、被墙常见域名黑名单，所以我就自己改了改，最后折腾完的结果是（ SwitchyOmega 自动切换模式 + GFWList + PAC ）：

1. 访问一个网站
2. SwitchyOmega 自动切换模式开始依次匹配
3. 先是从 自定义 规则匹配（把我最常访问的域名设置为 走代理 /直连）
4. 然后从 GFWList 规则匹配（这些都是确定被墙的网站，直接走代理即可）
5. 最后从 PAC 规则匹配（解析为 IP ，判断 IP 是国内就直连，是国外就走代理）

PAC 规则里我只保留了部分国内常见域名白名单判断，被墙常见域名黑名单判断由 GFWList 代替。

不过，我刚才测试了下，将一个国内网站配置为 直连 或 走完上面全流程，加载时间也就增加了 10ms ，最多也就 几十 ms 罢了，感觉提前用自定义规则、GFWList 规则指定其走代理 /直连似乎不是很有必要。当然，这样做也可以避免老是 DNS 解析一些常见被污染的域名，因此如果要省略这两个，则建议搭配 DOH 加密 DNS 。

我多用一段时间，看看还有什么需要完善优化，或有什么我没考虑到的~