网页能开、游戏进不去。客户端版本也没动过——问题出在节点「怎么传 UDP」。而这背后，是一对天然的矛盾。
客户在中国（移动）用 TUN／游戏模式玩《战舰世界》北美服，节点更新后所有节点都卡在「登录中」、报ネットワークエラー，但浏览网页一切正常。
能上网、进不去游戏 ＝ UDP 出了问题。游戏走 UDP，网页／登录走 TCP；实测每条线路 TCP 都通（3/3），所以问题只出在「UDP 怎么被传过去」。
游戏 UDP 要的是裸奔式直达、丢一两个包无所谓但绝不能卡；而代理为了过墙必须加密＋混淆＋走专线绕路——这层「伪装」恰恰会拖垮游戏的实时性。这就是上面那句话的核心。
客户正好踩中两个最不适合游戏的节点：① AnyTLS 节点——它是 TCP 通道，游戏 UDP 被硬塞进 TCP 顺序传输，丢一个包后面全堵（队头阻塞），表现就是卡登录。② 日本 IPLC 节点——线路本身没问题，但出口在日本，离北美服务器太远。
实测：从中国直连境外的游戏 UDP 会被墙限速／丢弃（直连探测 0 到达）；而走 IPLC 专线的 UDP 能稳定通过（实测专线上有大量真实游戏 UDP 流量）。所以「直连／GLOBAL／HY2 直连」反而不适合打游戏。
用「美国出口 ＋ IPLC 专线」的 SS 节点：既是原生 UDP、又走专线稳定过墙、出口还靠近北美服务器。这个节点本来就在客户套餐里——他只是一直没试过，反而去试了上面两个最差的。
我们已证明 UDP 能稳定到达「出口服务器」；但还没证明游戏 UDP 能从出口一路打到北美再回来。所以让客户先用这个美国 IPLC 节点实测一局，就能最终定论；若仍卡登录，那更可能是出口 IP 被战舰北美区风控，届时我们上一条干净的北美游戏专线。
整个工单期间客户端版本始终没变——所以这不是 App 的 bug。是服务端的节点重组，把客户挪到了承载不了游戏流量的节点上。
游戏对战流量走 UDP；登录／聊天／网页走 TCP。从中国侧实测，每条线路 TCP 都 3/3 通。所以不是连不上，而纯粹是 UDP 怎么被传过去。
握手能完成。浏览、车库、聊天都能用——所有节点都行，包括那些对游戏不可用的节点。
实时数据包被塞进 TCP 流，或在过境时被丢弃。登录在等它们 → 无限「登录中」。
同样的 UDP 包尝试三条路到游戏服务器。客户试的是前两条——最差的两条。
只读检查：节点配置、代理核心源码、出口抓包、以及从中国侧的探测。（本公开版已隐去网络标识。）
代理核心对 AnyTLS 无条件启用 UDP-over-TCP（没有开关）。游戏 UDP 被迫挤进一条有序 TCP 流 → 队头阻塞。
在日本出口（20 秒抓到 853 个）和美国出口（18 秒 1252 进 / 5761 出）实测到真实游戏 UDP 包，经专线中转链路。专线没问题。
两次直连境外 UDP 探测（用的是未占用端口）：零到达。而 UDP/53 对照组成功。
某日本节点的 GLOBAL 域名在中国被解析到 GFW 黑洞 IP。域名版 GLOBAL 连都连不上；裸 IP 版 GLOBAL 没问题。
AnyTLS = tcp（仅 UoT）· SS = tcp,udp（原生）· HY2 = UDP 原生。「仅 App」之类只是显示标签，不是流量限制。
只试了日本 AnyTLS 和日本 SS-IPLC——传输方式错、地区也错。一个美国出口的 IPLC SS 节点一直在套餐里没用。
stack=gvisor（默认），FakeIP 默认。测试时固定一个节点，别频繁切换。AnyTLS 是 UoT（队头阻塞）。IPLC 专线可证能承载 UDP（日本和美国都有实测抓包）。被测的直连路径会丢高端口 UDP。这些都是实测的。
抓包证明 UDP 到达了出口处的服务器——但没证明游戏 UDP 完成了 出口 → 游戏服务器 → 返回 的全程。出口延迟更能解释「卡顿」而不是硬「卡登录」。
| 节点 | 传输 | 出口 | 游戏 UDP | 结论 |
|---|---|---|---|---|
| SS-US-IPLC | SS · IPLC | 美国 | IPLC ✓（已验证） | 最佳 —— 选它 |
| SS-US（裸 IP GLOBAL） | SS · IPLC | 美国 | IPLC ✓ | 不错的备选 |
| SS-JP-IPLC | SS · IPLC | 日本 | IPLC ✓ | UDP 行，地区不对 |
| HY2-JP（直连） | HY2 · 直连 | 日本 | 直连 —— 被限速 | 移动上不稳 |
| AnyTLS-JP（直连） | AnyTLS · 直连 | 日本 | UoT —— 队头阻塞 | 游戏绝不用 |