日常开发中经常需要通过终端工具调用外部大模型 API。最近在使用 opencode 时遇到一个典型问题：浏览器能正常访问外网，但终端请求却持续报错、无法连通 API。
本文记录了完整的排查过程，包括使用 Proxifier 的尝试与踩坑，以及最终采用 Clash TUN 模式的解决方案。
1. 发现问题与初步尝试：Proxifier 登场
初步分析后发现，opencode 等终端工具不会读取 Windows 系统代理配置，而是直接通过 Socket 接口向目标 IP 发起连接，导致流量绕过了 Clash。
常见解决方案是使用 Proxifier 进行进程级流量拦截。配置分两步：
- 建立代理通道：在 Proxifier 中添加
127.0.0.1:7890，协议选择 SOCKS5 - 设置分流规则：指定目标程序走代理，Clash 本身走直连
2. 踩坑实录：语法错误与无限死循环
在配置规则过程中遇到了两个典型错误：
错误一：路径语法导致读取失败
直接从桌面复制快捷方式名称 Clash for Windows.exe - 快捷方式 (2)，系统报错：
1 | Unexpected blank space found... |
解决：使用真实的 .exe 执行文件路径，空格路径用英文双引号 "" 包裹，多程序用英文分号 ; 分隔。
错误二：遗漏核心进程导致 Infinite Loop
修正语法后，Proxifier 弹出严重警告：Infinite loop connection detected
根因分析：
- 我只放行了图形界面
clash for windows.exe - 遗漏了真正负责网络收发的核心进程
clash-win64.exe - Proxifier 把 Clash 核心发出的代理数据包强行拦截，又塞回 7890 端口，形成死循环
解决：将 clash-win64.exe 加入直连规则，opencode 改为 Proxy。
3. 探寻更优解：从 API 劫持到 TUN 虚拟网卡
虽然 Proxifier 方案可行，但它是闭源商业软件（31天试用），且基于 Winsock API Hooking，部分程序可能绕过。
更彻底的方案是 Clash 原生 TUN 模式：
TUN 模式工作机制
在 Clash「常规」设置中安装 Service Mode 并开启 TUN 后：
- 网卡层接管：系统创建
wintun虚拟网卡 - 路由表重构：所有应用程序的 IP 数据包在路由阶段被强制送入虚拟网卡
- Fake-IP 机制：DNS 解析返回假 IP (
198.18.0.x)，Clash 在内存中完成域名映射后代理发出
4. 最终结论
最终选择关闭 Proxifier，直接启用 Clash TUN 模式：
- 无需手动配置进程规则
- 避免遗漏核心进程导致的死循环风险
- 终端工具的网络请求被 TUN 网卡透明捕获并代理
这是目前解决终端网络代理问题最具普适性和稳定性的方案。
