某多，2060s 九百多，而 5700xt 才 七百多，性能比 6600xt （差不多一千）还高那么一点点。
不过 5700xt 发布时间太长，因此挖矿时间也长，更容易翻车。。。

目前矿卡性价比最高的还是 580 8G ，才一百多，虽然矿的更严重，矿渣中的矿渣~

@nii 我也是，我当初 700 元买了个 580 矿卡，用了 2 年，去年矿潮我就给咸鱼 3200 元卖给矿工了，基本上是最高价了，后续很快就来了一波小矿难。。。
相当于白票 2 年还净赚 2500 。。。真是理财神器，印象深刻~

不过现在虽然 580 不到 200 元，但都不知道是几手的矿渣，风险太大，我也就没啥兴趣了~

对 CPU 要求高吗，还是说只是单纯的速度快慢的区别？~

@kingpo 这肯定的呀，不都是这样吗。。。

续费的话，如果没有什么活动优惠，那么 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 步骤，可要可不要，对性能、速度影响不大~