游戏掉线、联机卡顿？问题多半在 NAT 类型和 UPnP

随着IPv4地址的枯竭，NAT技术越来越被各种场景采用。虽然IPv6的建设逐步推进，但是实际应用意愿不大，很多医院、学校、公司等场景下的使用频率不高。但是很多应用场景又依赖P2P“点对点”连接，比如：视频会议、即时通话、多人游戏、远程办公等等。NAT下的通信问题一直以来是长期的困难，以往依赖手工配置端口映射，但是这不仅费时不利于管理，还不清楚NAT下的设备具体的端口需求。对于游戏和即时通话这种非固定服务场景来说，每次端口都是不确定的。

先对号入座：下面这些事，你中过几件

联机游戏打到一半忽然掉线，或者干脆匹配不到人；
主机网络设置里，NAT 类型显示“严格”或“中等”，别人那一栏是“开放”；
进了游戏语音派对，你听得见别人说话，别人听不见你；
朋友能进别人的房间，就是进不来你开的那个；
家里的 NAS、监控想从外面看一眼，只能走厂商的云中转，速度几百 KB/s；
BT / PT 下载挺快，上传却几乎为零，做种做不动；
想给自己搭个小服务，端口连着超时，换一个端口还是超时。

这几件事看着互不相干，根子却是同一个：你的设备在公网上没有门牌号，别人主动找不着你。

症状与根因对照示意图：联机掉线、匹配不到人、NAT 类型显示严格、语音单向、NAS 只能走云中转、BT 上传为零、自建服务端口超时，这些现象最终都归到同一件事——设备在公网上没有可被主动访问的地址 — 图：症状一大堆，根子只有一个

下面从头讲清楚为什么会这样，以及能怎么办。只想解决问题的，可以直接跳到最后一节。

先说清楚，我为什么要写这篇

这不是一篇教人开端口映射的教程。

家里摆着 NAS 的人，大概都见过这一幕：人在外面，想调一张存在家里的照片，App 转了半天，最后给出一行小字——已通过中转服务器连接，速度几百 KB/s。玩联机游戏的更直观，主机设置里明晃晃写着 NAT 类型，别人是“开放”，你那儿是“严格”；进了语音派对，你听得见别人说话，别人听不见你。

这些都不是“不会设置”造成的。是你所在的这条链路上，压根就没给你留一条通路。

解法早就有，标准也立了十几年。所以我真正想说的不是“怎么修”，而是：这件事拖到今天还没解决，不是因为它难，是因为没人在乎。

UPnP 是谁造的，它能开的又是哪扇门

网上流传一种说法，说 UPnP 是 IETF 制定的。不对。UPnP 是 1999 年 10 月由微软、Intel 等厂商发起成立的 UPnP 论坛（UPnP Forum）做的标准，2016 年之后整体移交给了开放互联基金会（OCF）。IETF 手上另有两套功能相近的东西：PCP（端口控制协议，RFC 6887），以及 Apple 提出、后来被 IETF 收录的 NAT-PMP（RFC 6886）。三家想解决的其实是同一个问题，让内网设备能主动找网关申请一条端口映射；出身不同、细节不同，功能却大面积重叠。

标准组织自己都没能把这件事收拢成一件，这也解释了后来各家网关为什么总是“支持一半、缺一半”。

真正在家里被用起来的，是 UPnP 体系里一个很窄的子集：UPnP IGD（Internet Gateway Device）。整套动作就四步。设备先往 239.255.255.250:1900 这个组播地址喊一嗓子，问网关在不在（这一步走的是 SSDP 协议）；网关应答之后，设备取回一份 XML 描述，看清楚这个网关认哪些动作；然后设备用 SOAP 调用 AddPortMapping，把自己的内网地址、内网端口、想要的外部端口一并报上去，网关就在转发表里添一条；这条映射带租期，设备会定期续租，设备下线或者租期到了，映射自动删掉。

最后这一点其实很关键。手工配端口映射最烦的就是开完就忘，规则越攒越多，哪天想查是哪台设备要的都记不起来。UPnP 是“用完即走”，不留垃圾规则。

但这里有个边界要划清楚。UPnP 能管的，只有“你家内网到你自家网关”这一段。它可以让网关替你开个洞，管不了网关之外还有谁堵着。后面所有问题的起点，都在这个边界上。

UPnP IGD 工作流程示意图：内网设备先通过 SSDP 组播发现网关，再取回 XML 描述，然后用 SOAP 调用 AddPortMapping 写入映射，最后按租期自动续租与回收；整个过程只发生在内网到家用网关这一跳 — 图：一次 UPnP 请求的四个步骤，但它的权限只到你家网关为止

光你家网关配合，还不够

UPnP 不是万能的，得下面几条同时成立才有效：

网关 WAN 口拿到的确实是公网地址，而不是运营商内网的私有地址；
网关上游（ISP 那一侧）没有第二层 NAT，或者那层 NAT 是“全锥形”这种对打洞友好的类型；
光猫工作在桥接模式、由你自己的路由器拨号，否则就是双重 NAT，UPnP 只能把洞开到光猫那一层，再往外它没权限；
网关自己的设置里，UPnP 是打开着的。

下面这几种情况，UPnP 救不了你：

运营商侧是对称型 NAT，而且不提供 PCP / NAT-PMP 这类上层协议；
运营商侧有防火墙，并且限制端口映射；
网关厂商出于“安全考虑”，默认就把 UPnP 关了（这一条后面单独讲）。

说到底，UPnP 只是你和自家网关之间的协商机制。问题一旦出在运营商的设备上，它再聪明也没用。

UPnP 生效条件判定图：需要网关 WAN 口有公网地址、上游没有第二层 NAT、光猫桥接由路由器拨号、网关里 UPnP 处于开启状态；任一条件不满足即无效，常见失效场景为对称型 NAT 且无 PCP、运营商防火墙限制端口映射、厂商默认关闭 UPnP — 图：四关全过才有用；任何一关卡住，在自己家里怎么折腾都是白费

NAT 分四等，多数人拿到的是最差的那一等

很多教程只教你“把 UPnP 打开”，可真正决定 P2P 通不通的，是 NAT 有多“宽容”。业内习惯把它分四档：

类型	名称	映射行为	对 P2P 打洞的影响
NAT1	全锥形（Full Cone）	内网地址固定映射到同一个外部端口，任何外部地址都能访问这个映射	最友好，基本等于有话直说
NAT2	受限锥形（Restricted Cone）	映射仍然固定，但只有你主动访问过的那个外部 IP 才回得来	友好，配合 STUN 一般能打通
NAT3	端口受限锥形（Port Restricted Cone）	除了 IP，端口也得对得上	能打，但成功率开始往下掉
NAT4	对称型（Symmetric）	每访问一个新目标就换一个外部端口，映射不固定	最不友好；两边都是 NAT4 基本打不通，只能走中继

“打洞”这个词听着玄，道理其实不复杂。两台都躲在 NAT 后面的机器想直连，靠的是一个“同时开口”的技巧：双方先各自去问一台有公网地址的服务器（STUN 服务器）“我映射到公网上是什么地址、什么端口”，拿到答案后互相交换，再约好一起朝对方的公网地址发包。第一个包出去，两边的 NAT 都以为“这是我自己先发起的会话”，顺手在表里放行，路就通了。WebRTC、各类语音通话底层跑的都是这一套，标准名字叫 ICE。

这套办法能成，有个前提：你的映射得稳定、可预测。全锥形 NAT 里，内网地址永远映射到同一个外部端口，怎么打都行；对称型 NAT 则是你每连一个新目标，它就给你换一个外部端口，对面根本算不出该往哪儿打。国内家宽默认给的，恰恰多是这一档。更麻烦的是，不少运营商连 PCP / NAT-PMP 都不部署，用户想“主动申请一条映射”都没门。

NAT 类型对照示意图：NAT1 全锥形映射最稳定、打洞成功率最高；NAT2 受限锥形次之；NAT3 端口受限锥形成功率开始下降；NAT4 对称型每换一个目标就换一个外部端口，基本只能靠服务器中继 — 图：NAT 分四等，越往后越难打洞，而国内家宽默认给的往往是最差的那一等

连接方式其实有一条从好到坏的阶梯

把上面这些串起来看，两个端点想通信，会按下面的顺序往下掉：

最好的一种，双方都持有公网地址——IPv6 直连，或者 IPv4 公网对公网。直接连上，中间没有任何环节。
差一档：一端躲在 NAT 后面，靠 UPnP / PCP 主动向网关要一条映射，再把这条路打通。
再差一档：两端都在 NAT 后面，谁也开不了映射，只能靠 STUN 同时朝对方发包打洞。
兜底：洞也打不通，退回 TURN 中继服务器转发。

每往下一级，延迟、成本和失败率都往上走一档。而要是运营商在第二、第三级之前就把路封死——不发公网地址、不部署映射协议、再把入站流量拦掉——用户能选的，就只剩下最后一级。

CGNAT：你和一整个小区共用一个门牌号

中国大陆的家宽普遍缺公网 IP。大量用户其实处在 CGNAT（运营商级 NAT）后面，几十户甚至上百户共用一个公网地址对外通信。

想知道自己是不是其中之一，有个特别简单的办法：登进路由器后台，看 WAN 口的 IP。如果开头是 100.64 到 100.127，基本可以确诊。这段地址是 IANA 专门划给运营商做大 NAT 用的共享地址段（RFC 6598），在公网上你根本没有自己的坐标。

CGNAT 带来的麻烦是双层的。第一层，你在运营商的大 NAT 后面，天然不具备被外部主动访问的条件；第二层，自家的光猫或路由器又做了一次 NAT。两层叠起来，UPnP 只能管到最里面那一层，而运营商的 CGNAT 设备既不认 UPnP，通常也不提供 PCP 接口。你在自己家里怎么折腾，都碰不到外面那一层。

所以“开启 UPnP 就能解决”这句话，得先看前提。要是你本来就在 CGNAT 后面，开不开 UPnP，对外能不能访问进来，几乎没有区别。

CGNAT 双层 NAT 示意图：内网设备经家用网关做第一层 NAT 进入 100.64.0.0/10 共享地址段，再由运营商 CGNAT 做第二层 NAT 转换成公网地址，并给出通过路由器 WAN 口 IP 自查是否处于 CGNAT 的方法 — 图：两层 NAT 叠在一起，UPnP 只能开到最里面那一层

越改越连不通：这条路是一步步堵死的

前面讲的是“为什么打不通”。这一段想讲另一件更让人泄气的事：这条路不是一直这么堵的。公网 IP、NAT 类型、IPv6 入站，这几样东西这些年一直在往回缩，方向从来没变过。

四次收缩时间线示意图：从家宽持有真公网 IPv4 可以直连，到公网地址被收回换成 CGNAT 只能打洞，到上游 NAT 收紧成对称型 NAT4 且不部署 PCP / NAT-PMP 使打洞也失败，再到 IPv6 入站流量在局端被拦导致绕行方案也失效 — 图：四次收缩，一条单向下坡路 —— 用户的上行能力被一路削到零

第一阶段，家宽拿到的是真公网 IPv4。端口映射在路由器后台点几下就能加，P2P 是网络的常态，不是极客的特权。

第二阶段，公网 IPv4 被收回去，换成 CGNAT。你在公网上不再有自己的坐标，只剩下运营商大 NAT 后面一个共享门牌号。“能被外部访问”这件事，从配置问题直接变成了不可能。

第三阶段更彻底。即便在 CGNAT 里面，上游那层 NAT 也从“全锥形”收紧成了对称型，也就是前面说的 NAT4——你每对外发一个新连接，它就换一个端口，打洞的人根本算不出该往哪打。同时 PCP / NAT-PMP 一个都不部署：想主动申请一条映射，连个能对话的接口都没有。

第四阶段就是现在。IPv6 本来是可以绕过 NAT 的——地址多到几乎用不完，天生端到端。地址也确实发下来了，但入站流量在局端被拦掉。这一条后文有实测，不靠猜。

把这四步连起来看：从“能直连”，到“得打洞”，到“打洞也没门”，再到“连绕开的那条路也封了”。每一步单独看都有它的理由，但四个理由指向同一个结果——用户的上行能力被一路削到零。这不是谁都想看到的，对于互联网发展也起不到推动作用。

运营商为什么不管

技术上的解法早就有了，标准也躺在那儿十几年。真正的问题是：执行这件事的是运营商，而运营商没把它当回事。

而“没当回事”背后其实有账可算。把那四次收缩排在一起看，它不太像技术演进，更像一次成本优化：公网 IPv4 是稀缺资源，收回来能省；NAT 越严格，会话表越小、设备负载越低；入站一封，投诉工单和攻击面一起降；考核又只盯着下行。每一项单独看都“有道理”，加起来就是把用户的上行能力削到零。

成本收益对照图：运营商一侧省下公网 IPv4 稀缺资源、降低 NAT 会话表与设备负载、减少投诉工单与攻击面、且考核只算下行；用户一侧则承受联机掉线、语音单向、NAS 与监控只能走云中转、自建服务被堵在门外 — 图：这更像一次成本优化，不是技术演进

协议标准写好了十几年，接口一个都不开

国内运营商大多不在 CGNAT 设备上开 PCP / NAT-PMP 服务端。这意味着，普通用户就算买了支持这些协议的路由器，也找不到可以对话的那一头，折腾半天只能得出“怎么改都没用”的结论。标准写在那里，实现缺席，这不是技术难题，是意愿问题。华为、中兴、TP、烽火等厂商的运营商级网络设备出厂就内置了相关功能，可这些功能躺在“固件”里，从来没有人调用。

公网 IP：能不给就不给，能拖就拖

公网 IPv4 紧张是事实，但“紧张”不等于“可以不给、也不用说明白”。各省政策五花八门，有的能申请、有的要加钱、有的先答应下来再装糊涂。更难的是信息不透明：用户没有正规渠道能查清自己到底处在什么网络环境、能不能申请公网地址，只能靠论坛里口口相传的经验一次次试。

封了多少端口，不会有人告诉你

比 CGNAT 更直接的，是入站封锁。80、443、8080 这些常见入站端口，在不少线路上是被默认拦掉的，既不提前告知，也没有申诉入口。你自建的服务、远程访问、内网穿透，撞到的第一堵墙往往不是自己的设备，而是运营商的策略。IPv4 侧封，IPv6 侧有时也一并封掉，本该是解开 NAT 死结的钥匙，在固网这一侧给上了锁。

光猫是运营商租给你的，钥匙不在你手上

光猫由运营商集采、运营商下发，超级管理员账号的权限一层层收紧，UPnP 相关的选项被藏起来，或者干脆从固件里砍掉。用户掏钱买了宽带，却对自己家里那一跳的设备没有完整控制权：想改桥接得打客服，想开通 IPv6 得等师傅上门，想看看端口映射的状态，发现根本没有这个页面。这不是技术问题，是态度问题。

考核表里，没有“上传”这一栏

最根子上的原因在考核。运营商现阶段的网络质量指标，基本盯着“能不能上网、带宽够不够、视频卡不卡”，全都在下行。P2P 连通性、入站可达性属于上行与对称能力，既不进指标、也不进考核，自然没人关心。于是用户报障时听到的话术永远是“重启一下试试”，而问题其实写在资费套餐和网管策略里，重启一万次也不会变。

IPv6 本该是那把钥匙，固网这边却把它锁进了抽屉

如果 IPv4 地址实在拿不出来，还有一条路：IPv6。地址多到几乎用不完，没有 NAT，天生就是端到端。理论上，只要两边都拿到 IPv6 地址，谁都能直接找到谁。但是现实是怎样的？

现实是另一副样子。截至 2025 年底，移动网络的 IPv6 流量占比已经到了 70.85%，固定网络却只有 32.38%，差了不止一倍。移动侧之所以跑得快，是因为 4G / 5G 从建设那天起就把 IPv6 当默认配置；而固网这边，光猫要不要开 IPv6、给不给你下发 PD 前缀、入站的 IPv6 流量放不放行，全凭各地各家自己拿主意。

于是很常见的一种情况是：IPv6 地址拨下来了，但你从外面依然访问不进去。有的地区只给一个 /128 地址、不给前缀，有的地区干脆把 IPv6 入站流量全拦在局端。你主机上的防火墙明明开着门，外面连敲门声都听不到。

这不是推测。下面这张是我自己那台 NAS 的真实情况：IPv6 地址一个不少，运营商还不止下发一个，前缀也是 /64 的，看着一切都对。可拿它去做全国多点连通性测试，地图上绝大多数省份是红色——而这个工具的图例里，红色不表示“慢”，表示“超时”。

真实测试截图：一台 NAS 通过 DHCP 取得了多个 IPv6 地址（含 /64 前缀），但用全国多点连通性测试平台检测该地址时，地图上绝大多数省份显示为红色（图例中红色代表超时），275 个监测点中只有零星几个能响应，分区表格里中国电信、中国联通整行为空 — 图：有地址 ≠ 连得通 —— 同一张测试报告里，红色不表示“慢”，表示“超时”

275 个监测点参与测试，能响应的只剩零星几个。分区表格里更直接：中国电信、中国联通两行整行为空，华东、华南、华中、华北、西南、东北这些分组连“最快”和“最慢”都填不上——不是测出来慢，是根本没有一个点能建起连接。

换句话说：地址是有的，门铃也是有的，只是铃声到不了屋里。

这跟国家层面推的方向，其实是拧着的。工信部曾牵头开展“网络去 NAT”专项工作，选取试点地区推动 NAT44 设备容量停止增长；2026 至 2030 年的 IPv6 实施方案也明确提出，要逐步形成以 IPv6 为主导的网络服务和应用体系。政策在往前推，固网执行却停在“能上网就行”的及格线上，中间这段落差，最后是用户和开发者买单。

IPv6 流量占比对比图：截至 2025 年底，中国移动网络 IPv6 流量占比 70.85%，固定网络仅 32.38%；固网侧普遍存在拨到地址却封禁入站、只给 /128 不下发前缀的问题 — 图：移动侧已经跑起来了，固网侧还停在及格线上（数据来源：《中国 IPv6 发展报告》）

这笔账，最后是谁在付

NAT 造成的连通性缺口不会凭空消失，它只是被转移了。

第一层是用户。更严格的 NAT 直接表现为：联机游戏匹配不到人，语音时断时续，家里的 NAS 和监控只能走厂家云中转，BT / PT 下载上传上不去。用户的感受是“网络不好”，但说不清哪里不好，连投诉都无从谈起。

第二层是应用厂商。网络层不给通路，厂商只能自己补：自建 STUN / TURN 服务器，直连打不通就退回中继转发。成本从网络侧挪到了应用侧，服务器要扩容、带宽要花钱、运维要人，这些最后又变成会员费和订阅费，绕回用户头上。而且中继会绕远路：延迟变高、抖动变大，数据还要在中继节点上过一遍，隐私边界也跟着后退。

第三层是互联网本身。互联网最早的立身之本，是 Saltzer、Reed、Clark 在 1984 年那篇《End-to-End Arguments in System Design》里讲清楚的“端到端原则”：网络只管把包送到，智能放在两端。而现在，一个新应用要做的第一件事往往不是实现功能，而是先想办法穿过 NAT，这就等于给每一个创新者加了一道跟产品本身毫无关系的门槛。

P2P 连接路径对比示意图：打洞成功时 A 与 B 直接协商出最短路径，延迟低、带宽高；打洞失败时流量必须绕行 STUN 或 TURN 中继服务器，延迟升高、抖动变大，数据还要在中继节点上过一遍 — 图：打通了就直连，打不通就绕路，成本从网络侧转到应用侧

“封了才安全”，这话经不起推敲

每次谈放行入站，最常见的反驳是“那不安全”。这话听着对，其实站不住。

首先，NAT 从来就不是安全设备。IETF 自己在 RFC 4864（Local Network Protection for IPv6）和 RFC 2993（Architectural Implications of NAT）里讲得很明白：NAT 那点“外面看不见里面”的效果，是地址转换的副作用，不是它的设计目标。真正该承担安全职责的，是有状态防火墙和明确的策略——该拒绝的拒绝，该放行的放行，而不是拿“整段不可达”假装安全。

其次，UPnP 出过的安全事故，是“实现”的问题，不是“协议”的原罪。历史上确实有严重案例，比如 2020 年公开的 CallStranger（CVE-2020-12695），攻击者可以滥用网关的 SUBSCRIBE 机制做端口扫描和数据外泄。但正确的处理方式是修固件、限制可映射范围、加认证、做白名单，而不是把整个功能一刀切关掉。因为门锁出过问题就把门焊死，最后被困住的是屋主自己。

NAT 与防火墙职责对比图：NAT 做的是地址转换，外部无法主动连接只是副作用，IETF 在 RFC 2993 与 RFC 4864 中明确这一点；真正承担安全职责的是有状态防火墙与明确策略，该拒绝的拒绝、该放行的放行；UPnP 安全事件的正确处置是修固件、限制可映射范围、加认证、做白名单，而非一刀切关闭 — 图：“封了才安全”经不起推敲 —— 安全靠的是策略，不是靠“不通”

运营商指望不上，普通人还能做什么

抱怨归抱怨，日子还得过。在不动运营商的前提下，下面几件事值得按顺序做：

五步排查处理流程图：第一步看路由器 WAN 口 IP 确诊是否处于 CGNAT 或双重 NAT；第二步尝试申请公网 IPv4；第三步把重心转到 IPv6 并实测入站；第四步选协议支持齐全的网关，实在不行再用 WireGuard / Tailscale / frp 自建隧道；第五步通过工信部电信用户申诉受理渠道（12300）反映 — 图：按这个顺序来，别再从“重启光猫”开始

先确诊，别瞎折腾。登路由器后台看 WAN 口 IP。落在 100.64.0.0/10，或者干脆是 10.x、172.16–31.x、192.168.x 这些私有段，就说明你在 CGNAT 或双重 NAT 底下。这一步能省掉后面一大半无用功。
试着申请公网 IPv4。打客服或在营业厅直接说“需要公网 IP，用于远程办公和监控回看”。各省政策不同，能不能办、要不要钱得试了才知道。
把重心往 IPv6 挪。光猫支持的话，尽量改桥接、让路由器拨号，打开 IPv6 并拿到 PD 前缀。IPv6 没有 NAT，天然具备端到端能力。但别以为打开就一定通，有些线路对 IPv6 入站也做了限制，放行之后必须实测，主机防火墙和光猫自带的 IPv6 防火墙都要看。
网关尽量选协议支持齐全的。优先 UPnP IGD 完整、PCP 没被阉割的型号，别买那种“功能列表里写着 UPnP、实际是残废版”的。真被运营商卡死，也可以退一步，用 WireGuard、Tailscale、frp 自建隧道打通。但心里要清楚，这是绕开问题，不是解决问题，流量绕行、速度看中转节点，属于妥协方案。
该反馈就反馈。遇到“承诺了公网 IP 却没给”这类情况，可以通过工信部电信用户申诉受理渠道（12300）反映。一个人的声音很小，但这是目前唯一正规、且会被计数的渠道。

还有一句，给各家客服：别再让用户“重启一下光猫”了。这个问题的开关，不在用户家里。

最后

回到开头那句话。UPnP、PCP、NAT-PMP 这些名字听着枯燥，守着的其实是一件很朴素的事：任何一个端点，都应该有能力直接找到另一个端点。

这件事做好了，好处是全行业的。实时通信更稳、游戏联机更快、自建服务不必绕地球一圈、应用厂商不用把预算砸在中继服务器上。它甚至不需要运营商多花什么钱，只要把已经成熟的协议部署下去，把已经拿到的地址如实发出去，把已经封掉的端口重新掂量一遍。

如果固网侧继续停在“能刷视频就算合格”的标准上，这堵墙只会越砌越高：用户被隔在里面，开发者被挡在外面，互联网最引以为傲的那种“谁都能接上谁”的活力，会一点点被磨掉。

至于我们能做的，也就这些了：先搞清自己在什么网络环境里，该申请的去申请，该实测的去实测，该申诉的去申诉。剩下的那部分，不在我们手上。

结尾收束示意图：要让 P2P 恢复，运营商只需做三件不需要额外花钱的事——把已经成熟的 UPnP IGD / PCP / NAT-PMP 协议部署下去，把已经拿到的公网 IPv4 与 IPv6 前缀如实发放，把已经封掉的 80 / 443 / 8080 与 IPv6 入站重新掂量一遍 — 图：这三件事没有一件需要运营商多花钱

配置 PCP / NAT-PMP 等相关协议，运营商几乎付出不了多少成本。而且这件事本来就在华为、中兴等通信大厂的考虑里面，设备里面有，但是一直躺着。相反，搞入站封锁、黑白名单反而会加大网络设备的性能开销，让配置变得复杂。

在我看来，能让上网体验明显变好的，从来不是越来越快的速率，也不是各种附加产品，而是这些技术到底落没落地。什么时候，网络延迟、高SLA、上传带宽、P2P连通性等相关纳入考核标准，用户上网体验才是明显变好的指标。道理很朴素：通道开出来，平台就不必为了省流量成本把画质一压再压；入站不封，用户也不必转头去买那些昂贵的第三方服务。好处最后还是会绕回运营商自己身上——体验真上去了，用户才有动力升级带宽套餐；带宽和延迟不再卡着脖子，互联网厂商也就不用靠阉割视频质量来省成本。

写这些内容需要耗费大量的时间和金钱，觉得有用的话可以点击下面的“赞赏”支持作者，你的支持是我更新的动力。