带宽从来不是瓶颈：主机联机卡在 NAT 类型与那一个 UDP 端口上

NAT 类型的判定口径：为什么三类主机的分档名字不一样

PS5 说 1/2/3，Xbox 说开放、中等、严格，Switch 不显示类型只报错误码。名字不同，判据是同一个：外部能否主动向你的公网端口发一个 UDP 包并收到回应。

三地实测：三类主机在两种 NAT 状态下的组队与延迟

组队成功率的定义是连续发起 50 次邀请中成功进入同一局的比例，同一账号、同一时段、同一区服各测三轮，取中位。这个指标比延迟更能反映主机联机的实际体验。

表 1 里 PS5 那三行的组队成功率跨度是 36 个百分点，而中位延迟只差 12 ms。这说明主机联机的主要矛盾是可达性，不是速度：能不能连上，和连上之后快不快，是两个独立的问题。

端口开放的先后顺序：先开一个，验证，再开下一个

一次把所有端口都开掉是最常见的错误做法：出问题时无法判断是哪一条生效。逐个开放、逐个验证，两步就能定位。

1. 先确认是否处于双 NAT

   光猫拨号 + 路由器再拨号，或者运营商做 CGNAT 时，上游已经做过一次转换。此时路由器上开多少端口都没用，必须让上游把地址透传，或者直接在上游设备做转发。

2. 只开主端口，先测 PS5 或 Xbox

   PS5 先开 UDP 3074，Xbox 先开 UDP 3074 一个端口，进入游戏的网络状态页看类型是否变化。变了说明转发生效，没变说明还有一层 NAT。

3. 再补辅助端口

   Xbox 补 3478–3480 与 4500，PS5 补语音相关端口。辅助端口主要影响语音与派对，不影响能否进入对局，优先级低于主端口。

4. Switch 单独处理

   Switch 的 P2P 对端口更敏感，固定 UDP 45000–45099 一段转发，并在路由器上关掉对称型 NAT 相关的严格模式，通常能把 58% 的组队成功率推到 90%。

5. 最后才考虑加速

   端口与 NAT 都正常之后，再谈延迟。顺序反了会在错误的层面上折腾很久，实测里有相当比例的「主机联机卡」其实从未走到这一步。

三列数据卡：主机联机的三条判据

主机场景不用看抖动，也不用看带宽。三个数字就能定性：NAT 档位、组队成功率、路径类型。

• 正常

  NAT 中等或开放 · 组队 ≥ 90%

  90%

  走直连，中位 48–55 ms。这一档里再换节点收益有限，实测同一档内不同节点差异通常小于 8 ms。

• 受限

  NAT 严格 · 组队 60%–70%

  70%

  必然走中继，多一次往返。处置顺序是开端口，其次换一个能给出中等型出口的线路，最后才考虑换区服。

• 无解

  双 NAT 或 CGNAT · 组队 < 60%

  60%

  上游已经做过一次地址转换，路由器上的任何设置都碰不到它。此时要么找运营商要公网地址，要么接受中继。

三类主机的细节差异：同一条线路，三种表现

同一条 51 ms 的线路，在三台主机上体感并不一致，原因在于各自的联机模型与语音处理方式不同。分开说清楚，才知道该动哪一处。

PS5：派对语音与对局走不同的端口

PS5 的对局流量与派对语音分走不同端口，只开 3074 时能进对局但派对里听不到声音，是很常见的现象。实测中先开 3074 再补语音端口，组队成功率与语音清晰度会分两步改善，中间那一段容易被误判成「加速无效」。

Xbox：UPnP 与手工转发不要同时开

UPnP 能自动开端口，手工转发也能开，两者同时存在时会出现端口争用，表现为随机掉线。实测里把 UPnP 关掉、改用手工转发之后，掉线次数从每两小时一次降到零。反之如果路由器不支持 UPnP，就必须手工转发。

Switch：P2P 对端口范围最敏感

Switch 的联机模型更接近纯 P2P，双方都要能被对方主动发起。端口范围不固定时，成功率随机波动。实测固定 UDP 45000–45099 之后，组队成功率从 58% 升到 90%，中位延迟只降了 16 ms，改善几乎全部来自不再走中继。

• 共同点一：三类主机的联机流量都是小包高频，下行占用低于 60 Kbps。
• 共同点二：带宽升档对联机没有可测出的改善，端口与 NAT 才是变量。
• 共同点三：加速能改善的是「到中继或到对端」的路径，改不了你的 NAT 类型。
• 差异一：PS5 语音与对局分端口，Xbox 的语音走派对通道，Switch 用系统级语音。
• 差异二：Switch 对端口范围最敏感，PS5 与 Xbox 对单一主端口更敏感。
• 差异三：Xbox 的 UPnP 兼容性最好，Switch 最差，PS5 居中。

什么时候换节点有效，什么时候换也没用

主机场景里的判断比 FPS 简单：先看 NAT 档位，再看路径类型，两个都正常才轮到延迟。标「无效」的四种情形，换多少条线都不会变。

有效 · 中继路径换直连

两端本来可以直连，但因为一端出口的端口不可达而走了中继。换一个端口可达的出口，路径立刻从两跳变一跳，实测省 31 ms。

有效 · 换区服落地

港服与日服的物理距离差决定下限，51 ms 与 62 ms 的差别无法靠优化消除，只能换落地区域。

部分有效 · 严格型对严格型

两端都是严格型时，加速只能保证两边都能到达同一个中继，组队成功率会提升，但路径仍是中继，延迟改善有限。

无效 · 双 NAT 与 CGNAT

上游做过地址转换时，本地任何设置都碰不到那一层。换节点只换了出口，NAT 状态原样带过去。

无效 · 服务器侧满员

同一局里所有人同时变慢、匹配时间变长，是服务端状态，与 NAT 和路径都无关。

无效 · 手柄无线延迟

手柄蓝牙的 12 ms 与线路无关，改成有线能省 6 ms，量级比换节点更实在。

端口与验证方式对照表

下表用于快速核对，第三列是验证方式：改完之后用什么动作确认生效，比记住端口号本身更重要。

验证动作这一列是这张表的重点：主机平台的状态页刷新有缓存，改完端口不重启往往看不到变化，容易误判为「没生效」而继续改别的设置。实测里最常见的误操作就是在未重启的状态下反复调整转发规则。

三张补图：路径、矩阵与中断

主机联机的图不需要复杂，把路径与状态画出来就够。这三张图对应排查里的三个提问：为什么走中继、为什么三台表现不同、夜里那次掉线是什么。

• 走中继的判据：任意一端严格型，或端口不可达时，路径必然落到中继上。
• 三台差异的判据：语音通道与端口范围不同，同一线路表现自然不同。
• 夜间掉线的判据：看更新记录里的可用率，与 NAT 无关。
• 图的作用：把「为什么」变成一张可指认的图，比记住端口号有用。
• 复查节奏：主机系统更新可能改变联机端口，每次大版本后复测一次。
• 口径：三张图与表 1 共用同一批抓包记录。

主机派对语音：三条与对局不同的链路

派对语音是主机联机里最容易被单独拎出来的问题：它走的端口不同、编解码不同、对抖动的容忍度也不同。对局流畅但派对断续，是最典型的组合。

PS5 的派对语音：与对局分端口

PS5 的派对语音与对局走不同端口，只开对局端口时能进对局但派对无声或断续。实测里补上语音相关端口后，派对断续次数从每十分钟 3 次降到 0 次，而对局读数没有变化，说明两者确实是两套链路。

Xbox 的派对：走系统级通道，受 UPnP 影响

Xbox 的派对语音走系统级通道，UPnP 失效时会出现「能听到对方但对方听不到你」的单向问题。这类单向故障靠看 NAT 类型发现不了，必须看派对内的实际收发状态。

Switch 的系统语音：依赖手机端

Switch 的系统语音依赖手机端配合，主机侧只承担联机。因此 Switch 的语音问题往往与主机端口无关，排查方向与另外两台完全不同，先看手机与耳机的蓝牙链路。

三台主机的语音链路差异说明一件事：把「主机联机卡」当成一个整体来排查，第一步就会走偏。先分对局与语音，再分平台，最后才看端口。

对局链路

小包高频，重点是端口可达性与 NAT 档位，带宽需求低于 60 Kbps。

语音链路

有编解码与抖动缓冲，容忍度取决于缓冲深度，抖动超过 25 ms 就会断续。

单向故障

能听到对方但对方听不到你，多半是上行端口未通或 UPnP 争用。

双向故障

两侧都断续，多半是同一区域的中继拥塞，换落地区域通常有效。

延迟敏感度

对局对延迟敏感，语音对抖动敏感，两者的阈值不是同一个数。

排查顺序

先分对局与语音，再分平台，最后才动端口与线路。

十种典型故障与对应动作

下表按「看到的提示」而不是「猜测的原因」排序，这样能直接从症状跳到动作，不必先建立完整的网络模型。

最后两行值得单独记住：系统更新会改变端口，这是主机联机最容易被忽略的回归来源；而全员同时变慢永远不是你的问题，此时任何设置改动都只会增加变量。

用重启排除缓存干扰

主机与路由器都会缓存端口映射状态，改完设置不重启时，状态页显示的往往是旧值。实测里两次「改了没用」的记录，重启后都立刻生效。因此验证动作必须包含两端重启。

复测口径：怎么确认改动真的生效

主机上没有现成的探测工具，只能靠平台自带的状态页与对局内计数。下表给出五个可用的观测点，按可信度排序。

五个观测点里，只有路由器会话表能直接看到端口映射是否建立，其余都是间接推断。有条件时优先用它验证，能省掉反复重启的时间。

一页速记：主机联机的六个判断

把整页内容压成六条，用于临时排查时快速定位。每条都标注了对应的数据来源，需要细节时回上表核对。

一 · 先看 NAT 档位

严格型先开端口，别先换线路。表 1 里严格型与中等型的组队成功率相差 32 个百分点。

二 · 再看路径类型

中继比直连多一次往返，实测 31 ms。路径类型由两端 NAT 决定，不由线路质量决定。

三 · 双 NAT 无法本地解决

上游做过地址转换时，本地配置碰不到那一层，只能找运营商或接受中继。

四 · 语音单独排查

对局流畅但派对断续，是两条不同链路的典型表现，先补语音端口。

五 · 带宽不是变量

联机下行占用低于 60 Kbps，升档对组队与延迟都没有可测出的改善。

六 · 系统更新会改端口

大版本更新后必须复测一次，这是最常见的回归来源。

• 对应数据：表 1 的九行记录、表 2 的端口清单、表 3 的十种故障、表 4 的五个观测点。
• 使用顺序：先按速记定位到某一行，再回表里看具体读数与条件。
• 时效：端口与状态页会随系统更新变化，2026-10 之后的记录需要复测确认。
• 记录：每次改动写一行「时间—动作—结果」，后面回看时能省掉一半排查时间。
• 交叉页：延迟与抖动的换算见 FPS 页，丢包的分档见丢包页。
• 边界：本页结论只覆盖点对点联机，云串流（Remote Play 一类）的链路不同，需单独处理。

相邻场景：换一个角度核对同一组数据

四类场景的瓶颈不在同一处：FPS 卡在服务器判定，主机联机卡在 NAT，语音卡在抖动缓冲，云游戏卡在解码与码率。下面六个入口按排查顺序排好，从一个场景读进另一个场景最快。

快喵VPN 在主机场景只记录组队成功率、路径类型与 NAT 档位三项，其余指标在这个场景里几乎没有解释力。

• FPSFPS 竞技：tickrate 与服务器判定64 tick 与 128 tick 的判定窗口差 7.8 ms，比你换节点省下的还多。
• Voice语音会议：抖动缓冲的深度取舍缓冲 20 ms 省延迟但吃抖动，60 ms 稳却吃掉轮流发言的间隙。
• Cloud云游戏：码率与解码延迟端到端 120 ms 预算怎么分到编码、传输、解码三段。
• Loss丢包 1%、3%、5% 三档感受同样是 3%，FPS 里是回拉，语音里是一声金属音。
• Updates线路与客户端更新记录每条标注影响面与是否可以回退，9 条按日期倒序。
• FAQ判定问答：换节点有没有用42 问按延迟、抖动、丢包、主机四组分开答。