Chrome 封锁 10080 端口

前几天在测试一个 Web 服务时，随手把端口指到了 10080，然后死活打不开。

当时第一反应是服务本身挂了——让 AI 诊断，提示一切正常；用 curl 测试也正常。只有浏览器打不开。换了机器、换了浏览器，Chrome 下报错，Firefox 下也报错。把 Firefox 的提示信息发给 AI，AI 才恍然大悟：Chrome 和 Firefox 内置了一份受限端口黑名单，10080 刚好在里面。

把端口改成 18080 后，网页立刻恢复正常。

为什么 10080 会被浏览器封掉

大多数人不知道的是：浏览器在代码里硬编码了一个端口黑名单，写进了 Fetch 规范。遇到这些端口时，浏览器会直接拒绝建立连接，请求根本不会发到服务端。所以服务端怎么看都是正常的，问题出在中间那层。

10080 的特殊之处在于它与 80 的高度相似性。HTTP 默认端口是 80，而 10080 只需多敲一个零，在许多 Unix/Linux 系统中，非 root 用户可以绑定 1024 以上的任意端口，因此 10080 常被各类工具当作"免 sudo 的 80 端口"使用。

这种用法本身没有恶意，但在攻击场景下，它的存在让 NAT 表映射的 payload 更容易被构造和触发。攻击者可以诱骗访问者浏览器发起看似无害的 HTTP 请求，实际却让路由器在 NAT 表中创建一条穿越规则，把外部端口映射到内部主机上。这就是 NAT Slipstreaming 攻击的核心思路。

2020 年，安全研究员提出了 NAT Slipstreaming 2.0 版本，攻击面进一步扩大。新版本不再局限于特定端口，只要目标端口经过了路由器的 ALG（应用层网关）处理，就会被纳入攻击范围。这意味着内网中大量依赖特定端口通信的服务——从监控设备到管理后台——都暴露在映射风险之下。

浏览器厂商判断，封锁 10080 的收益远大于可能带来的兼容性损失。受到影响的服务包括 Amanda Backup 和 VMWare vCenter 等企业级工具，它们恰好使用了上述部分被封端口。

完整的受限端口列表

Google Chrome 在更新中明确封锁了以下 TCP 端口用于 HTTP、HTTPS 和 FTP 访问：

• 69、137、161、554
• 1719、1723、1720
• 5060、5061、6566
• 10080

Firefox 更早在 2020 年 11 月就把 10080 加入黑名单。两家厂商的思路一致：与其逐个修补路由器 ALG 的实现，不如从客户端层面直接阻断对这些高危端口的访问，掐断攻击链的前置条件。

封锁后，如果用户尝试在 Chrome 中访问运行在这些端口上的站点，浏览器会直接返回 ERR_UNSAFE_PORT 错误，不再建立连接。

完整的受限端口列表在 Fetch 规范里可以查到，Chrome 的实现对应 net/base/port_util.cc，Firefox 对应 nsIOService.cpp，都是公开源码，不是隐藏行为。

遇到"服务正常但浏览器打不开"怎么排查

这条路径比反复换浏览器、交 AI 诊断效率高得多：

1. 确认服务本身正常：ss -tlnp | grep 端口 确认监听状态，curl 127.0.0.1:端口 确认本地回环正常
2. 排除本地防火墙：iptables -L 和云控制台安全组先看一眼
3. 换个端口复查：把 10080 改成 18080 或 8080，立刻能验证是不是黑名单命中
4. 查官方名单：Chrome 看 net/base/port_util.cc，Firefox 看 nsIOService.cpp，Fetch 规范里有完整列表

改端口是最快的修复方式。如果已经在用某个被封端口，优先考虑是不是命中了黑名单。

实际操作建议

在搭建 Web 服务时，避开这些端口。高地址段里也要注意查一下黑名单再定。

另外还要注意两点：

• 不要用 2000 以下的端口做自建服务，大部分是系统预留，容易冲突
• 不要用 10080 当"免 sudo 的 80 端口"，这个坑已经被浏览器厂商盯上了，以后类似的高危替代端口也可能被加入黑名单

路由器固件的 ALG 漏洞短期难以根治，浏览器侧的封禁是目前最务实、见效最快的缓解手段。对我们运维者来说，了解这份黑名单本身就是一个必备常识。