事情的起因，其实有点玄学。
最近我总刷到一些关于 ChatGPT 降智的讨论。其中一种说法是，节点的 IP 不干净，会让 GPT 的表现变差。
我本来就天天用 ChatGPT 和 Codex，写代码、学东西、做项目，基本离不开它们。看到这种说法，很难完全不在意。
正好前两天，我还拿网页端和 Codex 跑了一下鹈鹕骑自行车测试。提示词就是那句：
创建一个 HTML，内容是 SVG 绘制一个鹈鹕骑自行车的 2D 动画。
HTML 描述网页结构，SVG 则可以直接用代码描述线条和形状。我想看的就是，模型能不能只靠代码，把一只骑自行车的鹈鹕画出来，再让它动起来。
下面是当时留下的两个结果。第一张来自 Codex，第二张来自 ChatGPT 网页端。
Codex GPT-6 Astra High
ChatGPT 网页端 GPT-6 Pro
我当时的直观感受是，网页端那版更对我的胃口。造型、细节和整个页面的完成度，都让我觉得差异挺明显。
不过，两边的模型、运行环境和工具使用方式都不完全一样，我也没有只改变 IP 重复测试。输出有差异，不代表差异就是 IP 造成的。
至于原来的代理，我一直用的是 OuO，130 元一年，每月 100 GB。日常速度其实没什么问题，日本节点的延迟也不高。
只是它终究是多人共用的出口。我又看了一圈节点检测，越看越觉得心里不踏实。
于是我寻思，既然 AI 已经是我每天都在用的工具，那就给它单独弄一个固定、独享、低风险的出口。贵一点可以，别再让我惦记这个了。
我以为买一个新代理，这件事就结束了。
最后从电脑折腾到手机，连代理链都搭出来了。
先买个独享 IP，总该简单一点吧
开始的时候，我对网络代理真没多少系统认识。平时就是导入订阅、选个节点、打开开关。节点下面那个数字越小，看起来就越舒服。
但真准备花钱买一个干净 IP 的时候，我才发现，商品页上那些词根本不是一回事。
独享说的是，这个出口是不是和别的代理客户共用。静态说的是，地址会不会变化。住宅 / ISP说的是网络来源或归属。至于访问快不快、稳不稳，又是另一件事。
ISP 是 Internet Service Provider，也就是互联网服务提供商。Dedicated ISP Proxy 可以先理解成独享的 ISP 来源代理。Decodo 对静态住宅 / ISP 代理的介绍里，也把运营商来源和服务器托管结合在了一起；它并不等于某个家庭专门把光猫留给我用。
拆到最后，我的诉求其实就四个字：干净、稳定。 再具体一点，就是出口固定、尽量只有我自己用，而且能正常工作。
最后选了 Decodo 的三 IP 独享月付档，两个日本、一个美国。日本作为日常主力和备用，美国留给以后确实需要美区出口的场景。
购买 IP 时的分配页面。
拿到以后，我又挨个查了 Scamalytics、AbuseIPDB 和 IPinfo。IPQualityScore 要注册，我就没继续折腾。
查询当时，三个 IP 的 Scamalytics 风险分数都是 0，AbuseIPDB 也都是 0 次报告。美国那个显示为 Comcast 的 ISP 网络；两个日本出口则被一些数据库识别为 Hosting，也就是服务器托管类网络。
我一开始还纠结，日本出口怎么被识别成了服务器托管网络。后来想了想，我要的也不是一张看起来很漂亮的检测报告。只要独享、固定、实际能稳定用，标签没必要追得那么死。
这些毕竟只是第三方检测结果。没有举报记录，不等于从来没被滥用，也不代表 OpenAI 一定接受这个出口。
买完以后，后台给了我三个代理入口。同一个域名，配合不同端口，对应分配给我的三个出口。我又用实际请求确认了一遍，最后给它们起了名字：
| 名称 | 代理入口 | 用途 |
|---|---|---|
| Decodo JP Main | isp.decodo.com:10003 |
日本主力 |
| Decodo JP Backup | isp.decodo.com:10002 |
日本备用 |
| Decodo US | isp.decodo.com:10001 |
美国备用 |
入口地址和最终出口 IP 是两回事。 客户端连接的是 Decodo 的入口；目标网站看到的，是请求从 Decodo 出去时使用的地址。
到这一步，我觉得事情已经完成一半了。
结果真正麻烦的部分才刚开始。
IP 检测挺漂亮，想用的网站却打不开
我先把三个节点写进 FlClash，类型用的是 HTTP 代理。
仪表盘能查到日本出口，节点有时也能测出延迟。我就去开 Google、YouTube、ChatGPT。
然后页面开始转圈。
Google 打不开，YouTube 打不开。ChatGPT 一开始好像还能用，过一会儿也不行了。我只能重新切回 OuO，继续问 ChatGPT 这是怎么回事。
这就有点尴尬了。
我买新代理，是为了更稳定地用 AI。现在连排查新代理，都得靠旧代理才能进行。
为了不把问题全推给客户端，我开始用 curl 测。curl 是一个命令行网络请求工具，可以明确指定代理、目标网址，再把响应或者错误打印出来。
我在 Windows PowerShell 里用 curl.exe 明确指定代理和目标。下面用占位符替代了真实用户名；只提供用户名时，curl 会再提示输入密码，不必把密码写进命令历史。
1 | curl.exe -I --proxy "http://isp.decodo.com:10003" --proxy-user "YOUR_USERNAME" "https://www.google.com/" |
结果还是那句：
1 | curl: (56) Recv failure: Connection was reset |
两个日本端口不行，换美国端口也一样。
偏偏 Decodo 自己的检测接口又能返回结果。
我的第一反应就是：难道这个产品只支持检测自己，不支持正常上网？
代理还没查明白，先被 PowerShell 绊了两次
有一次，我把 curl -U ... 复制进 PowerShell，得到的却是：
1 | Invoke-WebRequest：无法处理参数，因为参数名称 U 具有二义性。 |
我的环境把 curl 当成了 Invoke-WebRequest 的别名，根本没调用到真正的 curl。改成 curl.exe 才能继续。
后来 AI 又给了一条用 ^ 换行的命令，我照着粘进去，PowerShell 继续报错。那是 CMD 的续行方式，不是 PowerShell 的。
折腾到这里，我决定：后面的短命令尽量一行写完。
这些错误和代理质量没有半毛钱关系，但它们会混在排错过程里，让事情显得比实际更乱。
客服说支持，那就一个变量一个变量地测
我去找了 Decodo 的在线客服。
最先接待的是自动客服。它明确回复，Google 和 ChatGPT 都支持，YouTube 也应该能用，让我换个 ISP 端口试试。
这是当时的客服答复。
我把三个端口都测了一遍，还是 reset。
客服又让我换几个无关的 HTTPS 网站，看看是不是只有这些目标有问题。HTTPS 就是在 HTTP 外加了 TLS 加密，TLS 是传输层安全协议，用于保护连接内容和验证服务端身份。
这次有区别了。
GitHub 能返回 301 或 200，Cloudflare 能返回 200，普通 HTTPS 网站也能打开。
成功的输出大概是这样：
1 | HTTP/1.1 200 Connection established |
代理不是完全不通，而是不同目标的表现不一样。
我把当时的几轮测试整理成了一张表：
| 我改了什么 | 当时看到的结果 | 能说明什么 |
|---|---|---|
| 换三个端口，覆盖日本和美国出口 | Google、ChatGPT 等仍然 reset | 不像只是某一个出口偶发故障 |
| 改测 GitHub、Cloudflare 等网站 | 能收到正常 HTTP 响应 | 不是所有 HTTPS 连接都失败 |
| 台式机换成笔记本 | 问题仍能复现 | 不限于原来那台电脑 |
| 笔记本分别连 Wi-Fi 和手机热点 | Google、ChatGPT 仍失败，GitHub 可达 | 不限于某一个局域网，但尚不能排除共同的上游网络环境 |
换了设备、换了热点以后，我和 AI 一度把排查方向转向了商家的账户或网关。
但这些测试还不能完全排除网络因素。换接入网络，不等于换掉了所有共同经过的网络路径。 几台设备和手机热点仍可能经过相似的上游网络，因此只能缩小范围，不能直接认定是 Decodo 的问题。
中间客服还让我检查后台 VPN、防火墙、杀毒软件。我把已经做过的测试重新说明了一遍，最后转到了人工。人工客服在他那边跑同样的请求，却复现不了这个错误，所以又让我换蜂窝网络测试。上表里的笔记本和热点对照，就是这一路补出来的。
还有个小坑：某次我对 ip.decodo.com/json 也用了 -I，结果返回 405 Method Not Allowed。这次不是网络断了，而是接口只接受 GET / OPTIONS，我却发了只取响应头的 HEAD 请求。去掉 -I 才是原来的 GET 检测。
HTTP 错误响应和连接中断，得分开判断。
curl -v 终于让我看到，连接断在了哪一阶段
人工客服要我补一份 verbose 日志，也就是用 -v 打印更详细的连接过程。
测试命令如下，账号和日志中的认证信息已用占位符替换。
1 | curl.exe -v -o NUL --proxy "http://isp.decodo.com:10003" --proxy-user "YOUR_USERNAME" "https://chatgpt.com/" |
-o NUL 是把响应正文丢掉，免得终端被整个网页刷满。连接过程仍会显示。
失败记录里的关键部分是：
1 | > CONNECT chatgpt.com:443 HTTP/1.1 |
后面另一些测试则显示：
1 | curl: (56) Proxy CONNECT aborted |
这时我才开始理解，HTTP 代理访问 HTTPS 网站，并不是直接把网页请求扔过去。
客户端会先向代理说：请帮我建立一条通往 chatgpt.com:443 的通道。这就是 CONNECT。客户端收到成功响应后，才会在这条通道里和目标网站进行 TLS 握手，再发送加密的网页请求。
所以，200 Connection established 和后面的 200 OK 不是重复说了两遍成功。前一个是代理隧道建立成功，后一个才是目标网站的 HTTP 响应。
而我失败的那份记录，连前一个都没收到。
这说明连接中断在 CONNECT 阶段，还没进入与目标网站的 TLS 握手。至于是请求途中被干预，还是代理侧处理异常，客户端日志并没有给出答案。定位到中断阶段，不等于定位到了责任方。
同样，Proxy auth using Basic 也只能说明客户端准备发送这种认证信息，不等于服务器已经确认认证通过。
技术团队的邮件，让我换了一个方向
客服把工单交给技术团队，最初给的预期是通常两个工作日内回复，但当天后面就收到了邮件。
他们注意到的也是那个反差：自己的检测接口可达，Google、ChatGPT 却被 reset。他们认为，这很像网络层过滤或干扰，询问了我所在的地区，并建议对比不同协议，以及开、关 VPN 时的结果。
技术团队回信。
于是我把 OuO 重新打开，并启用了客户端的 TUN，也就是虚拟网络接口模式。
这里我又补了一课：TUN 不是一个海外节点，也不是加密协议。 它负责把系统网络包交给代理程序；后面是否加密、走哪个出口，由客户端和实际使用的节点协议决定。
之前只开系统代理时，应用需要使用这套设置，才会把请求送进去。而我在 curl 里已经显式指定了 Decodo，不能指望它再自动套一层 OuO。用 TUN 做这轮对照，是为了让到 Decodo 入口的连接也进入现有代理路径。
这一次，Google 通了，YouTube 也能访问了。
但 ChatGPT 仍然是：
1 | Proxy CONNECT aborted |
我又测了 openai.com 和 api.openai.com，还是同样的错误。
看起来又像是 OpenAI 被单独限制了。可客服前面明明说支持。
这时候，邮件里还有一个变量没试完。
SOCKS5。
换成 SOCKS5，终端突然刷出了几百 KB 的网页
SOCKS5 是另一套代理协议。它不通过 HTTP 的 CONNECT 方法协商，而是有自己的认证与连接请求格式，可以让代理连接指定域名和端口。
我换了下面的写法：
1 | curl.exe -v -o NUL --proxy "socks5h://isp.decodo.com:10003" --proxy-user "YOUR_USERNAME" "https://chatgpt.com/" |
这里 socks5h 的 h 很重要：它表示目标域名交给代理解析，而不是先在本机把目标解析成 IP 再交过去。
最开始那一遍，我还没加 -o NUL。一回车，终端突然刷出了巨量文本，多到我根本复制不过来。
我还在问，这怎么截？
然后才意识到，那不是一长串报错。
那是 ChatGPT 的网页正文。
加上 -o NUL 以后，关键结果就很清楚了：
1 | * SOCKS5 connect to chatgpt.com:443 (remotely resolved) |
接着我又把 OuO 的系统代理和 TUN 都关掉，直接从当前网络连接 Decodo SOCKS5。
还是 200 OK，这一遍下载了约 486 KB 的页面。
折腾了这么久，终于拿到一个能工作的结果。
HTTP CONNECT 与 SOCKS5 的测试结果。
HTTP 代理、HTTPS 代理和 SOCKS5，差别在哪
换协议解决了这次连通性问题，但它们之间的区别并不是谁比谁更高级。
通过普通 HTTP 代理访问 HTTPS 站点时，目标内容仍可以被 TLS 加密，但前面的 CONNECT 协商本身并不因此自动加密。真正的 HTTPS 代理，是客户端到代理这一段也先建立 TLS 连接；不能只因为目标网址以 https:// 开头，就把它称作 HTTPS 代理。
而 SOCKS5 也不是天然加密隧道。尤其常见的用户名 / 密码认证，标准明确指出密码是以明文携带的。目标网站的 HTTPS 能保护网页内容，不会反过来替 SOCKS5 的认证阶段加密。
这次测试确认的是：同一组入口下，HTTP CONNECT 访问 OpenAI 失败，而 SOCKS5 路径可用。 具体差异来自协议特征、网关实现，还是中间网络设备，仍未查明。
能连上，和能拿来干活，又是两回事
我以为把 FlClash 里的 type: http 全改成 type: socks5，这件事就能收尾了。
结果节点开始一会儿绿，一会儿 timeout。网页不是完全打不开，而是能进去，但很慢，资源一直加载，转圈转得人没脾气。
这比完全打不开还烦，因为你总觉得再等一下它就好了。
单次 curl 成功，证明的是那次请求拿到了响应。浏览器还要加载脚本、图片、接口；部分 ChatGPT 和 Codex 功能还会使用 WebSocket，也就是持续双向通信的连接。
所以，首页 HTML 能下完，离真正好用还差一截。
我又做了一组对照：同样经过 Decodo SOCKS5 请求 ChatGPT 首页，一次让 OuO TUN 先接管连接，一次直接连 Decodo。
这次保留下来的原始数字是：
| 指标 | OuO TUN → Decodo | 直接连接 Decodo |
|---|---|---|
time_connect |
0.009220 s | 1.219353 s |
time_starttransfer |
1.960126 s | 3.500436 s |
time_total |
2.706354 s | 4.599579 s |
speed_download |
183747 B/s | 126562 B/s |
首字节时间是从请求开始到收到第一个字节的时间，包含建连和服务端处理；总耗时则是整个操作花的时间。这里的速率也是这次响应的平均传输速率，不是独立测出来的线路带宽。
裸连与经过 OuO 的单次请求对比。
这组数据每条路径只记录了一次，响应体大小和缓存也没有统一控制，不能直接拿来计算长期提速比例。
尤其是 TUN 那一侧的 time_connect 只有 9 毫秒，并不代表到海外代理的实际延迟只有 9 毫秒。虚拟网络接管以后，curl 看到的连接建立，不一定意味着后面的跨境链路也已经全部连好。
这组数字让我更愿意试一试链式方案，但真正让我留下它的，还是后面浏览器和 Codex 的实际使用体验。
我也不再打算直接用新代理换掉旧代理。
而是：旧代理负责把路走顺，新代理负责最后从哪个 IP 出去。
最后，我把新旧代理串了起来
我还专门担心过一个很现实的问题：我总要一边看 YouTube 网课，一边问 AI。难道以后看视频用 OuO，问问题再切 Decodo？
那还学什么，光切节点了。
代理客户端可以按域名分流，不需要来回切换。同一台设备、同一个浏览器里的不同连接，不一定要走同一个出口。
最后我把目标拆成三路：
1 | ChatGPT / OpenAI |
最终的分流与代理链。
这条链里，OuO 日本节点是第一跳，Decodo 是最后对外发请求的出口。对于确实命中这条链的连接，目标服务看到的是 Decodo 的出口，而不是 OuO 的共享出口。
链式代理解决的是路由和出口分工，不是匿名保证。 OuO 和 Decodo 仍各自参与连接，SOCKS5 的认证与目标信息也不会对整条链路上的所有参与方自动保密。
Windows：一万九千行配置，只改关键几处
我那份 OuO 配置有一万九千多行。
当时我看着就不太想手动碰，最后把文件交给 AI 帮我检查和修改。
好在原配置已经有 OpenAI、Google、YouTube 这些策略组。所谓策略组，就是让一类请求去选某个节点，或者再选另一个组。
不需要把后面所有规则重写一遍。关键是给 Decodo 节点加上 dialer-proxy，引用已有的日本节点组，让 Decodo 通过这个组建立连接。
在原有 YAML 配置的 proxies 列表中，Decodo 节点的关键字段如下：
1 | proxies: |
然后把 OpenAI 策略组指向 Decodo 的选择组，再选 Decodo JP Main。第一跳的日本节点组里只放原来的 OuO 节点，不把 Decodo 放回去，避免形成循环。
这套链式设置和 TUN 是两回事。前面用 TUN 做实验，是为了接管 curl 的连接；正式合并配置以后，由 dialer-proxy 明确规定第一跳。我的电脑只开系统代理、不开 TUN，也能让进入客户端的请求走这条链，但不会因此接管所有程序。
FlClash 中的三个 Decodo 节点。
网页恢复以后，我又查了一次实际出口。
我临时把 ip.decodo.com 也指定到 OpenAI 策略组，再查最终出口，确认回来的确实是日本主力 IP。普通 IP 检测页不加这条规则时，会走默认海外出口，查到 OuO 地址很正常。
然后我又在 Codex 里发了一个真正调用模型的小任务，回到客户端的连接页看。
Codex 命中 Decodo JP Main。
连接页里的进程是 codex.exe，目标是 chatgpt.com，策略链里也有 Decodo JP Main。这次模型请求确实走到了我指定的节点。
第二台电脑又给我补了一课：策略组不是全局总开关
我一共有两台台式机、一台笔记本。客户端也不完全一样，有 FlClash，也有 Clash Verge。
第一台跑通后，把配置复制过去，ChatGPT 能用，YouTube 能看，Gmail 却一直停在加载界面。
我以为是新电脑上的链路又出问题了。
最后发现，这台机器的 Google 组还选着手动切换，它又指向另一条 OuO 线路。改成可用的日本节点以后，Gmail 就恢复了。后来普通海外业务又按实际体验选了低延迟的香港节点。
我之前一直以为，选了 Decodo JP Main，下面其他组就不用管了。
其实在规则模式下，各组的选择可以同时生效：Google 看 Google 组，YouTube 看 YouTube 组，OpenAI 看 OpenAI 组。一个组还可能引用另一个组，所以它们也不是完全互不影响。
复制了 YAML，不代表每台客户端当前保存的选择状态也一模一样。
这件事搞明白后，剩下电脑的迁移就顺了。
我最后保留的是本地配置副本，避免订阅更新时覆盖手动改动。不过这个副本也不会自动跟着 OuO 更新，以后订阅节点变了，还得同步并检查引用。
最后一关：把同一套逻辑搬到 iPhone
手机用的是 Shadowrocket，不能指望直接照搬 Mihomo 的字段。
但我在节点详情里找到了一个非常直观的选项：代理通过。
给 Decodo JP Main 填好 SOCKS5 参数，把代理通过选成 OuO 的 AnyTLS.JP 03，网络路径就对应上了。
Shadowrocket 的代理通过设置。
先临时让手机走 Decodo，Safari 打开检测页，拿到的出口和电脑一致。ChatGPT 网页版也能开。
但我又不确定 App 是不是也走了。
最后还是去翻日志。
前一轮还没做精细分流时，ios.chat.openai.com、chatgpt.com 走的是 PROXY，Google 也走 PROXY，而首页当前节点就是 Decodo。
这样 Google 也会绕到 Decodo，分流还没做完。
于是我把 OpenAI 相关规则放到了当前配置前面，明确指向 Decodo JP Main。再把首页默认节点改回 OuO 香港，全局路由保持配置模式。
核心规则是下面四条。我的实际配置还加了一条 DOMAIN-KEYWORD,openai，同样指向 Decodo，用来匹配域名中包含 openai 的连接。
1 | DOMAIN-SUFFIX,chatgpt.com,Decodo JP Main |
后缀匹配会覆盖相应子域名，所以不用再给 ios.chat.openai.com、ws.chatgpt.com、ab.chatgpt.com 各写一条。
改完再测试，日志里的关键记录如下：
1 | # ChatGPT App |
同一批记录里，还能看到 Decodo 的后端链、OuO 日本会话，以及 SOCKS5 的 handshake ok。
App 的主要连接走 Decodo，Google 和 YouTube 走香港，国内网站保持直连，分流结果和预期一致。结合实际发消息和内容加载，手机上的日常使用也跑通了。语音、视频功能还没有完整测试。
到这里，三台电脑和 iPhone，才算把同一套主要分流逻辑落下来了。
折腾完以后，我到底解决了什么
最开始我想的是：我要一个干净 IP，最好别让我担心 GPT 降智。
最后实际解决的，是一个更具体的问题：我的主要 OpenAI 请求，有了一条固定出口、路由可检查、实际用起来顺畅的路径。
出口信誉、接入协议、连接质量和分流规则，得分开检查。检测分数低，不代表目标一定能访问；curl 收到 200，也不代表浏览器就能流畅使用。直到实际请求、客户端日志和日常体验都对上，这套配置才算跑通。
AI 帮我解释概念、整理命令、改一万多行的配置，省了不少事。但它也把 CMD 的命令给了 PowerShell，并根据不完整的现象提前猜过原因。最后留下来的配置，是一轮轮实际测试的结果。
收尾时，我还用查找替换更新了三个 Decodo 节点的密码，再同步到其他设备。排查日志中的 Proxy-Authorization: Basic ... 也需要遮掉，Base64 只是编码，不是保密手段。
至于最开始那个问题：换成干净 IP，GPT 到底有没有变聪明？
这次没有做模型能力的前后对照，回答不了这个问题。
现在能确定的是，ChatGPT 用起来稳定，Codex 的模型连接也看到了正确的策略链；与此同时，YouTube 和 Gmail 还能继续走原来更快的线路。
甚至可能我的账号本来就没有被降智。