在用户端，除了使用代理服务器伪装外，有没有简单的方法避免“云减速”而直走 Cloudflare

[passerbytiny]

前情： /t/602329
搜索引擎准备： 打开网站就是“安全检测 | 百度云加速”，怎么办？

使用代理服务器绕路就能直走 Cloudflare，算是一种解决方案。然而 UWP 走代理需要 Fiddler+Proxifier+常规代理，开启麻烦不说，Fiddler 还只能开全局。路由器代理又好难配置（知道这玩意 4 年了，还折腾了 2 个路由器，缺一直没开始配置）。

像尝试 hosts，然而 ping 了一下 trakt.tv ，其 IP 是 Cloudflare 的，推测“中国发起的访问分配给云减速”是 Cloudflare 那一边做的，hosts 估计没用。

有啥解决方法吗？

我想寻求的是用户端（宽带接入端）的自主解决办法。

最本源的解决方案当然是让Cloudflare取消与“云减速”的合作，然而这个方案的可行性是零，就算没有云减速，某宽带本身都会对Cloudflare做减速。

让 trakt.tv creativecommons.org 这些网站运营方换掉Cloudflare，显然可行性也是零。

有些内容有些跑题，我没有回复，请见谅。

最终没有找到不使用代理服务器的方法，但找到了更简单的使用代理服务器的方法。详见我最后的回复。结帖。

[MonoLogueChi]

uwp 代理不需要那么麻烦啊，只要装 fidder 设置一下就可以用全局代理了，甚至你都可以直接用 cmd 命令，不需要装 fidder。

[passerbytiny]

@MonoLogueChi #1 一，全局代理不能常用的。二，fidder 设置一下是使用 fidder 本身做全局的 http/https 代理，是纯本地代理，要达到绕路的效果还得 Proxifier+常规代理。fidder 的 socks 上游配置有问题，用不了。

[MonoLogueChi]

@passerbytiny 按理说 http 代理就足够了，只要你的出口在国外，并且用远程 DNS，应该就可以啊

[Cipool]

其实 cloudflare 针对中国 IP 展示百度云加速的验证页面，是为了避免中国用户因为无法访问 recaptcha 而完全无法通过安全验证，是出于便利中国用户的做法。

[z919126592]

用 cname 不要用 a 接入

[passerbytiny]

@MonoLogueChi #3 HTTP 代理是肯定不能用在出口上的，我试试能不能搞本地 HTTP 代理给 fidder 做上游。

@z919126592 #5 这好像只能由服务端控制，用户端控制不了。

[mnihyc]

@Cipool 百度云**检测方式垃圾，界面还很丑，叫我选择肯定不会选。还有 recaptcha 在大陆地区明明能用啊，www.recaptcha.net 是干什么的。反正 bdlj 就对了

[mattx]

换个 不要用 Cloudflare 的

[just1]

你这个本来就是非正常访问啊，拦截又没做错，不喜欢没问题，因这个问题骂他就很摸不着头脑了。

[Yourshell]

是你的访问环境有问题，就算不走百度云的人机验证也会有 CF 的人机验证。

[Cipool]

@mnihyc 但是 cloudflare 的验证页面直接用的 www.google.com 的 API，这也是官方文档一般推荐使用的

[passerbytiny]

找了了一下午，貌似给路由器开一个 V2Ray 还是很简单的，难得是在路由上。

我想能不能在路由器上弄个简单的梯子，只对少数特定域名（ trakt.tv ）或特定 IP （ dig trakt.tv 得到的 IP 是 Cloudflare 的固定的两个：104.20.81.229 和 104.20.82.229 ）走梯子。就是不知道 Iptables 能否实现这效果。懂 Iptables 的人能否看下下面这规则能否有效，其中 12345 端口由 V2Ray 提供支持：
iptables -t nat -A PREROUTING -p tcp -d 104.20.81.229 -j REDIRECT --to-ports 12345
iptables -t nat -A PREROUTING -p tcp -d 104.20.82.229 -j REDIRECT --to-ports 12345

[mytsing520]

你用百度云加速的页面和 CloudFlare 本身产生的验证页面没有什么两样。
百度云加速核心部件依然是 CloudFlare

实在不知道你的是什么奇怪的需求

[azh7138m]

hosts 修改解析到 cf 的域名到你想要的节点就行

[passerbytiny]

@azh7138m #12 怎么查节点。ping、dig 得到的结果不管海内外，都是 104.20.81.229 和 104.20.82.229 ，这俩肯定不是节点。

[azh7138m]

@passerbytiny 你要知道一个 cf 其他地区的 CDN ip，比如美西的，假如是，2.3.3.3，直接 hosts 把 trakt.tv 走 CDN 的域名全部解析到 2.3.3.3 就行了

咱是觉得这么可以，没有真实测试过，我平时在家是只有白名单是直连，其他走 出去的
直接改 hosts，蹭香港直连是可以的（

[titanium98118]

感觉 4 楼是正解

[wwbfred]

这种减速其实是 CF 根据 IP 之类的东西自己做的,访问者没办法改变.
你可以把这类域名当作被墙了,直接加到透明代理里走境外.

[passerbytiny]

@azh7138m #14 改 hosts 方式试了下，不行。https://bgp.he.net/AS13335#_prefixes 找了几个 IP，那么没用，要么 trakt.tv 直接无法访问。根据 https://bgp.he.net/dns/trakt.tv 的结果，trakt.tv 的 DNS 结果是固定的 104.20.82.229 104.20.81.229 ，而这两个 IP 是美国节点。通过 hosts 修改成这两个 IP 或它临近的 IP，都会被转向云减速，而修改成远一点的 IP，则找不到服务器。推测这是 Cloudflare 在 IP 层做的转发，域名、dns 或 hosts 影响不到。

[passerbytiny]

经过十几天努力，终于将路由器配置成了透明代理——虽然只能针对固定配置出来的 IP 地址做代理，将 trakt.tv creativecommons.org 的四个 IP 配置上之之后，电脑端不管是浏览器还是 UWP app 都能正常访问这两个网站了。（理论上，因为 Cloudflare 的 IP 地址是连续的，可以把 Cloudflare 的 IP 地址掩码配置上去，从而彻底远离百毒云减速，不过没试。）

该解决方法仍然用到了代理服务器，不过至少首次配置完成后，后续使用的时候简单了。

虽然努力了十几天，但绝大部分时间都是再搞路由器（完全重刷了两次），代理程序的安装只用了一天，网关转发规则花了一天时间去找方案，但配置起来就只是在防火墙自定义规则中加了这么几句：

ipset -X extend_ips
ipset create extend_ips hash:net
for ip in $(cat /root/gateway_extend_ips.txt);
do ipset add extend_ips $ip;
done
iptables -t nat -A PREROUTING -p tcp -m set --match-set extend_ips dst -j REDIRECT --to-port 56789

我没有顺便把***list 自动**给配置上，那个虽然找到了方法，但是预测没个 5 天的奋斗，是配置不起来的。

可惜的是，手机还用不了。这逼走的是 ipv6 的通道，上面配置的透明代理不起作用。经过 ip6tables 多次尝试，我的路由器的 ipv6 模式下，网关都不是路由器，手机直接以 ipv6 地址接入公网了。

[passerbytiny]

更正，ipv6 下路由器仍然是网关，只不过不是 NAT 网关。ⅰpⅴ6 网络的网关也配出来了：
ip -f inet6 rule add fwmark 1 table 100
ip -f inet6 route add local ::/0 dev lo table 100
ip6tables -t mangle -I PREROUTING -p tcp -m set --match-set extend_ips_v6 dst -j TPROXY --on-port 98765 --tproxy-mark 0x01/0x01

路由器需额外安装 iptables-mod-tproxy，代理程序需要额外开一个 tproxy 模式的端口