# 🧠 AI 友好机制-彻底解决antigravity不稳定问题 > 一份面向公开讨论的技术研究。 > > 主题不是"哪个协议理论上最强"，而是： > 为什么某些链路在交易场景无敌顺滑，却会把 AI 编程工具用成地狱；而另一条看起来更绕的链路，反而能让 AI 体验极度丝滑。 > > 📅 最后更新: 2026-04-13 | 状态: 实战验证完成 --- ## 📌 结论先行 在 AI 编程场景里，真正决定体验的，往往不是最低延迟，而是： - 是否真正兼容 - 是否能扛住"长时间无输出后的继续返回" - 是否在轻微丢包时仍然保持 UI 连续、不超时、不报错 - 是否能在断线后快速恢复，而不是整条流彻底崩掉 这会导出一个很反直觉但非常实用的结论： > 一个延迟略高、但对流式交互更友好的独立链路，常常比一个低延迟的主链路更适合 AI 编程。 --- ## 🔬 为什么"低延迟主链路"会在 AI 工具里翻车 ### 💡 传统主链路的优化目标 | 目标 | 适合场景 | 与 AI 的关系 | |------|---------|-------------| | 🌐 日常网页浏览 | 短请求短响应 | ✅ 无冲突 | | 📈 金融看盘 | 低延迟稳定 TCP | ✅ 无冲突 | | 🔒 高隐蔽性 | 对抗 GFW 审查 | ⚠️ 可能副作用 | | 🛡️ 高抗封性 | 模拟正常 HTTPS | ⚠️ 可能副作用 | 这些目标都没有错。问题在于，AI 编程工具不是普通网页。 ### 🤖 AI 工具的典型行为 也就是说，AI 工具的核心诉求不是"极限首包速度"，而是： > 流不要断，状态不要丢，恢复不要慢。 --- ## ⚡ Vision 把 SSE 搞坏的根因分析（代表性案例） ### 🎯 冲突矩阵 某些为隐蔽性或抗审查做过深度处理的 TCP/TLS 链路（如 XTLS-Vision），在普通浏览里很好，但在 SSE 场景下会产生致命副作用： | 维度 | Vision 做了什么 | SSE 需要什么 | 冲突点 | |------|----------------|-------------|--------| | TLS 记录拼接 | 把多个小 TLS 记录合并成大记录，消除"大量小包"指纹 | SSE 是 token-by-token 极小包高频推送 | 合并了本不该合并的 SSE 帧 → 数据延迟/丢失 | | 随机填充 | 往 TLS 记录里塞 padding 模拟正常 HTTPS 包大小 | SSE 心跳 () 本身就是极小包 | 填充逻辑和心跳包冲突 → 状态机混乱 | | 空闲期处理 | 长时间无数据时可能触发超时判定 | Agent 思考期 10-30 秒完全无数据 | 误判连接已死或填充行为干扰恢复 | | 流方向对称假设 | 普通 HTTPS 是对称的（双向交互） | SSE 极度不对称（单向服务端→客户端喷流） | 指纹消除算法基于对称假设，SSE 打破了假设 | ### 📊 实锤证据 > 2026-03-30：同一台电脑、同一个网络，用"垃圾 VPN"（简单隧道协议）时 Antigravity 零断联，用 VLESS+Vision 时 1-5 秒即断。 这直接证明了问题出在 Vision 的 TLS 层操控，而非 TCP 本身。 --- ## 🌐 不止 Vision：一切 VPN 都在某种程度上破坏 SSE > 2026-04-13 路由审计后的核心发现 Vision 只是问题的"极端案例"。实际上，绝大多数 VPN/代理/中间件在面对 SSE 时都会产生干扰，区别只在程度和机制： ### 🧱 三大广义干扰机制 #### 1. 📦 中间层缓冲 (Proxy Buffering) — 致命的"自作聪明" 大多数 VPN 节点、代理软件（如 Nginx、传统 V2ray 配置）以及企业级防火墙，为了最大化网络吞吐量并减少碎片包，默认开启了缓冲区（Buffer）。 - VPN 的视角：收到 1 byte 的小包太浪费带宽，我要先拦截下来，等攒够 10KB 凑成大包再一次性发给客户端 - SSE 的视角：AI 吐出的每一个 Token（可能只有几个字节）都需要立刻在 UI 上渲染 - 💥 冲突：前端表现为"卡死"，然后突然一大段文字瞬间弹出来。缓冲时间过长则直接超时断流 > 全网佐证：Nginx 默认 、Azure APIM、YARP、Traefik 等中间件都需要专门配置 才能不破坏 SSE。 #### 2. ⏳ 激进的空闲连接清理 (Aggressive Idle Timeouts) 大部分 VPN 服务商或底层协议设定了严格的 TCP/UDP 空闲超时策略（通常 30-60 秒无数据即回收连接）。 - VPN 的视角：这个连接 30 秒没动静了，肯定是幽灵连接，杀掉释放资源 - SSE 的视角：AI 编程助手遇到复杂代码时，经常有 10-30 秒的"思考空窗期"，此时没有数据下发 - 💥 冲突：AI 刚思考完准备返回代码，底层 TCP 连接已被 VPN "出于好心"强制掐断 #### 3. 🛡️ 流量混淆与协议魔改 (Traffic Obfuscation) 不仅是 Vision 会做 TLS 记录的拼接与填充，许多为穿透 GFW 设计的协议（Shadowsocks 变种、Reality 等）都会对数据包重组、加密填充。 - 💥 冲突：SSE 依赖的心跳包（）极小且高频，混淆机制破坏其完整性或延迟到达 → 前端状态机混乱 → 误判连接已死 ### 📊 各协议对 SSE 的干扰程度 | 协议/代理类型 | 缓冲干扰 | 超时干扰 | 混淆干扰 | SSE 友好度 | |:---:|:---:|:---:|:---:|:---:| | XTLS-Vision | 🔴 TLS 拼接 | 🔴 可能误判 | 🔴 随机填充 | ❌ 极差 | | Shadowsocks 系 | 🟡 取决于实现 | 🟡 取决于配置 | 🔴 重度加密重组 | ⚠️ 一般 | | OpenVPN | 🔴 MTU 分片 | 🟡 可配超时 | 🟡 轻度 | ⚠️ 一般 | | WireGuard | 🟢 内核级透传 | 🟢 无连接概念 | 🟢 无混淆 | ✅ 较好 | | VLESS+WS (CC Worker) | 🟢 零缓冲 | 🟢 WS ping/pong | 🟢 无混淆 | ✅★ 最优 | ### 💡 通则 > 越是追求多功能、高隐蔽性的"聪明"链路，越容易自作主张地干预数据，从而破坏对连贯性要求极高的 SSE 单向推流。 > > 想要解决这个问题，唯一的出路就是像 CC Worker 那样，建立一条完全不碰应用层数据、不做缓冲的"笨管道"。 --- ## ✅ AI 友好链路的 4 个关键特征 ### 1. 🔄 不破坏应用层流式语义 链路必须对 SSE 帧做到字节级透传，不做任何拼接、填充、重排序。 ### 2. ⏳ 对长连接更宽容 AI 任务是"突发输出 → 长时间悬停 → 突发输出"的间歇模型，链路不能对空闲连接施加超时压力。 ### 3. 📡 轻微丢包不拖垮整条流 AI 编程不追求极低延迟，但很怕一次轻微抖动后 UI 冻结、整段回答报错。 ### 4. 🔁 重连恢复必须快 断了能快速恢复、恢复后不继续报错、不需要频繁手动刷新。 --- ## 🏆 最终解决方案：CC Worker（EdgeTunnel） ### 🎯 为什么 CC Worker 天然 AI 友好 > 2026-04-13 实战验证：CC Worker 的纯净 WebSocket 透传实现了 Antigravity 零断联，体验极度丝滑。 根因只有一句话： > Vision 在 TLS 层"动手脚"搞坏了 SSE；CC Worker 走的是纯净 WebSocket，根本不碰应用层数据。 ### 📐 传输链路对比 | 环节 | CC Worker | Vision | 结果 | |------|-----------|--------|------| | TLS 加密 | Cloudflare Edge 全权处理 | Xray 自己操控 TLS 记录 | Worker 不碰 TLS 内部结构 | | 数据转发 | 字节级透传 | 经过 Vision 流控引擎处理 | Worker 不做任何拼接/填充 | | 随机填充 | 无 | 有（消除指纹） | SSE 心跳不受干扰 | | 长连接保活 | WebSocket 原生 ping/pong | Vision 可能误判超时 | Agent 思考期安全度过 | ### 📊 五场景对比总结 | 场景 | Vision | Hysteria2 | CC Worker | |------|--------|-----------|-----------| | SSE 兼容性 | ❌ TLS 操控导致断联 | ✅ 不碰应用层 | ✅★ 纯净透传 | | 长连接稳定 | ❌ 频繁断裂 | ✅ QUIC 保活 | ✅★ WS 原生支持 | | Agent 思考期 | ❌ 可能触发 bug | ✅ 自动保活 | ✅★ 无超时压力 | | 与 VPS 解耦 | ❌ 同一服务器 | ❌ 同一服务器 | ✅★ 完全独立 | | 部署复杂度 | 中（需服务端配置） | 高（需 UDP+证书） | 低（Worker 即部署） | --- ## 🛠️ 最佳实现方案 ### 📦 基于 EdgeTunnel 的 CC Worker 专线 #### 上游项目 | 项目 | 地址 | |------|------| | edgetunnel | | | 研究基线 | commit (2026-04-10) | | 性质 | Cloudflare Workers/Pages 边缘隧道程序 | #### 我们只用了最克制的一层 edgetunnel 本身是一套完整的"隧道 + 订阅 + 管理后台"系统，但我们只使用了它的 Worker 隧道能力： #### 最小暴露面策略 | 配置 | 选择 | 原因 | |------|------|------| | 自定义域 | ✅ 启用 | 唯一对外入口 | | | ❌ 关闭 | 不暴露 域名 | | KV 绑定 | ❌ 不开 | 不需要后台/订阅 | | 管理面板 | ❌ 不开 | 减少攻击面 | | UUID | 固定手动设置 | 稳定可控 | #### 部署一条 CC 线路只需 3 步 1. fork 或直接上传 2. 设置环境变量 = 你的固定 UUID 3. 绑定自定义域名，关闭 > 整个过程不动现有 VPS、不动主线节点。CC Worker 与你的主系统完全解耦。 --- ## 🔀 CC Worker 在整体架构中的定位 ### 🏗️ 核心思路：独立 AI 通道 CC Worker 不替代你现有的主系统（无论是 Vision、Hysteria2 还是其他协议），而是在主系统之外拉出一条 专属 AI 的独立链路： ### 📋 职责划分原则 | 通道 | 协议 | 承担什么 | 为什么 | |------|------|---------|--------| | CC Worker | VLESS+WS via Cloudflare | AI 编程专线 | 不碰应用层、SSE 天生兼容、与 VPS 完全解耦 | | 你的主线 | 任何（Vision/HY2/WG 等） | 日常/交易/游戏 | 延迟低、稳定、满足各类场景需求 | ### ⚠️ CC Worker 不该做什么 "AI 友好"不等于"全能主力"。独立 AI 通道不应该被拿去承担： - ❌ 大规模公开分享 - ❌ 大流量下载 - ❌ 全设备全场景默认总出口 它最适合的定位： > 高质量、低暴露、专注流式交互的 AI 专线。 --- ## 🚦 完整分流规则：Flyfish v3.2（2026-04-13 路由审计版） ### 🎯 设计哲学：CC Worker 白名单制 > CC Worker 只接显式列出的域名，绝对不做兜底（MATCH）。 > 未识别流量走主线（电脑 → DMIT Vision / 手机 → DIRECT）。 ### 📋 12 级执行优先级 规则按从上到下（优先级从高到低）执行，首次命中即停止： | 优先级 | 类型 | 目标 | 通道 | 备注 | |:---:|------|------|:---:|------| | 1 | 🧠 AI SSE 长连接 | Antigravity / Gemini / OpenAI / Anthropic | CC Worker | 白名单制，见下方完整表 | | 2 | 🐦 X/Twitter | x.com, twitter.com, twimg.com | CC Worker | 同走 CC | | 3 | 📈 交易 | TradingView, MetaTrader, xuebz.com | DMIT Vision | 低延迟优先 | | 4 | 🚫 垃圾拦截 | wpad | REJECT | 系统代理探测，纯浪费 | | 5 | 🚫 遥测直连 | exp-tas.com, events.data.microsoft.com | DIRECT | 不浪费代理资源 | | 6 | 🎮 游戏 | Steam, Epic | Hysteria2 | UDP 低延迟 | | 7 | 🇨🇳 国内域名 | geosite:cn | DIRECT | — | | 8 | 🇨🇳 国内 IP | geoip:cn, private | DIRECT | — | | 9 | 🛡️ 广告拦截 | geosite:category-ads-all | REJECT | — | | 10 | 🌐 海外总出口 | geosite:google, gfw, geolocation-!cn | DMIT Vision | 防止漏进 CC Worker | | 11 | 🏠 局域网 | geoip:private | DIRECT | — | | 12 | 🔄 兜底 | MATCH | DMIT Vision（电脑）/ DIRECT（手机） | 绝对不能指向 CC Worker | ### 🧠 CC Worker 白名单（完整版） > 经 Google 官方防火墙文档 + Clash 日志实战验证 + 全网搜索确认 #### SSE 长连接域名（必须走 CC Worker） | 分类 | 域名 | 匹配方式 | 来源 | |------|------|:--------:|------| | Antigravity 核心 | | SUFFIX | 日志确认 | | Antigravity 核心 | | DOMAIN | 日志确认 | | Antigravity IDE | | SUFFIX | Google 官方 + 日志 | | Antigravity IDE | | SUFFIX | 日志确认 | | Gemini Code Assist | | DOMAIN | Google 官方白名单 | | Gemini API | | DOMAIN | Google 官方 | | Gemini 前端 | | DOMAIN | Google 官方 | | OpenAI 全系 | , , | SUFFIX | — | | OpenAI 资源 | , | SUFFIX | — | | Anthropic 全系 | , , | SUFFIX | — | #### Google 认证/辅助链（保障 OAuth2 + MCP 稳定性） | 分类 | 域名 | 匹配方式 | 来源 | |------|------|:--------:|------| | 认证 | | DOMAIN | Google 官方 | | 项目管理 | | DOMAIN | Google 官方 | | 用户信息 | | DOMAIN | Google 官方 | #### 不需要走 CC Worker 的 Antigravity 域名 | 域名 | 类型 | 走向 | 原因 | |------|------|:---:|------| | | 短连接 | DMIT | 更新检查，一来一回 | | | REST API | DMIT | MCP GitHub，短连接 | | | HTTP 下载 | DMIT | 扩展市场，短连接 | | | 短连接 | DMIT | 遥测上报 | #### 不需要走 CC Worker 的 Gemini 辅助域名 | 域名 | 类型 | 走向 | 原因 | |------|------|:---:|------| | | 静态资源 | DMIT (geosite:google) | 字体/JS/CSS，走 DMIT 秒加载 | | | 静态资源 | DMIT (geosite:google) | 图片/内容，走 DMIT 秒加载 | > 📌 混合策略：Gemini 网页的 SSE 流走 CC Worker（不断连），静态资源走 DMIT（秒加载）。两全其美。 ### 🚫 必须拦截的垃圾流量 | 域名 | 处置 | 原因 | |------|:---:|------| | | REJECT | 系统 WPAD 自动代理探测，每隔几秒刷一次 | | | DIRECT | 微软实验/遥测 | | | DIRECT | Windows 活动历史 | | | DIRECT | VS Code / Antigravity 遥测 | ### 🔧 运维 SOP：发现新的漏网 AI 域名 1. 打开 Clash 日志窗口，搜索 或 2. 找到 的行 3. 提取域名 → 加到三个配置文件的 AI 白名单顶部 4. 同步更新本文档白名单表 5. 重载 Clash 配置 --- ## 📈 Hysteria2 的角色变更 过去引入 Hysteria2 的核心原因是： - 主链路 (Vision) 对 AI 流式交互不友好 - 需要一条更适合长连接和流式输出的替代通道 CC Worker 出现后，这个需求已被更优雅地满足： | 日期 | HY2 角色 | 驱动因素 | |------|---------|---------| | 2026-03-30 前 | ❌ 已否决 | "UDP 延迟不可控，不适合交易" | | 2026-03-30 | 🔴 AI 唯一救星 | 实锤 Vision+SSE 不兼容 | | 2026-04-13 | 🟢 降为候补 | CC Worker 彻底解决 AI 断联 | > 不是 Hysteria2 失去价值了，而是"为了拯救 AI 体验而把它塞进主系统"的必要性下降了。 CC Worker 证明了 AI 断联的根因是 Vision 的 TLS 操控，而非 TCP vs UDP 的差异。一条"笨但干净"的 WebSocket 管道就够了。 --- ## 🧬 核心洞察 > 越"聪明"的协议（Vision、Reality），越容易和特殊应用层模式冲突。 > 越"笨"的协议（WireGuard、SOCKS5、WebSocket 透传），反而兼容性越好。 > 而一切 VPN/代理都在某种程度上破坏 SSE——Vision 只是最极端的案例。 这不是理论推导，而是实战验证的结论： - ❌ Vision TLS 操控 → SSE 断联（极端） - ⚠️ 大多数 VPN → 缓冲/超时/混淆都会不同程度干扰 SSE - ✅ 垃圾 VPN 简单隧道 → AI 零断联（但不稳定） - ✅★ CC Worker 纯净 WS 透传 → AI 零断联 + 极度丝滑（最优解） > AI 编程的最优解，不一定在主链路里。 > > 很多时候，真正的升级不是继续把主系统堆得更复杂，而是单独拉出一条更懂 AI 的链路。 > > 而且，对于混合场景（如 Gemini 网页），正确的策略是让 SSE 流走 CC Worker、让静态资源走 DMIT，而不是"一刀切"全走某一条线。 这，才是 AI 友好链路机制 的核心价值。 --- ## 📚 全网佐证 (2026-04-13 检索) 以下佐证均来自独立第三方来源，与本文结论交叉验证。 ### 佐证 1：XTLS Vision + SSE 的兼容性问题是已知问题 > 来源: GitHub Xray-core Issues / 社区讨论 | 外部发现 | 与本文结论的关联 | |---------|---------------| | XTLS Vision 的 Splice 机制会对 TLS 记录做拼接/填充处理，以消除流量指纹 | ✅ 本文 §3 "Vision 把 SSE 搞坏的根因分析"完全吻合 | | SSE 是持久 HTTP 连接的增量推送，对中间层的缓冲/拼接行为极度敏感 | ✅ 本文 "TLS 记录拼接"冲突矩阵的第一行 | | Vision 的流控逻辑假设双向对称通信，SSE 的极端单向推流打破了这一假设 | ✅ 本文 "流方向对称假设"冲突矩阵的第四行 | | 社区建议用 XHTTP 替代 Vision 来解决流式兼容问题 | ✅ 本文的 CC Worker (WS) 方案是同类思路的实战落地 | > 结论：Vision 对 SSE 不友好不是个例 bug，而是 架构级冲突。 --- ### 佐证 2：代理/中间层缓冲是 SSE 断流的头号杀手 > 来源: GitHub Issues, StackOverflow, ServerfFault, Stackademic | 外部发现 | 与本文结论的关联 | |---------|---------------| | Nginx 默认开启 ，会把 SSE 流缓冲成大块才发送 → 客户端体感"卡住" | ✅ 本文 "TLS 记录拼接"本质上就是协议层缓冲 | | 解决方案： + + | ✅ CC Worker 的 天然不缓冲，等效于 | | Azure APIM、YARP、Traefik 等中间件都需要专门配置才能不破坏 SSE | ✅ 佐证"越多中间层处理 → 越容易搞坏流式语义"的通则 | > 结论：任何"动手脚"的中间层都是 SSE 的天敌。CC Worker 的纯净透传是正确方向。 --- ### 佐证 3：Cloudflare Workers WebSocket 天然支持流式透传 > 来源: Cloudflare 官方文档 | 外部发现 | 与本文结论的关联 | |---------|---------------| | Workers 使用 API 创建客户端/Origin 双端配对 | ✅ edgetunnel 正是用此 API 实现隧道 | | Worker 的 WebSocket 模式下数据是逐帧传递的，不做整体缓冲 | ✅ 字节级透传的技术基础 | | SSE 在 Worker 中属于标准 HTTP 流式响应，Workers 原生支持流式输出 | ✅ 佐证 CC Worker 不需要额外配置即可兼容 SSE | | Cloudflare 建议对 SSE 响应添加 并关闭缓存 | ✅ edgetunnel 不走 CDN 缓存，天然满足 | > 结论：Cloudflare Workers 的平台特性决定了它是 SSE 透传的理想载体。 --- ### 佐证 4：ChatGPT / Claude 的 SSE 流在 VPN/代理下普遍断联 > 来源: Reddit, Medium, IndieHackers, StackOverflow, ServiceStack | 外部发现 | 与本文结论的关联 | |---------|---------------| | 大量用户报告通过 VPN 使用 ChatGPT/Claude 时流式输出卡顿或断连 | ✅ 与我们 Vision+Antigravity 的实战体验一致 | | 主要归因：代理空闲超时（30-60s）、TCP 半开连接、中间层缓冲 | ✅ Vision 的 TLS 操控属于"中间层缓冲"的变种 | | WireGuard 比 OpenVPN 对长连接更稳定 | ✅ 佐证"越简单的协议越不容易搞坏流" | | 解决方案：心跳保活、禁用混淆模式、降低 MTU | ✅ CC Worker 的 WS ping/pong 天然满足保活需求 | | 企业 SSL 检查 (MITM) 代理对 SSE 长连接同样致命 | ✅ 佐证"一切中间层都是 SSE 的天敌"的通则 | | Xray 社区建议用 XHTTP 替代 Vision 来解决流式兼容 | ✅ 我们的 CC Worker (WS) 方案是同类思路的实战落地 | > 结论：AI 工具 + VPN/代理 = 普遍性痛点，不限于 Vision。我们不是唯一遇到的人，但我们找到了最优解。 --- ### 佐证 5：QUIC vs WebSocket 在 LLM 流式场景下的对比 > 来源: Medium, Lightyear.ai, WebSocket.org, Ably.com | 维度 | WebSocket (TCP) | QUIC/HTTP3 (UDP) | |------|----------------|------------------| | 当前生产可靠性 | ⭐⭐⭐⭐⭐ 行业标准 | ⭐⭐⭐ 仍在成熟中 | | HoL 阻塞 | ❌ TCP 级阻塞 | ✅ 流级独立 | | 连接迁移 | ❌ 不支持 | ✅ 切换 WiFi/4G 不断 | | 浏览器支持 | ✅ 全面 | ⚠️ WebTransport 仍在推进 | 与本文结论的关联： - QUIC 理论上更好（HoL 阻塞消除 + 连接迁移），但 WebSocket 在当前生态中是最成熟可靠的流式通道 - 这解释了为什么 CC Worker (WS) 比 HY2 (QUIC) 在实际 AI 编程中体验更稳定——不是 QUIC 理论不行，而是代理层对 WS 的处理更透明 - WebSocket 是 Cloudflare Workers 的一等公民，而 QUIC 无法在 Workers 上原生运行 > 结论：在代理环境下，WebSocket 的"笨但可靠"胜过 QUIC 的"强但复杂"。 --- ### 佐证 6：edgetunnel 项目的社区验证 > 来源: GitHub (), SourceForge | 外部发现 | 与本文结论的关联 | |---------|---------------| | 项目 Star 数持续增长，社区活跃 | ✅ 方案有广泛用户基础 | | 核心能力：VLESS/Trojan 通过 WebSocket 在 Cloudflare Edge 运行 | ✅ 与我们使用的正是同一个内核 | | 无需 VPS、无需端口、无需证书 | ✅ 与现有 VPS 完全解耦的技术基础 | | 社区明确说明这不是高安全方案，但适合轻量级代理场景 | ✅ 与本文"最小暴露面策略"一致——只做 AI 专线，不做全局出口 | > 结论：我们的 CC Worker 方案不是孤例实验，而是有社区规模验证的成熟路径。 --- ### 📊 佐证汇总 > 六条独立佐证链，从 Xray 社区 → Cloudflare 官方 → LLM 用户社区 → 协议理论对比，全方位交叉验证了本文的每一个核心结论。 > > 这不是一篇基于猜测的技术文章。这是一个从实战出发、被全网独立来源反复验证的工程结论。 # 🧠 AI-Friendly Routing — Solving Antigravity Instability Once and For All > A technical research piece for open discussion. > > The subject is not "which protocol is theoretically best," but: > Why do certain links that feel unbeatable for trading turn into a nightmare for AI coding tools, while a seemingly slower, more roundabout link delivers a silky-smooth AI experience? > > 📅 Last updated: 2026-04-13 | Status: Battle-tested and verified --- ## 📌 Conclusion First In AI coding scenarios, what truly determines the experience is rarely raw latency — it is: - Whether the link genuinely supports - Whether it can survive "long silences followed by resumed output" - Whether minor packet loss freezes the UI or kills the entire response - Whether reconnection is fast and doesn't cascade errors This leads to a counterintuitive but highly practical conclusion: > A slightly higher-latency link that is friendlier to streaming interactions often outperforms a low-latency primary link for AI coding. --- ## 🔬 Why "Low-Latency Primary Links" Fail AI Tools ### 💡 What Primary Links Optimize For | Goal | Ideal Scenario | Relationship to AI | |------|---------------|-------------------| | 🌐 Daily browsing | Short request/response | ✅ No conflict | | 📈 Financial charting | Low-latency stable TCP | ✅ No conflict | | 🔒 High stealth | Anti-GFW censorship | ⚠️ Potential side effects | | 🛡️ Anti-fingerprinting | Mimic normal HTTPS | ⚠️ Potential side effects | These goals are all valid. The problem is that AI coding tools are not ordinary web pages. ### 🤖 Typical AI Tool Behavior The core requirement of AI tools is not "fastest first byte" but: > Don't break the stream. Don't lose the state. Recover fast. --- ## ⚡ How Vision Breaks SSE (Representative Case Study) ### 🎯 Conflict Matrix Certain TCP/TLS links engineered for stealth (e.g., XTLS-Vision) work great for browsing but produce fatal side effects for SSE: | Dimension | What Vision Does | What SSE Needs | Conflict | |-----------|-----------------|----------------|----------| | TLS record merging | Merges small TLS records to eliminate "many small packets" fingerprint | SSE is token-by-token tiny-packet high-frequency pushing | Merges frames that should never be merged → data delay/loss | | Random padding | Pads TLS records to mimic normal HTTPS packet sizes | SSE heartbeats () are inherently tiny | Padding logic conflicts with heartbeat packets → state machine confusion | | Idle handling | May trigger timeout on prolonged silence | Agent thinking period: 10-30s of zero data | Misjudges connection as dead or padding interferes with recovery | | Symmetric flow assumption | Normal HTTPS is bidirectional (symmetric) | SSE is extremely asymmetric (server → client one-way burst) | Fingerprint elimination algorithms assume symmetry; SSE breaks that assumption | ### 📊 Hard Evidence > 2026-03-30: Same machine, same network — a "junk VPN" (simple tunnel) achieved zero disconnects for Antigravity; VLESS+Vision disconnected within 1-5 seconds. This directly proves the issue is in Vision's TLS-layer manipulation, not TCP itself. --- ## 🌐 Not Just Vision: ALL VPNs Break SSE to Some Degree > Core discovery from the 2026-04-13 routing audit Vision is merely the "extreme case." In reality, the vast majority of VPNs/proxies/middleware interfere with SSE. The differences are only in degree and mechanism: ### 🧱 Three Universal Interference Mechanisms #### 1. 📦 Proxy Buffering — The Fatal "Optimization" Most VPN nodes, proxy software (Nginx, traditional V2ray configs), and enterprise firewalls enable response buffering by default to maximize throughput and reduce fragmented packets. - VPN's perspective: A 1-byte packet is wasteful — let me buffer it until 10KB accumulates, then send it all at once - SSE's perspective: Every token the AI produces (possibly just a few bytes) must render in the UI immediately - 💥 Conflict: Frontend appears "frozen," then a massive block of text suddenly pops in. If buffering lasts too long → timeout → stream killed > Global evidence: Nginx defaults to . Azure APIM, YARP, Traefik — all require explicit configuration to avoid breaking SSE. #### 2. ⏳ Aggressive Idle Timeouts Most VPN providers enforce strict TCP/UDP idle timeout policies (typically 30-60 seconds of silence → connection recycled). - VPN's perspective: This connection has been silent for 30 seconds — must be a zombie connection, kill it - SSE's perspective: AI coding assistants routinely have 10-30 second "thinking gaps" with zero data transmission - 💥 Conflict: The AI finishes thinking and is ready to return code, but the underlying TCP connection has already been "helpfully" murdered by the VPN #### 3. 🛡️ Traffic Obfuscation & Protocol Manipulation Not only Vision manipulates TLS records — many protocols designed to penetrate the GFW (Shadowsocks variants, Reality, etc.) reassemble, encrypt-pad, and reshape data packets. - 💥 Conflict: SSE heartbeats () are tiny and high-frequency. Obfuscation mechanisms break their integrity or delay arrival → frontend state machine confusion → false death verdict ### 📊 SSE Friendliness by Protocol | Protocol/Proxy | Buffering | Timeouts | Obfuscation | SSE Friendliness | |:-:|:-:|:-:|:-:|:-:| | XTLS-Vision | 🔴 TLS merging | 🔴 May misjudge | 🔴 Random padding | ❌ Very poor | | Shadowsocks family | 🟡 Implementation-dependent | 🟡 Config-dependent | 🔴 Heavy re-encryption | ⚠️ Fair | | OpenVPN | 🔴 MTU fragmentation | 🟡 Configurable timeout | 🟡 Light | ⚠️ Fair | | WireGuard | 🟢 Kernel-level passthrough | 🟢 No connection concept | 🟢 No obfuscation | ✅ Good | | VLESS+WS (CC Worker) | 🟢 zero-buffer | 🟢 WS ping/pong | 🟢 No obfuscation | ✅★ Best | ### 💡 Universal Principle > The "smarter" the link (more features, higher stealth), the more likely it is to interfere with data in ways that break SSE's demanding single-direction streaming semantics. > > The only solution is to build a "dumb pipe" — like the CC Worker — that never touches application-layer data and never buffers. --- ## ✅ Four Key Traits of an AI-Friendly Link ### 1. 🔄 Preserves Application-Layer Streaming Semantics The link must perform byte-level passthrough of SSE frames — no merging, padding, or reordering. ### 2. ⏳ Tolerant of Long-Lived Connections AI tasks follow a "burst output → long suspend → burst output" intermittent pattern. The link must not impose idle timeout pressure. ### 3. 📡 Minor Packet Loss Doesn't Kill the Stream AI coding doesn't demand ultra-low latency, but it cannot tolerate a single jitter freezing the UI and killing the entire response. ### 4. 🔁 Fast Reconnection Recovery When disconnected, the link must recover quickly without cascading errors or requiring manual refresh. --- ## 🏆 The Solution: CC Worker (EdgeTunnel) ### 🎯 Why CC Worker Is Naturally AI-Friendly > 2026-04-13 battle test: CC Worker's clean WebSocket passthrough achieved zero disconnects for Antigravity — silky smooth. The root cause in one sentence: > Vision "tampers with" TLS and breaks SSE; CC Worker uses clean WebSocket and never touches application-layer data. ### 📐 Transport Link Comparison | Layer | CC Worker | Vision | Result | |-------|-----------|--------|--------| | TLS Encryption | Cloudflare Edge handles everything | Xray manipulates TLS records | Worker doesn't touch TLS internals | | Data Forwarding | byte-level passthrough | Processed by Vision flow-control engine | Worker performs zero merging/padding | | Random Padding | None | Yes (fingerprint elimination) | SSE heartbeats undisturbed | | Keep-Alive | WebSocket native ping/pong | Vision may misjudge timeout | Agent thinking periods pass safely | ### 📊 Five-Scenario Summary | Scenario | Vision | Hysteria2 | CC Worker | |----------|--------|-----------|-----------| | SSE Compatibility | ❌ TLS manipulation → disconnect | ✅ Doesn't touch app layer | ✅★ Clean passthrough | | Long Connection Stability | ❌ Frequent drops | ✅ QUIC keep-alive | ✅★ WS native support | | Agent Thinking Period | ❌ May trigger bug | ✅ Auto keep-alive | ✅★ Zero timeout pressure | | Decoupled from VPS | ❌ Same server | ❌ Same server | ✅★ Fully independent | | Deployment Complexity | Medium (server config) | High (UDP+certs) | Low (Worker is deployment) | --- ## 🛠️ Implementation ### 📦 CC Worker via EdgeTunnel #### Upstream Project | Item | Value | |------|-------| | edgetunnel | | | Research baseline | commit (2026-04-10) | | Nature | Cloudflare Workers/Pages edge tunnel | #### We Use Only the Minimal Layer edgetunnel is a complete "tunnel + subscription + admin panel" system. We use only its Worker tunneling capability: #### Minimum Exposure Strategy | Setting | Choice | Reason | |---------|--------|--------| | Custom Domain | ✅ Enabled | Only external entry point | | | ❌ Disabled | Don't expose hostname | | KV Binding | ❌ Off | No admin/subscription needed | | Admin Panel | ❌ Off | Reduce attack surface | | UUID | Manually fixed | Stable and controllable | #### Three Steps to Deploy 1. Fork or upload directly 2. Set environment variable = your fixed UUID 3. Bind custom domain, disable > The entire process doesn't touch your existing VPS or main nodes. CC Worker is fully decoupled. --- ## 🔀 CC Worker's Role in the Architecture ### 🏗️ Core Idea: Independent AI Channel CC Worker does not replace your existing system (Vision, Hysteria2, or whatever). It adds an independent AI-only link alongside your main system: ### 📋 Responsibility Separation | Channel | Protocol | Handles | Why | |---------|----------|---------|-----| | CC Worker | VLESS+WS via Cloudflare | AI coding dedicated link | Doesn't touch app layer, SSE natively compatible, fully decoupled from VPS | | Main Link | Any (Vision/HY2/WG etc.) | Daily/trading/gaming | Low latency, stable, covers all general scenarios | ### ⚠️ What CC Worker Should NOT Do "AI-friendly" ≠ "universal primary link." The AI channel should not handle: - ❌ Large-scale public sharing - ❌ Heavy file downloads - ❌ Full-device default gateway Its ideal role: > High-quality, low-exposure, streaming-focused AI dedicated link. --- ## 🚦 Complete Routing Rules: Flyfish v3.2 (2026-04-13 Audit Edition) ### 🎯 Design Philosophy: CC Worker Whitelist-Only > CC Worker accepts ONLY explicitly listed domains. It NEVER acts as a fallback (MATCH). > Unrecognized traffic goes to the main link (PC → DMIT Vision / Mobile → DIRECT). ### 📋 12-Level Execution Priority Rules execute top-to-bottom (highest to lowest priority). First match stops processing: | Priority | Type | Targets | Channel | Notes | |:---:|------|---------|:---:|-------| | 1 | 🧠 AI SSE long connections | Antigravity / Gemini / OpenAI / Anthropic | CC Worker | Whitelist-only, see full table below | | 2 | 🐦 X/Twitter | x.com, twitter.com, twimg.com | CC Worker | Same CC channel | | 3 | 📈 Trading | TradingView, MetaTrader, xuebz.com | DMIT Vision | Low-latency priority | | 4 | 🚫 Junk intercept | wpad | REJECT | System proxy probing, pure waste | | 5 | 🚫 Telemetry direct | exp-tas.com, events.data.microsoft.com | DIRECT | Don't waste proxy resources | | 6 | 🎮 Gaming | Steam, Epic | Hysteria2 | UDP low-latency | | 7 | 🇨🇳 Domestic domains | geosite:cn | DIRECT | — | | 8 | 🇨🇳 Domestic IPs | geoip:cn, private | DIRECT | — | | 9 | 🛡️ Ad blocking | geosite:category-ads-all | REJECT | — | | 10 | 🌐 Foreign catch-all | geosite:google, gfw, geolocation-!cn | DMIT Vision | Prevents leaking into CC Worker | | 11 | 🏠 LAN | geoip:private | DIRECT | — | | 12 | 🔄 Fallback | MATCH | DMIT Vision (PC) / DIRECT (Mobile) | Must NEVER point to CC Worker | ### 🧠 CC Worker Whitelist (Complete) > Verified via Google official firewall docs + Clash log analysis + web research #### SSE Long-Connection Domains (Must Use CC Worker) | Category | Domain | Match Type | Source | |----------|--------|:----------:|--------| | Antigravity Core | | SUFFIX | Log confirmed | | Antigravity Core | | DOMAIN | Log confirmed | | Antigravity IDE | | SUFFIX | Google official + logs | | Antigravity IDE | | SUFFIX | Log confirmed | | Gemini Code Assist | | DOMAIN | Google official whitelist | | Gemini API | | DOMAIN | Google official | | Gemini Frontend | | DOMAIN | Google official | | OpenAI (all) | , , | SUFFIX | — | | OpenAI resources | , | SUFFIX | — | | Anthropic (all) | , , | SUFFIX | — | #### Google Auth/Support Chain (OAuth2 + MCP Stability) | Category | Domain | Match Type | Source | |----------|--------|:----------:|--------| | Auth | | DOMAIN | Google official | | Project mgmt | | DOMAIN | Google official | | User info | | DOMAIN | Google official | #### Domains That Do NOT Need CC Worker (Antigravity-Related) | Domain | Type | Route | Reason | |--------|------|:-----:|--------| | | Short connection | DMIT | Update check, single round-trip | | | REST API | DMIT | MCP GitHub, short connection | | | HTTP download | DMIT | Extension marketplace, short connection | | | Short connection | DMIT | Telemetry reporting | #### Domains That Do NOT Need CC Worker (Gemini Auxiliary) | Domain | Type | Route | Reason | |--------|------|:-----:|--------| | | Static assets | DMIT (geosite:google) | Fonts/JS/CSS — instant via DMIT | | | Static assets | DMIT (geosite:google) | Images/content — instant via DMIT | > 📌 Hybrid Strategy: Gemini web's SSE stream goes through CC Worker (no disconnects), static resources go through DMIT (instant load). Best of both worlds. ### 🚫 Mandatory Junk Traffic Rules | Domain | Action | Reason | |--------|:------:|--------| | | REJECT | System WPAD auto-proxy probing, fires every few seconds | | | DIRECT | Microsoft experimentation/telemetry | | | DIRECT | Windows activity history | | | DIRECT | VS Code / Antigravity telemetry | ### 🔧 Maintenance SOP: New AI Domain Discovery 1. Open Clash log window, search for or process names 2. Find lines matching 3. Extract domain → add to top of AI whitelist in all three config files 4. Update this document's whitelist table 5. Reload Clash configuration --- ## 📈 Hysteria2's Role Change The original reason for introducing Hysteria2: - The primary link (Vision) was hostile to AI streaming - A better channel for long connections and streaming was needed With CC Worker, this need is now elegantly solved: | Date | HY2 Role | Driver | |------|----------|--------| | Pre 2026-03-30 | ❌ Vetoed | "UDP latency too unpredictable for trading" | | 2026-03-30 | 🔴 AI lifeline | Vision+SSE incompatibility proven | | 2026-04-13 | 🟢 Demoted to backup | CC Worker fully solves AI disconnect | > Hysteria2 didn't lose value — the urgency of "jamming it into the main system to save AI" disappeared. CC Worker proved that the root cause of AI disconnects is Vision's TLS manipulation, not TCP vs UDP. A "dumb but clean" WebSocket pipe is all it takes. --- ## 🧬 Core Insight > The "smarter" the protocol (Vision, Reality), the more likely it conflicts with special application-layer patterns. > The "dumber" the protocol (WireGuard, SOCKS5, WebSocket passthrough), the better the compatibility. > ALL VPNs/proxies break SSE to some degree — Vision is just the most extreme case. This is not theoretical — it's battle-tested: - ❌ Vision TLS manipulation → SSE disconnect (extreme) - ⚠️ Most VPNs → buffering/timeouts/obfuscation all interfere with SSE at varying degrees - ✅ Junk VPN simple tunnel → AI zero disconnect (but unstable) - ✅★ CC Worker clean WS passthrough → AI zero disconnect + silky smooth (optimal solution) > The optimal solution for AI coding may not be on your primary link. > > Often, the real upgrade is not making the main system more complex, but pulling out a dedicated link that understands AI. > > For hybrid scenarios (e.g., Gemini web), the correct strategy is to route SSE streams through CC Worker and static resources through DMIT — not a one-size-fits-all approach. This is the core value of the AI-Friendly Routing architecture. --- ## 📚 Global Evidence (2026-04-13 Research) All evidence below comes from independent third-party sources, cross-validating every core conclusion in this document. ### Evidence 1: XTLS Vision + SSE Incompatibility Is a Known Issue > Source: GitHub Xray-core Issues / Community | External Finding | Correlation to This Document | |-----------------|----------------------------| | XTLS Vision's Splice mechanism merges/pads TLS records to eliminate fingerprints | ✅ Matches §3 "Vision breaks SSE" root cause analysis | | SSE is incremental push on persistent HTTP — extremely sensitive to mid-layer buffering/merging | ✅ Matches "TLS record merging" row in conflict matrix | | Vision's flow control assumes bidirectional symmetric communication; SSE's extreme one-way push breaks this | ✅ Matches "Symmetric flow assumption" row | | Community recommends XHTTP to replace Vision for streaming compatibility | ✅ Our CC Worker (WS) is a production implementation of the same idea | > Conclusion: Vision's hostility to SSE is not a one-off bug — it is an architectural conflict. --- ### Evidence 2: Proxy/Middleware Buffering Is the #1 SSE Stream Killer > Source: GitHub Issues, StackOverflow, ServerFault, Stackademic | External Finding | Correlation to This Document | |-----------------|----------------------------| | Nginx defaults to , buffering SSE into large chunks → client experiences "freeze" | ✅ TLS record merging is essentially protocol-level buffering | | Fix: + + | ✅ CC Worker's is inherently unbuffered, equivalent to | | Azure APIM, YARP, Traefik all require special config to not break SSE | ✅ Validates the universal rule: "more middleware processing → more likely to break streaming" | > Conclusion: Any "hands-on" middleware is an SSE enemy. CC Worker's clean passthrough is the correct direction. --- ### Evidence 3: Cloudflare Workers WebSocket Natively Supports Streaming > Source: Cloudflare Official Documentation | External Finding | Correlation to This Document | |-----------------|----------------------------| | Workers use API to create client/origin paired connections | ✅ edgetunnel uses exactly this API | | Worker WebSocket mode passes data frame-by-frame without bulk buffering | ✅ Technical foundation for byte-level passthrough | | SSE in Workers is standard HTTP streaming — Workers natively support streaming output | ✅ CC Worker requires zero extra config for SSE compatibility | | Cloudflare recommends for SSE and disabling cache | ✅ edgetunnel doesn't use CDN cache, naturally compliant | > Conclusion: Cloudflare Workers' platform characteristics make it the ideal SSE passthrough carrier. --- ### Evidence 4: ChatGPT / Claude SSE Streams Universally Break on VPN/Proxy > Source: Reddit, Medium, IndieHackers, StackOverflow, ServiceStack | External Finding | Correlation to This Document | |-----------------|----------------------------| | Massive user reports: ChatGPT/Claude streaming stutters or disconnects through VPN | ✅ Matches our Vision+Antigravity battle experience | | Primary causes: proxy idle timeout (30-60s), TCP half-open connections, middleware buffering | ✅ Vision's TLS manipulation is a variant of "middleware buffering" | | WireGuard more stable than OpenVPN for long connections | ✅ Validates "simpler protocol → less likely to break stream" | | Fixes: heartbeat keep-alive, disable obfuscation mode, lower MTU | ✅ CC Worker WS ping/pong natively satisfies keep-alive | | Enterprise SSL inspection (MITM) proxies are equally fatal to SSE | ✅ Validates the universal principle: "all middleboxes are SSE enemies" | | Xray community recommends XHTTP over Vision for streaming | ✅ Our CC Worker (WS) is a production implementation of the same idea | > Conclusion: AI tools + VPN/proxy = universal pain point, not limited to Vision. We aren't the only ones affected, but we found the optimal solution. --- ### Evidence 5: QUIC vs WebSocket in LLM Streaming Scenarios > Source: Medium, Lightyear.ai, WebSocket.org, Ably.com | Dimension | WebSocket (TCP) | QUIC/HTTP3 (UDP) | |-----------|----------------|------------------| | Production reliability | ⭐⭐⭐⭐⭐ Industry standard | ⭐⭐⭐ Still maturing | | HoL blocking | ❌ TCP-level | ✅ Stream-independent | | Connection migration | ❌ Not supported | ✅ WiFi/4G switch without drop | | Browser support | ✅ Full | ⚠️ WebTransport still in progress | Correlation to this document: - QUIC is theoretically superior (HoL elimination + connection migration), but WebSocket is the most mature and reliable streaming channel in today's ecosystem - This explains why CC Worker (WS) delivers more stable AI experience than HY2 (QUIC) — not because QUIC is theoretically inferior, but because the proxy layer handles WS more transparently - WebSocket is a first-class citizen on Cloudflare Workers; QUIC cannot run natively on Workers > Conclusion: In proxy environments, WebSocket's "dumb but reliable" beats QUIC's "powerful but complex." --- ### Evidence 6: edgetunnel Community Validation > Source: GitHub (), SourceForge | External Finding | Correlation to This Document | |-----------------|----------------------------| | Project stars growing steadily, active community | ✅ Solution has broad user base | | Core capability: VLESS/Trojan via WebSocket on Cloudflare Edge | ✅ Exactly the same kernel we use | | No VPS, no port, no certificate required | ✅ Technical foundation for full VPS decoupling | | Community explicitly states this is not a high-security solution, but suitable for lightweight proxy | ✅ Matches our "minimum exposure strategy" — AI-only link, not universal gateway | > Conclusion: Our CC Worker solution is not an isolated experiment — it's a community-validated, mature path. --- ### 📊 Evidence Summary > Six independent evidence chains — from Xray community → Cloudflare official → LLM user community → protocol theory — cross-validate every core conclusion in this document. > > This is not a speculative technical article. It is an engineering conclusion forged in battle and independently verified by sources across the entire internet.