代理能打游戏吗：UDP、NAT 类型与游戏加速器的本质区别

摘要：「开了代理能不能打外服」「节点测速 50ms，进游戏却 150ms」「主机联机总显示 NAT 严格」——这些问题背后是同一件事：游戏流量和网页、视频流量的性质完全不同。游戏以 UDP 小包为主，要的是低延迟、低抖动、低丢包，而通用代理和机场节点主要围绕 TCP 大流量设计。本文梳理各代理协议承载 UDP 的方式、NAT 类型如何被代理链路改变、机场打游戏体验差的结构性原因，以及游戏加速器与通用代理的本质区别，最后给出配置与测试方法。

先说结论：能，但有条件

用代理打游戏行不行，取决于下面几个条件是否同时满足：

回合制、卡牌、MMO 等对延迟容忍度较高的游戏，一个离游戏服务器近、支持 UDP 的节点通常够用；FPS、格斗、MOBA 等竞技游戏，通用代理很难稳定达到理想状态，专门的游戏加速器更合适。

游戏流量有什么不一样

以 UDP 为主，小包高频

实时对战中，客户端和服务器要持续同步位置、朝向、技能、命中判定等状态。服务器以固定频率（tick rate）推进游戏世界并下发快照，从每秒几十次到一百多次不等。每个包通常只有几十到几百字节，总带宽一般只有几十到几百 Kbps。

这类数据几乎都走 UDP，因为过期的数据没有重传的价值。100 毫秒前的位置丢了就丢了，下一个包马上带来更新的状态；如果像 TCP 那样坚持等重传，后面的新数据都得排队，画面反而卡住。游戏引擎一般在 UDP 之上自行实现需要的可靠性（例如只对关键事件确认重发），其余数据允许丢失。

登录、商店、聊天、补丁下载则多走 TCP（HTTPS），而且往往和对局流量连向不同的服务器，这一点在分流时很重要。

敏感的是延迟、抖动、丢包，不是带宽

所以，「测速能跑满的节点」不等于「适合打游戏的节点」。视频和下载要的是管道粗，游戏要的是管道短、平稳、不漏。一条晚高峰抖动 ±50ms、丢包 3% 的大带宽线路，看视频靠缓冲大多还能凑合（服务端使用 BBR 等不以丢包为主要信号的拥塞控制时影响更小），打 FPS 却几乎不可用。延迟与带宽的区别见 速度慢的常见原因与优化思路。

代理协议如何承载 UDP

原生 UDP 转发：Shadowsocks

Shadowsocks 的 UDP Relay 把每个 UDP 包单独加密，仍以 UDP 包的形式发给服务端，服务端解密后代为发往目标，相当于在远端做了一次 NAT。每个包独立传输，丢一个就是丢一个，不影响后续数据，行为与直连 UDP 基本一致。代价是这些包没有任何伪装，更容易受运营商 UDP 策略影响。

mihomo 的 SS 节点另有 udp-over-tcp 选项（默认关闭），可在 UDP 不通的网络里把 UDP 塞进 TCP 传输。但它是 SagerNet 自定义的 UoT 协议，sing-box 文档明确说明它不属于 Shadowsocks 标准，兼容表只列出 sing-box、Clash.Meta（mihomo）和 Shadowrocket。服务端也必须实现它（例如 sing-box 服务端），Xray、shadowsocks-rust 等常见 SS 服务端并不支持，对这类节点贸然开启反而会让 UDP 完全不通；开启后也同样会遇到下文所说的队头阻塞。

UDP over TCP：VMess / VLESS / Trojan

这三种协议通常跑在 TCP（加 TLS）之上，UDP 只能被切成带长度前缀的帧塞进 TCP 连接，即 UDP over TCP（UoT）。即使 VMess / VLESS 换用 mKCP、HTTP/3 等传输层，UDP 也仍装在可靠、有序的流里传输，本质上还是 UoT 式的封装。Trojan 的 UDP ASSOCIATE 命令、Xray 的 XUDP 都属于这一类。

XUDP 是 Xray 对 Mux.Cool 的扩展，在帧元数据里附带 UDP 的地址和端口，让 VLESS / VMess 的 UDP 能实现 FullCone（完全锥形）行为。按 Xray 项目的说明，客户端与服务端均为 Xray-core v1.3.0 及以上时默认启用。客户端这一侧：mihomo 与 sing-box 的 VLESS 默认即使用 XUDP；mihomo 的 VMess 需写 packet-encoding: xudp 显式开启。v2ray 5+ 与 sing-box 还支持另一种按包携带地址的编码 packetaddr，两端必须一致。但要分清：XUDP 解决的是 NAT 行为，不是时延，只要底层是可靠有序的流，就逃不开队头阻塞。

基于 QUIC 的 UDP：Hysteria2 / TUIC

Hysteria2 的协议规范要求 UDP 包通过 QUIC 的不可靠数据报（unreliable datagram）发送：丢了不重传，也不阻塞后续数据报，语义与原生 UDP 一致，外层仍是加密的 QUIC 连接。TUIC 的 udp_relay_mode 默认 native，也可切到 quic（用 QUIC 流做无损转发，开销更大，对游戏反而不利）。

两者的原理见 Hysteria2 与 TUIC 和 Hysteria 2 协议详解。补充一点：Brutal 拥塞控制解决的是吞吐量，而游戏几乎不需要带宽，所以 Hysteria2 对游戏的价值在于「数据报语义、无队头阻塞」，而不是「暴力加速」。

WireGuard 则是三层隧道，直接封装 IP 包并用 UDP 传输，没有 UoT 问题，但特征明显、不做伪装，跨境稳定性难以保证。

队头阻塞：UoT 为什么会让游戏「瞬移」

TCP 保证按序交付。假设装着游戏数据的第 10 个 TCP 段丢失：

1. 第 11 个段已到达，但必须等第 10 个段重传成功才能交给上层
2. 重传至少要多等一个 RTT；游戏是稀疏的小包流，丢包后往往没有足够的后续段凑齐快速重传所需的 3 个重复 ACK。现代 Linux 等系统的 TCP 会用 RACK 与尾部丢包探测（TLP，约 2 个 RTT 后发出探测包）补救，探测也失败时才要等超时重传，Linux 默认最小重传超时为 200ms
3. 这段时间游戏收不到任何新数据，重传完成后积压的包一次性涌出

体现在画面上就是对手先「定住」再「瞬移」，自己的操作被回滚。原生 UDP 或 QUIC 数据报下，丢掉的那个包会被游戏的插值和预测掩盖。丢包率越高差距越大；几乎不丢包的线路上，UoT 尚可接受。

对比表

关键结论：UDP 友好的协议只有在「UDP 本身畅通」时才有优势。如果运营商晚高峰对跨境 UDP 限速或大量丢包，Hysteria2 可能反而不如走 TCP 的 VLESS。实际做法是同一地区备好 UDP 系和 TCP 系两种节点，实测对比，协议整体取舍见 主流代理协议横向对比。

NAT 类型：主机联机成败的关键

经典四种类型与 RFC 4787

NAT 类型决定了「外面的人能不能主动连进来」。RFC 3489 把 NAT 分为四种，国内玩家常称 NAT1 到 NAT4；后来的 RFC 4787 改用「映射行为 + 过滤行为」两个维度描述：

• 映射行为：同一个内网源端口访问不同目标时，是否复用同一个公网端口。「与端点无关」（Endpoint-Independent）即复用，对方看到的地址稳定，可以打洞
• 过滤行为：是否接受从没联系过的外部地址发来的包

不少主机游戏的联机对战采用 P2P：玩家之间直接交换数据，服务器只负责匹配。双方 NAT 都严格时打洞失败，就会「匹配到了却连不上」「进不了好友房间」。

主机上的 NAT 类型

三家主机厂商各用一套标签，判定逻辑并未公开，下表只是大致对应：

• PlayStation 的 Type 1 指主机直接拿到公网地址，Type 2 指在路由器之后但仍可被连入，Type 3 受严格限制；官方远程游玩排障页提到 Type 3 可能导致无法使用 Remote Play
• 任天堂官方说明中 Switch 的 NAT 类型为 A、B、C、D、F（没有 E）：A 最利于联机，D 一般只能与 A 连接，F 基本无法与其他玩家连接
• Windows 上部分 Xbox 网络多人游戏（官方举例 Forza Horizon 3、4）使用 Teredo（把 IPv6 封装进 UDP 的隧道），拿不到 Teredo 地址时，Windows 上的 Xbox 网络设置会把 NAT 类型显示为「Teredo 无法取得资格」。Xbox 支持文档指出，部分 VPN 客户端在连接期间会禁用 Teredo，安装了虚拟网卡的 VPN 客户端甚至可能在网卡移除前一直禁用它

代理如何改变 NAT 类型

很多人忽略的一点：游戏流量走代理后，对方看到的不是你家路由器的 NAT，而是整条代理链路的 NAT 行为。于是：

• 家里处于运营商大内网（CGNAT）、本地常测出端口受限（NAT3）甚至对称型（NAT4）的用户，走一条完全锥形的代理链路，反而可能得到更开放的 NAT 类型
• 家里有公网 IP、路由器开启了 UPnP 或 Full Cone NAT、本来是 NAT1 的用户，走一条对称型链路，NAT 类型反而变差

注意，有公网 IP 不等于 NAT1：家用路由器常见的 Linux 地址伪装（MASQUERADE）通常表现为端点无关映射加上与地址和端口相关的过滤，也就是 NAT3，开启 UPnP 端口映射、Full Cone NAT 或 DMZ 后才接近 NAT1。

整条链路要表现为锥形，每一环都不能把行为「对称化」：

直接运行 mihomo 内核时，在配置文件的 tun 段写：

1
2
3
4
5
6
7
8
9

tun:
  enable: true
  stack: mixed                     # 官方：无使用问题时建议 mixed，默认 gvisor
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
  udp-timeout: 300                 # UDP 会话过期时间（秒），默认 300
  endpoint-independent-nat: true   # 默认 false，官方提示性能可能略降

Clash Verge Rev 等图形客户端里，tun.enable 由界面开关决定，stack、auto-route、auto-detect-interface、dns-hijack、strict-route 等以 TUN 设置对话框里保存的值为准，写进 YAML 不会生效；直接改订阅文件也会在下次更新后丢失。做法是在设置页开启 TUN，再把下面两行写进「全局扩展配置」或订阅的扩展配置：

1
2

tun:
  endpoint-independent-nat: true

处理链与被界面接管的字段见 mihomo 配置文件逐段详解，扩展配置的写法见 如何自定义规则。

sing-box 旧的 endpoint_independent_nat 自 1.11.0 起已不再生效，可以删除。1.14.0 起改由 TUN 等入站上的 UDP NAT 字段 udp_mapping / udp_filtering 控制，两者默认都是 endpoint_independent，一般不需要写。1.13 及更早的内核不认识这两个字段，会报 json: unknown field 并拒绝启动，使用内置 sing-box 的图形客户端时请先确认内核版本。另外，sing-box 1.15（写作时处于 alpha 阶段）已将 TUN 的 stack 字段标记为弃用，升级前请以官方文档为准。

为什么「机场 + 游戏」经常体验差

物理距离决定延迟下限

光在光纤中的速度约为真空光速的三分之二，约每毫秒走 204 公里，所以两地大圆距离每 100 公里，往返延迟至少约 1ms：上海到香港约 12ms、到东京约 17ms、到洛杉矶约 102ms。完整的下限表与推导见 延迟测试数字的含义。

实际光缆不走直线，还有路由转发和排队，真实延迟通常明显高于下限。任何代理、加速器都不可能突破这个下限，只能让实际路径尽量接近它。「国内玩美服 30ms」在物理上就不成立。

节点离游戏服务器远：三角路由

走代理时，总延迟约等于「你到节点」加上「节点到游戏服务器」。客户端显示的延迟只覆盖前半段，而且测的是 HTTP 请求耗时而非 UDP 往返，详见 延迟测试数字的含义。

例如游戏服务器在东京，你选了显示 40ms 的香港节点，香港到东京还要几十毫秒，总延迟可能高于显示 60ms 的日本节点。选节点要看游戏服务器在哪，而不是哪个数字最小。

运营商 QoS 与晚高峰

• UDP QoS：运营商不公开 QoS 策略，但跨境 UDP 在部分地区、部分时段被限速或丢包上升（不少用户反馈移动网络下更明显），是 UDP 系协议用户常遇到的情况，本站 QUIC 协议 一文也有讨论。这直接打击了游戏依赖的 UDP 优势
• 超售与晚高峰：节点多人共享，晚高峰带宽被视频和下载占满时，缓冲队列变长，表现为抖动和丢包，对下载只是慢一点，对游戏则是频繁卡顿。线路等级差异见 直连 vs 中转 vs CDN

节点根本不通 UDP

以下情况都会造成「能登录、不能开局」：

• 服务端关闭了 UDP 转发，例如 Hysteria2 服务端配置了 disableUDP
• 中转机只转发了 TCP 端口（参见 端口转发与中转）
• 客户端节点没开 udp：mihomo 中大多数协议的 udp 字段默认为 false，只有 TUIC 等基于 UDP 的协议默认开启
• CDN 类节点（如 WebSocket 经 Cloudflare）只能 UoT，本身延迟也偏高

自动切换与共享 IP

• url-test 策略组会在延迟波动时自动换节点：已建立的 UDP 会话一般仍留在旧节点，但对局中新建的会话（重连、切换房间、语音）会从另一个出口 IP 发出，游戏服务器可能判定为掉线或要求验证；部分图形客户端还提供「切换节点时断开旧连接」一类的选项，会直接打断对局
• 机场出口 IP 由大量用户共享，同一 IP 上有人作弊或滥用时，游戏方可能对该 IP 限流、要求验证甚至封禁

游戏加速器到底加速了什么

国内常见的游戏加速器（如网易 UU、雷神、迅游等）和通用代理都是「把流量绕到别处再发出去」，但设计目标差别很大：

1. 只接管游戏流量：按游戏进程和游戏服务器 IP 段列表截获流量（常见做法是驱动层虚拟网卡或过滤驱动），网页、视频不会被带着绕路
2. 专用游戏线路：在游戏服务器附近部署出口，入口到出口多为选路优化过的中转或专线，追求贴近物理下限的延迟和低抖动，而非大带宽
3. 就近接入：入口节点分布在国内各地、各运营商，跨境段交给优化线路
4. 围绕 UDP 设计：部分产品还提供多链路冗余发包之类的抗丢包功能
5. 主机方案：通过路由器插件、手机热点、电脑共享或专用硬件接管主机流量，部分产品把「突破 NAT 限制」作为卖点

适合加速器的场景：竞技类外服游戏（FPS、MOBA、格斗）；主机 P2P 联机且 NAT 问题自己解决不了；用代理实测延迟明显高于直连或抖动很大。

通用代理通常够用的场景：对延迟容忍度较高的游戏；游戏服务器恰好在你的优质节点所在地区；只需访问外服商店、社区或下载更新（TCP 流量，正是代理擅长的）。

实操：让游戏流量正确地走代理

电脑：TUN + UDP + 按进程分流

1. 必须开 TUN：游戏客户端基本不读系统代理。系统代理只是供应用自行读取的设置，遵守它的基本只有浏览器等 HTTP(S) 流量；SOCKS5 虽然定义了 UDP ASSOCIATE，但游戏不会主动用它发 UDP。原理见 TUN 模式 vs 系统代理，开不起来参考 TUN 模式不生效的常见原因
2. 确认节点开启 UDP：在客户端「连接」页面看游戏进程有没有 UDP 连接、走的哪个节点
3. 建专用游戏策略组，用手动选择，按进程分流。下面的 proxies 只示意节点需要带哪些字段（udp: true、packet-encoding），机场用户不要照抄节点：保留订阅里的节点，把 Game 组的 proxies 换成订阅中的节点名，再通过扩展配置或覆写脚本注入策略组和规则：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

proxies:
  - name: JP-Hy2
    type: hysteria2
    server: jp1.example.com
    port: 443
    password: your-password
    udp: true
  - name: JP-VLESS
    type: vless
    server: jp2.example.com
    port: 443
    uuid: your-uuid
    udp: true
    packet-encoding: xudp   # mihomo 的 VLESS 默认已是 xudp，可省略；VMess 需显式写出。服务端需支持 XUDP

proxy-groups:
  - name: Game
    type: select            # 手动选择，避免对局中自动切换
    proxies: [JP-Hy2, JP-VLESS, DIRECT]

rules:
  - PROCESS-NAME,YourGame.exe,Game   # 以任务管理器「详细信息」中的名称为准
  # ……以下为订阅原有规则

• 游戏流量只有在 TUN 下才会进入 mihomo，所以这条 PROCESS-NAME 规则要配合 TUN 才对游戏生效（进程识别本身并不限于 TUN，经系统代理进来的本机连接同样能匹配）；mihomo 的 find-process-mode 默认 strict，由内核自行判断是否查找进程，不要设为 off。在软路由 / 旁路由上代理其他设备时拿不到进程信息，只能按 IP 分流
• 使用订阅的用户可通过客户端覆写功能注入规则，避免更新后丢失，见 如何自定义规则
• sing-box 用路由规则的 process_name 字段实现同样效果（仅 Linux、Windows、macOS），Android 上改用 package_name
• 国服游戏及其反作弊组件一律 DIRECT，走代理只会徒增延迟

4. 游戏需要 P2P 联机（好友房、部分游戏的组队）时：按上文「代理如何改变 NAT 类型」开启端点无关 NAT，再用下文「测 NAT 类型」的方法确认映射与过滤均为 Endpoint Independent

主机：借助网关设备

PlayStation、Switch 网络设置里的「代理服务器」（HTTP 代理）一般只对商店、下载等 HTTP 类流量生效，联机对战的 UDP 不会走它，NAT 类型也不会改善；Xbox 则没有这一项。要让对战流量走代理，需要把主机的网关指向能透明代理 UDP 的设备：

1. 准备网关：软路由或旁路由，部署见 软路由与旁路由。只有一台 Windows 电脑时，也可以开启系统的「移动热点」让主机连接，再在电脑上开 TUN；热点转发的流量能否被 TUN 接管取决于客户端和系统版本，务必用第 4 步验证。注意客户端的「局域网连接」只是让别的设备把本机当 HTTP / SOCKS 代理，不是网关，游戏的 UDP 不会走它
2. 透明代理必须包含 UDP：OpenClash 等插件中的 UDP 转发类选项要打开
3. 给主机固定 IP，便于单独写规则，例如 SRC-IP-CIDR,192.168.1.50/32,Game
4. 验证：在主机的网络设置里运行连接测试，确认能连上、NAT 类型没有比直连时变差

手游

• 手机客户端通过系统 VPN 接口工作，本身相当于 TUN，UDP 能否用同样取决于节点
• Android 上 mihomo 的 PROCESS-NAME 可以匹配应用包名，也可以用客户端的「分应用代理」；iOS 客户端通常拿不到发起连接的应用信息，只能按域名 / IP 分流
• 不少用户反馈移动网络下跨境 UDP 更不稳定（运营商不公开相关策略），同一节点在 Wi-Fi 与 5G 下可能差很多，建议分别实测；部分游戏会检测设备是否处于 VPN 状态

各平台客户端的选择见 2026 各平台客户端推荐。

测试方法：用数据判断问题在哪

找到对局服务器

开 TUN 进入一局对战，在客户端「连接」页面按进程筛选，找到游戏进程 UDP 连接的目标 IP，再查归属地与 AS（方法见 AS 号与 IP 归属查询）。注意登录、商店的 TCP 连接往往指向另一批服务器，对局用的 UDP 服务器才是选节点的依据。

分段测延迟

先关掉 TUN 测直连基线；自建 VPS 的用户再登录节点，测节点到游戏服务器的延迟（203.0.113.10 换成实际 IP）：

1
2
3

# Windows：直连基线（先关闭 TUN）
ping -n 50 203.0.113.10
pathping -n 203.0.113.10      # 逐跳统计丢包，需等待几分钟

1
2
3
4

# Linux / 节点 VPS 上执行；macOS（Homebrew 安装的 mtr）需在前面加 sudo
mtr -rwzc 100 203.0.113.10       # 报告模式，100 轮，显示 AS 号
mtr -u -rwzc 100 203.0.113.10    # 改用 UDP 探测，可对照中间路由对 UDP 的处理；终点通常不回应，最后一跳显示丢包不代表不通
nexttrace 203.0.113.10           # 显示每一跳的地理位置与运营商

• 除了平均值，更要看最大值、波动和丢包率：平均 60ms、最大 65ms 的线路，比平均 45ms、最大 200ms 的更适合打游戏
• mtr 中间某跳丢包而后续正常，通常只是该路由器限制了 ICMP 回应，延续到终点的丢包才有意义
• 机场用户无法登录节点，只能开着 TUN 在游戏内切换不同节点，对比游戏显示的延迟与丢包，以此代替「节点到服务器」这一段的测量
• 开着 TUN 时不要用 ping 判断代理延迟：SS、VMess、VLESS、Trojan、Hysteria2、TUIC 等代理协议不承载 ICMP，mihomo 等客户端的 TUN 下 ping 通常要么被本地应答，要么由本机直连发出，数字不代表经代理的真实路径。WireGuard 这类三层隧道是例外，sing-box 1.13 起也能把 TUN 进来的 ping 转发到 WireGuard / Tailscale 出站
• 游戏内置的网络统计才是最终标准

测 NAT 类型

电脑上可用开源工具 NatTypeTester，它基于 STUN，按 RFC 5780 给出映射行为和过滤行为：

1. 开启 TUN，让该工具的流量走游戏节点，例如临时加一条 PROCESS-NAME,NatTypeTester.exe,Game（进程名以实际为准）
2. 映射和过滤都显示 Endpoint Independent，即相当于完全锥形；映射为 Endpoint Independent、过滤为 Address and Port Dependent，则是端口受限锥形
3. 关掉 TUN 再测一次得到本地宽带的 NAT 类型，两次对比即可看出代理链路的影响

这类测试需要支持 RFC 5780 的 STUN 服务器（有两个 IP、各监听两个端口）。结果显示 UnsupportedServer 或过滤测试失败时，先在工具里换一个 STUN 服务器再测，不要直接归咎于代理链路。

主机直接用系统设置里的网络连接测试查看 NAT 类型。

排查清单

风险提示

• 服务条款：不少游戏平台禁止用代理伪装所在地区。例如 Steam 订户协议要求用户不得通过 IP 代理等方式掩饰居住地，无论是为了绕过地区限制、以其他地区价格购买还是其他目的，违反者可能被终止账户。跨区购买、跨区激活的风险远高于单纯降低延迟
• 反作弊误判：频繁在不同国家 IP 间切换、使用被大量账号共享的出口 IP、驱动层网络工具与反作弊组件冲突，都可能触发风控，轻则验证，重则封禁；各游戏策略不同且通常不公开
• 账号地区：部分账号与注册地区绑定，登录 IP 长期与账号地区不一致可能带来额外验证或限制
• 安全：来路不明的「游戏专用节点」「免费加速器」同样能看到你的流量元数据

本文只讨论网络原理。是否用代理玩某款游戏、愿意承担什么风险，请自行阅读该游戏的用户协议后评估。

常见问题（FAQ）

开了 TUN 之后游戏延迟反而更高，正常吗？

如果游戏服务器在国内或离你很近，走代理必然绕路，这类游戏应设为 DIRECT。如果是外服，先检查节点和服务器是否同地区；再试试切换 TUN 协议栈（gvisor、system、mixed），个别游戏在不同栈下表现不同，参考 Sing-box TUN vs Clash Verge TUN。

客户端显示节点 50ms，为什么游戏里是 150ms？

客户端测的是经节点访问测试网址的 HTTP 请求耗时，与游戏的 UDP 往返是两回事，也不包含节点到游戏服务器那一段。以游戏内显示和分段测试为准。

Hysteria2 是不是打游戏最合适的协议？

不能一概而论。它的数据报语义适合游戏，但前提是网络不对跨境 UDP 限速；晚高峰 UDP 丢包严重时，基于 TCP 的 VLESS 反而更稳。Brutal 针对吞吐量，对小包游戏帮助有限，带宽参数按实际线路填写即可。

主机能不能直接在网络设置里填代理服务器？

PlayStation 和 Switch 可以填（Xbox 没有这一项），但一般只影响商店、下载等 HTTP 类流量，联机对战的 UDP 不走它，NAT 类型也不会改善。需要软路由、旁路由或开启热点并运行 TUN 的电脑充当主机网关。

NAT 类型测出来是对称型，怎么改善？

先分清是哪一段造成的。本地宽带是对称型（部分运营商大内网如此），先向运营商申请公网 IP（常见做法是光猫改桥接、由路由器拨号），再在路由器开启 UPnP 或 Full Cone NAT；仍在大内网时只开 UPnP 无效。也可以让游戏走一条锥形代理链路。代理链路是对称型，就逐项检查：客户端是否开启端点无关 NAT、VLESS / VMess 是否用 XUDP、机场是否经过改写映射的中转或负载均衡；如果测出来是端口受限，再检查服务端防火墙 / 安全组是否放行陌生地址发来的入站 UDP（不只是回包）。机场节点无法调整服务端，只能换节点或换方案。

游戏加速器和代理客户端能同时开吗？

不建议让两者同时接管同一个游戏。它们都可能用虚拟网卡或驱动截获流量，路由冲突会导致不通或延迟异常。确需同时运行，在代理规则中把游戏进程设为 DIRECT 交给加速器；仍有冲突就在玩游戏时关闭代理的 TUN。

外部参考

• mihomo TUN 配置、代理通用字段、路由规则
• sing-box UDP NAT 字段、TUN 入站、UDP over TCP、VLESS 出站、更新日志
• Clash Verge Rev 扩展配置与脚本
• XUDP 说明、Xray-core v1.2.0 发布说明
• Hysteria 2 协议规范、Trojan 协议
• RFC 4787、RFC 3489 — NAT 行为的定义；RFC 8985 — RACK-TLP 丢包检测
• NatTypeTester、NextTrace
• Nintendo Support：NAT 类型、Xbox Support：Teredo、PlayStation Support：Remote Play 连接排障
• Steam 订户协议

站内相关文章：

• TUN 模式 vs 系统代理：原理与选择
• Hysteria2 与 TUIC：基于 QUIC 的协议
• 软路由与旁路由
• 延迟测试数字的含义