UPnP端口映射失效：CGNAT 下为什么该用 PCP

前言

家里跑 NAS、开远程桌面、和朋友联机打游戏，或者挂着 BT 做种，很多人的第一步都是在路由器里打开 UPnP。管理页面上“端口映射成功”的提示也确实出现了，可外网访问依旧连不上。

多数排查会停在“路由器 UPnP 没开”“防火墙没放行”“映射没生效”这几步。但如果链路中间夹着一层运营商级 NAT（CGNAT），这些检查做得再细也没用——问题不在你家路由器，而在协议够不着的那一层。

下面按三步拆：先判断自己在不在 CGNAT 后面，再看 UPnP 到底能管到哪一层，最后看运营商有没有部署 PCP。

问题出在协议层，不是配置层

“路由器里 UPnP 开了，端口映射也成功了，为什么外网还是连不进来？”这个问题的答案通常不在路由器里。实际上，如果链路中间存在运营商级 NAT（CGNAT），UPnP 从一开始就够不着出问题的那一层。

在 CGNAT 场景下，真正负责“向运营商申请一个可被外部访问的端口”的协议是 PCP（Port Control Protocol，RFC 6887）。PCP 能否使用完全取决于运营商是否在城域网侧部署了 PCP 服务器、CPE 是否运行了 PCP 代理。运营商没有配置，就会出现“客户端请求发出去了，却没有响应”的结果。

先数清楚中间有几层 NAT

判断 UPnP 有没有意义，第一步是确认自己是否位于 CGNAT 之后。典型的两层结构长这样：终端把 UPnP 请求发给光猫，光猫老老实实建好了映射，可这条映射的公网侧地址属于运营商的内网，出不了城域网。

终端经光猫路由器发起 UPnP 映射，运营商侧 NAT4 策略使映射只停留在内网 — 图 1：UPnP 请求被光猫正常接收，但运营商侧的 NAT4 策略让这条映射停在了运营商这一层

关键判据是路由器 WAN 口拿到的地址：

192.168.x.x、10.x.x.x、172.16–31.x.x：标准私网，通常是自己又接了一台路由器，属于双重 NAT。
100.64.0.0/10：RFC 6598 定义的共享地址空间，这是 CGNAT 的明确标志。
公网地址：才可能是单层 NAT，UPnP 有意义。

表 1　按 WAN 口地址快速判断

WAN 口地址	结论	下一步
`100.64.0.0/10`	运营商 CGNAT	UPnP 无效，查 PCP、申请公网 IP 或走 IPv6
`10.x`、`172.16–31.x`、`192.168.x`	自家双重 NAT	光猫改桥接，或在光猫上给二级路由做 DMZ
公网地址	单层 NAT	UPnP 可用，注意端口冲突与租期

对比方法很简单：在路由器管理页看 WAN IP，再在终端里查出口 IP，两者不一致就说明中间还有一层。

# Linux / macOS
curl -4 ifconfig.co
traceroute -n 8.8.8.8 | head -5

# Windows
curl.exe -4 ifconfig.co
tracert -d 8.8.8.8

# 路由器上（OpenWrt 示例）
ip -4 addr show wan

traceroute 第二跳如果是 100.64.x.x 或私有地址，就可以确定已经进入运营商 NAT。

UPnP IGD 只能改第一跳

UPnP 在端口映射上的工作链路是：

客户端通过 SSDP（UDP 1900，组播 239.255.255.250）发现网关；
拉取网关的 IGD 描述文档（HTTP，常见 5000 或 49152–49156 端口）；
通过 SOAP 调用 AddPortMapping，参数是内网 IP、内网端口、外网端口、协议、租期。

它修改的是第一跳网关的 NAT 表，把 192.168.1.10:8080 映射到 WAN口IP:外网端口。

问题就在这里：如果 WAN 口 IP 是 100.64.3.7，这条映射的结果是“公网上可路由到 100.64.3.7 的某个端口”，而 100.64.0.0/10 在公网骨干上根本不可路由。CGNAT 那一层的转换表完全没有被触碰，外部流量到达运营商侧后仍会因为没有对应的端口绑定而被丢弃。

换句话说，UPnP 只能修改你家路由器这一层，够不到运营商那一层，而恰好是运营商那一层决定了外部流量能不能进来。

另外，UPnP 还可能因为以下原因失效，这些与 CGNAT 无关，但经常同时出现：

路由器固件关闭了 UPnP，或 miniupnpd 进程崩溃；
SSDP 组播被 VLAN 隔离或防火墙拦截；
双重 NAT 下客户端只发现了最近的一台网关；
端口已被其他服务占用，AddPortMapping 返回 718 冲突；
IGD 实现只支持 IGD:1，没有 NAT-PMP 回退。

PCP 是为 CGNAT 设计的协议

PCP 的设计目标就是让主机能够端到端地请求 NAT 设备为自己建立映射，而不假设 NAT 只有一层。

基本特征：

传输：UDP 5351（与 NAT-PMP 同端口，便于复用探测逻辑）；
消息：24 字节固定头 + 可选选项，包含版本、操作码、请求 lifetime、客户端 IP、映射 nonce；
主要操作码：
- ANNOUNCE（0）：服务器宣告自己存在、支持哪些能力；
- MAP（1）：申请一个入站映射，返回外部 IP、外部端口、lifetime；
- PEER（2）：为一条已存在的出站连接申请入站放行，适合 P2P 打洞。

对比图：UPnP 只在第一跳网关上建映射，运营商 CGNAT 转换表未被修改；PCP 经 UDP 5351 直达运营商侧服务器开洞 — 图 2：UPnP 的映射止步于光猫，PCP 的请求一路送到运营商侧的 PCP 服务器

对应的标准配套还有：

RFC 7648：PCP Proxy，让 CPE 把客户端的 PCP 请求转发给上游运营商服务器；
RFC 6970：UPnP IGD 与 PCP 的互通功能（IGD-PCP IWF），让只懂 UPnP 的应用也能借道 PCP；
UPnP IGD:2 起，规范层面开始把 PCP 纳入网关能力。

所以在新一点的 CPE 上，“UPnP 能用”有时其实是 IGD:2 + PCP 代理在工作，而不是传统 IGD:1 的 AddPortMapping。

关键判断：运营商是否部署了 PCP

PCP 是客户端-服务器模型，服务器必须在运营商侧。这意味着：

运营商在 BNG/CGNAT 上部署了 PCP 服务器，并允许用户侧网段访问 UDP 5351；
CPE 运行了 PCP 代理，把内网请求转给上游；
CGNAT 的端口分配策略允许按需映射，而不是只按算法静态分配。

三条同时成立，PCP 才有效。

现实里常见的缺口：

只做 MAP-E、lw4o6、DS-Lite：这类过渡技术下，外部端口是从你的 IPv6 地址按算法推导出的固定端口块，运营商不允许临时申请任意端口。你能用的端口是算出来的，不是要来的。
PCP 服务只对内网管理面开放：用户侧发到 5351 的包直接被 ACL 丢弃。
CPE 固件根本不带 PCP 代理：大量家用光猫只实现 IGD:1，管理页面里连 PCP 字样都找不到。
CGNAT 设备只支持 PEER 不支持 MAP：能帮你放行已有连接，但不能主动开放入站端口。
端口池耗尽：即使协议通，服务器也可能返回“资源不足”。

这就是“协议对了，但运营商没配”的典型状态：客户端按照 RFC 6887 发出 MAP 请求，等待响应，超时，回退到 UPnP，再失败。

五分钟定位流程

第 1 步：确认是否在 CGNAT 后面

curl -4 ifconfig.co          # 出口公网 IP
# 对比路由器 WAN 口 IP

WAN 口是 100.64.x.x，就可以直接判定为 CGNAT。

第 2 步：确认端口是否真的通

# 外部机器上
nc -vz 203.0.113.5 62000
curl -v http://203.0.113.5:62000/

第 3 步：抓包看 PCP 有没有响应

# Wireshark 过滤
udp.port == 5351

如果只看到客户端发出的 MAP 请求（操作码 1），没有任何 MAP 响应，基本可以确认上游没有 PCP 服务器，或者请求被 ACL 拦了。

第 4 步：检查 CPE 能力

管理页面搜索 PCP、NAT-PMP、端口控制协议；
OpenWrt 上确认是否装了 miniupnpd（2.x 起同时支持 IGD、NAT-PMP、PCP），以及有没有独立的 PCP 客户端或代理进程；
看固件版本说明里是否提到 IGD:2 或 RFC 6887。

第 5 步：用客户端实测

# NAT-PMP / PCP 客户端示例
natpmpc -a 8080 8080 tcp 3600
# 或使用 pcp-client 类工具，指定服务器地址后发 MAP 请求

返回外部 IP 和端口，说明链路通；超时或返回错误码，看错误码定位是“不支持”还是“无资源”。

方案横向对比

表 2　七种“让外网连进来”的方案

方案	工作层	能否穿透 CGNAT	前提条件
UPnP IGD:1	应用层发现 + SOAP	不能	仅第一跳网关可控
NAT-PMP	UDP 5351	不能	同上，且网关支持
PCP（RFC 6887）	UDP 5351，端到端	能	运营商部署 PCP 服务器 + CPE 有代理
STUN	UDP 打洞辅助	部分	需对端配合，对称 NAT 下失效
TURN	中继	能	有公网中继服务器，带宽成本
IPv6 直连	网络层	能	双方都有公网 IPv6，且防火墙放行
工单申请公网 IP	运营策略	能	运营商愿意分配

常见问题

映射显示成功，为什么还是不通？

因为“成功”只代表你家路由器的 NAT 表里多了一条记录。真正该看的是外部能不能连：从外网用 nc 或 curl 打一下公网 IP 加端口，或者确认 CGNAT 侧有没有对应的绑定。只盯着路由器状态页，永远看不出第二层发生了什么。

有了 IPv6，还需要 PCP 吗？

不需要。IPv6 下每台设备都有全局地址，不再有 NAT，入站是否可达只取决于防火墙策略。PCP 解决的是 IPv4 地址不足带来的映射问题；换成 IPv6 之后，该做的是在防火墙里放行对应端口，并确认运营商分配的前缀不会频繁变更。

UPnP 和 PCP 能同时开吗？

可以，两者互不冲突，不少设备干脆把 IGD、NAT-PMP、PCP 三套一起监听。需要留意的是安全面：任何内网程序都能借它们开洞，长期开启等于把端口控制权交了出去，用完即关更稳妥。

结论

UPnP 失效不是配置问题，而是适用范围问题。它只能控制第一跳 NAT；在 CGNAT 后面，它做出来的映射指向一个公网不可路由的地址。
CGNAT 场景下应使用 PCP。MAP 请求直达运营商侧 PCP 服务器，由 CGNAT 真正开洞并返回外部 IP、端口和租期。
协议正确不代表能用。PCP 是客户端-服务器模型，服务器在运营商手里。只做 MAP-E、lw4o6 的网络不提供按需映射；CPE 没有 PCP 代理、5351 被 ACL 拦截，结果都一样：请求没有响应。
排查顺序应该是：先确认 WAN 口是不是 100.64/10，再确认 5351 有没有响应，最后才回头检查路由器 UPnP 进程。顺序反了，就会在错误的层反复调整。
实际可行的出路：争取公网 IPv4、走 IPv6 直连、或用中继/打洞方案。PCP 是“运营商愿意配合”时的正解，不是用户单方面能打开的开关。

顺带一句：UPnP 和 PCP 都是“让内网主动对外开放”的机制，长期开启等于把端口控制权交给内网任意程序。用完即关、按需映射，比一直开着更稳妥。

如果你觉得这篇文章不错，有用的话可以点击下面的“赞赏”支持作者，你的支持是我更新的动力（饿饿吃饭）。