🧠 AI 友好机制-彻底解决antigravity不稳定问题

一份面向公开讨论的技术研究。

>

主题不是"哪个协议理论上最强"，而是：

为什么某些链路在交易场景无敌顺滑，却会把 AI 编程工具用成地狱；而另一条看起来更绕的链路，反而能让 AI 体验极度丝滑。

>

📅 最后更新: 2026-04-13 | 状态: 实战验证完成

📌 结论先行

在 AI 编程场景里，真正决定体验的，往往不是最低延迟，而是：

• 是否真正兼容 SSE / 长连接 / 流式输出
• 是否能扛住"长时间无输出后的继续返回"
• 是否在轻微丢包时仍然保持 UI 连续、不超时、不报错
• 是否能在断线后快速恢复，而不是整条流彻底崩掉

这会导出一个很反直觉但非常实用的结论：

一个延迟略高、但对流式交互更友好的独立链路，常常比一个低延迟的主链路更适合 AI 编程。

🔬 为什么"低延迟主链路"会在 AI 工具里翻车

💡 传统主链路的优化目标

这些目标都没有错。问题在于，AI 编程工具不是普通网页。

🤖 AI 工具的典型行为

`` 客户端发起请求 ↓ 服务器开始流式返回 (SSE / Server-Sent Events) ↓ 中间出现 10~30 秒的 "思考空窗" ↓ 恢复输出，需要沿着同一条流继续 ↓ 前端对超时、断流、卡顿极度敏感 ``

也就是说，AI 工具的核心诉求不是"极限首包速度"，而是：

流不要断，状态不要丢，恢复不要慢。

⚡ Vision 把 SSE 搞坏的根因分析（代表性案例）

🎯 冲突矩阵

某些为隐蔽性或抗审查做过深度处理的 TCP/TLS 链路（如 XTLS-Vision），在普通浏览里很好，但在 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 默认 proxybuffering on、Azure APIM、YARP、Traefik 等中间件都需要专门配置 proxybuffering off 才能不破坏 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 依赖的心跳包（: heartbeat\n\n）极小且高频，混淆机制破坏其完整性或延迟到达 → 前端状态机混乱 → 误判连接已死

📊 各协议对 SSE 的干扰程度

💡 通则

越是追求多功能、高隐蔽性的"聪明"链路，越容易自作主张地干预数据，从而破坏对连贯性要求极高的 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，根本不碰应用层数据。

📐 传输链路对比

📊 五场景对比总结

🛠️ 最佳实现方案

📦 基于 EdgeTunnel 的 CC Worker 专线

上游项目

我们只用了最克制的一层

edgetunnel 本身是一套完整的"隧道 + 订阅 + 管理后台"系统，但我们只使用了它的 Worker 隧道能力：

`` AI 编程工具 (Antigravity / Codex / Claude Code) ↓ VLESS + WebSocket 自定义域: edge.example.com ↓ Cloudflare Worker (edgetunnel _worker.js) ↓ 读取 VLESS 首包 → 解析 UUID/目标 ↓ forwardataTCP() 纯净 TCP 透传 ↓ 目标服务器 (Google / OpenAI / Anthropic) ``

最小暴露面策略

部署一条 CC 线路只需 3 步

1. fork cmliu/edgetunnel 或直接上传 _worker.js
2. 设置环境变量 UUID = 你的固定 UUID
3. 绑定自定义域名，关闭 workers_dev

整个过程不动现有 VPS、不动主线节点。CC Worker 与你的主系统完全解耦。

🔀 CC Worker 在整体架构中的定位

🏗️ 核心思路：独立 AI 通道

CC Worker 不替代你现有的主系统（无论是 Vision、Hysteria2 还是其他协议），而是在主系统之外拉出一条 专属 AI 的独立链路：

📋 职责划分原则

⚠️ CC Worker 不该做什么

"AI 友好"不等于"全能主力"。独立 AI 通道不应该被拿去承担：

• ❌ 大规模公开分享
• ❌ 大流量下载
• ❌ 全设备全场景默认总出口

它最适合的定位：

高质量、低暴露、专注流式交互的 AI 专线。

🚦 完整分流规则：Flyfish v3.2（2026-04-13 路由审计版）

🎯 设计哲学：CC Worker 白名单制

CC Worker 只接显式列出的域名，绝对不做兜底（MATCH）。

未识别流量走主线（电脑 → DMIT Vision / 手机 → DIRECT）。

📋 12 级执行优先级

规则按从上到下（优先级从高到低）执行，首次命中即停止：

🧠 CC Worker 白名单（完整版）

经 Google 官方防火墙文档 + Clash 日志实战验证 + 全网搜索确认

SSE 长连接域名（必须走 CC Worker）

Google 认证/辅助链（保障 OAuth2 + MCP 稳定性）

不需要走 CC Worker 的 Antigravity 域名

不需要走 CC Worker 的 Gemini 辅助域名

📌 混合策略：Gemini 网页的 SSE 流走 CC Worker（不断连），静态资源走 DMIT（秒加载）。两全其美。

🚫 必须拦截的垃圾流量

🔧 运维 SOP：发现新的漏网 AI 域名

1. 打开 Clash 日志窗口，搜索 antigravity_tools 或 Antigravity
2. 找到 match GeoSite(google) using Flyfish V2 的行
3. 提取域名 → 加到三个配置文件的 AI 白名单顶部
4. 同步更新本文档白名单表
5. 重载 Clash 配置

📈 Hysteria2 的角色变更

过去引入 Hysteria2 的核心原因是：

• 主链路 (Vision) 对 AI 流式交互不友好
• 需要一条更适合长连接和流式输出的替代通道

CC Worker 出现后，这个需求已被更优雅地满足：

不是 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 / 社区讨论

结论：Vision 对 SSE 不友好不是个例 bug，而是 架构级冲突。

佐证 2：代理/中间层缓冲是 SSE 断流的头号杀手

来源: GitHub Issues, StackOverflow, ServerfFault, Stackademic

结论：任何"动手脚"的中间层都是 SSE 的天敌。CC Worker 的纯净透传是正确方向。

佐证 3：Cloudflare Workers WebSocket 天然支持流式透传

来源: Cloudflare 官方文档

结论：Cloudflare Workers 的平台特性决定了它是 SSE 透传的理想载体。

佐证 4：ChatGPT / Claude 的 SSE 流在 VPN/代理下普遍断联

来源: Reddit, Medium, IndieHackers, StackOverflow, ServiceStack

结论：AI 工具 + VPN/代理 = 普遍性痛点，不限于 Vision。我们不是唯一遇到的人，但我们找到了最优解。

佐证 5：QUIC vs WebSocket 在 LLM 流式场景下的对比

来源: Medium, Lightyear.ai, WebSocket.org, Ably.com

与本文结论的关联：

• QUIC 理论上更好（HoL 阻塞消除 + 连接迁移），但 WebSocket 在当前生态中是最成熟可靠的流式通道
• 这解释了为什么 CC Worker (WS) 比 HY2 (QUIC) 在实际 AI 编程中体验更稳定——不是 QUIC 理论不行，而是代理层对 WS 的处理更透明
• WebSocket 是 Cloudflare Workers 的一等公民，而 QUIC 无法在 Workers 上原生运行

结论：在代理环境下，WebSocket 的"笨但可靠"胜过 QUIC 的"强但复杂"。

佐证 6：edgetunnel 项目的社区验证

来源: GitHub (cmliu/edgetunnel), SourceForge

结论：我们的 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 SSE / persistent connections / streaming output
• 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

These goals are all valid. The problem is that AI coding tools are not ordinary web pages.

🤖 Typical AI Tool Behavior

`` Client sends request ↓ Server begins streaming response (SSE / Server-Sent Events) ↓ 10~30 second "thinking gap" — zero data transmitted ↓ Output resumes on the same stream ↓ Frontend is extremely sensitive to timeouts, stalls, and disconnects ``

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:

📊 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 proxybuffering on. Azure APIM, YARP, Traefik — all require explicit proxybuffering off 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 (: heartbeat\n\n) are tiny and high-frequency. Obfuscation mechanisms break their integrity or delay arrival → frontend state machine confusion → false death verdict

📊 SSE Friendliness by Protocol

💡 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

📊 Five-Scenario Summary

🛠️ Implementation

📦 CC Worker via EdgeTunnel

Upstream Project

We Use Only the Minimal Layer

edgetunnel is a complete "tunnel + subscription + admin panel" system. We use only its Worker tunneling capability:

`` AI Coding Tool (Antigravity / Codex / Claude Code) ↓ VLESS + WebSocket Custom domain: edge.example.com ↓ Cloudflare Worker (edgetunnel _worker.js) ↓ Parse VLESS header → Extract UUID/target ↓ forwardDataTCP() clean TCP passthrough ↓ Target Server (Google / OpenAI / Anthropic) ``

Minimum Exposure Strategy

Three Steps to Deploy

1. Fork cmliu/edgetunnel or upload _worker.js directly
2. Set environment variable UUID = your fixed UUID
3. Bind custom domain, disable workers_dev

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

⚠️ 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:

🧠 CC Worker Whitelist (Complete)

Verified via Google official firewall docs + Clash log analysis + web research

SSE Long-Connection Domains (Must Use CC Worker)

Google Auth/Support Chain (OAuth2 + MCP Stability)

Domains That Do NOT Need CC Worker (Antigravity-Related)

Domains That Do NOT Need CC Worker (Gemini Auxiliary)

📌 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

🔧 Maintenance SOP: New AI Domain Discovery

1. Open Clash log window, search for Antigravity or process names
2. Find lines matching match GeoSite(google) using Flyfish V2
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:

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

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

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

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

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

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 (cmliu/edgetunnel), SourceForge

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.