现在回看,不该花那个冤枉钱去弄什么 IP 更换服务,不过没有这一步,也不会彻底放弃治疗转而去研究 IP 被墙之后还能做什么。
套个 CDN 可以挽救 IP 被封造成节点无法使用之问题。副作用当然不少,延迟上直接翻好几倍,稳定性直接拉跨,当然也没那么夸张,总之被强能挽救回来已经不错。套的域名是在用的二级域名,导致访问主域名个人网站时显示重定向次数过多,这个算是猜测,不过虽然有诸多不便,可是架不住那种失而复得柳暗花明之心情,就是那种被强行控制束缚之后可以变向挣脱之快感,妙不可言。过程:域名是在别家购买和管理,需要把域名 NS 值修改成 CF 提供之内容,等待 CF 提示成功后,添加一条 A 记录,也就是二级域名,在 IP 位置填入被墙 IP 地址,解析成功后,通过 X–UI 后台添加入站,使用 VLESS 协议,选择 80 端口,设置 WS 传输模式,填写 /a 路径,其余选项不动。回到客户端,在导入节点信息后,把地址、伪装、SNI 三处位置修改为解析域名,选择 443 端口,到此结束。注意:遇到下面这种 XRAY 无法运行之错误代码,需要降级版本为 1.8.0 以下。Failed to start: main: failed to load config files: [bin/config.json] > infra/conf: VLESS clients: "flow" doesn't support "xtls-rprx-direct" in this version还遇到下面这种另外一个无法运行之错误代码,则需要在 XRAY 配置文件里面入站选段监听修改为 0.0.0.0 地址。Failed to start: app/proxyman/inbound: failed to listen TCP on 端口第二个应该和 VPS 厂家提供的系统本身有关,其他 VPS 未遇到此类错误。在使用过程中,开始可能需要多断开重连几次,连接以后还算稳定。不过通过二级代理解锁 ChatGTP 只能搞定移动端,网页端不行,猜测由于不再是 SS 协议,关闭浏览器选项对 WS 传输类型无效,这一点也没必要继续纠结。另外一台临期 HK 只能通过 SS 客户端使用很奇怪,可能是姿势不对,也不再纠结。鸣谢:主要参考以下网络教程,特此鸣谢!NameSilo配置Cloudflare域名解析教程 新手如何如何拯救VPS IP 被墙
兼顾 IP 挽救与 CDN 重定向解决。之前有提及,套的域名是在用的二级域名,导致访问主域名个人网站时会显示重定向次数过多,当时是猜测,经过搜索得知,是确实需要配置一下才能解决,进入 Cloudflare 把 SSL/TLS 加密模式从默认的“灵活”修改为“完全”即可,正常到这里就可以解决问题,不过由于被封 IP 挽救要用到“灵活”模式,在“完全”模式下无法挽救节点,这就造成鱼与熊掌不可兼得的尴尬处境。网上搜索一番,未得到解决办法,最后查看 Cloudflare SSL/TLS 具体配置规则,通过创建一个二级域名的规则,等于这个域名的时候,自动设置 SSL/TLS 模式为“灵活”。经测试,完美兼得熊掌与鱼。
测试利用 CDN 解决 VPS 节点不通。问题:突然发现无论是移动还是联通,今天某个节点都无法使用,反反复复折腾 SS 和 X-UI 好几次,最终不得不接受现实,通过 PING 得知无响应,最多偶尔有一点儿响应,但是 PING 值很高,这种局面,基本无法使用节点,那么是否可以参考被封 IP 挽救的策略加以解决,相当于今天这台 VPS 网络延迟太离谱,出现网络动荡,把它等同于被墙之状态,因为假如今天网络不行,谁也不能预料以后还会不会出现类似情形。测试:通过测试,新加入一个入站节点,就套用 IP 被封那个完整的套路,当然要把新的二级域名加入到之前提到的 SSL 规则里面,以便于能够实现“灵活”响应。结果印证了猜测,完全可以使用新的入站节点,也完全可以畅游世界。总结:那么之前的入站节点必须得保留,因为如果网络畅通的时候,当然要用那个没套 CDN 之节点,才能最大化网络速度,那么,当网络不行的时候,这个套上 CDN 之新节点就完全可以派上用场。顶多延迟多一些,但起码可以使用,而且连接速度也没亏多少。何况旧节点还肩负着分流 ChatGPT 之重任,况且新节点是共用旧节点之 XRAY 配置,虽然使用新入站节点还要用到 Youtube 和 Netflix 的情况基本也不可能出现。毕竟主机节点不是这个。
借助 CDN 解决节点不通(续)。不行:没过几个小时,此方法不可用,套上 CDN 也不能访问节点,尝试添加新域名,然并卵,反而发现 Cloudflare 对同一主域名及时二级域名的代理都是相同的 IP 地址,也就是说添加再多同一顶级域名的二级域名也没用,到了晚上,直连节点反倒是恢复如初,一切就像是没发生过。总结:看来,之前总结的当网络不稳定时采用 CDN 节点的思路,并不可行。当网络真正延迟非常离谱时,其本质上比 IP 被墙问题更加严重,比如那个被墙的 HK IP 就是个很好的例子,如果没有被墙,直连那个 HK 速度非常快而且很稳定,所以套上 CDN 就可以仅仅牺牲掉一点延迟,就可以正常访问节点,但是这个延迟离谱无法连接上的 IP 就不同,墙与不墙没有区别,也就是说,套 CDN 的方案,仅仅适用于本身延迟不太高且直连速度还可以的 IP 节点,并不适用于本身体质就不稳定且网络经常不可达的 IP 节点。
文章评论