搜「内网穿透原理」，你会拿到两个互相矛盾的答案。
百度百科的词条第一句是「内网穿透，也即 NAT 穿透」——照它的说法，原理是两台设备各自在 NAT 上打一个洞，然后直连，中间那台服务器帮完忙就退场。而你去问任何一家做这门生意的厂商，得到的是另一句：内网穿透就是通过一台有公网 IP 的中转服务器，把外面的请求转发进你的局域网，数据全程经过那台服务器。
两个答案各自都对，也各自只对一半——而且倒向相反的那一半。
更麻烦的是，多数人并不是在做辨析的时候搜这个词的，是在连不上的时候。客户端显示在线，浏览器打不开；或者昨天还好好的，今天就不行了。这时候真正想知道的不是「原理」，而是——这条路一共几段，我该查哪一段。
而 2026 年 9 月初搜出来的十几篇，讲的是 NAT 的四种类型、UDP 打洞的时序、协议的演进，收尾一句「未来发展趋势」。没有一篇在最后告诉你：所以你该按这个顺序查。
两条路都得讲清楚，因为它们的失败方式完全不同——一条卡在带宽上，另一条卡在两端路由器的类型上。搞混了，排查的方向就是反的。
挡住外网的不是防火墙，是 NAT 少了一条记录
你的电脑在局域网里拿到的是 192.168.x.x 或 10.x.x.x 这类地址。这类地址在公网上不路由——不是被禁止，是根本没人认得它，往那儿发的包不知道该去哪。
所以路由器要做一次转换：把出去的包的源地址换成它自己的公网地址，再挑一个空闲端口顶替你的端口。换的时候它记下一条：10.0.0.2:4321 → 1.2.3.4:62000。对方回包时目标是 1.2.3.4:62000，路由器查到这条记录，换回去，送到你机器上。这就是 NAT，这条记录就是映射条目。
关键在于这条记录是什么时候建立的：你主动往外发包的那一下。反过来，外面主动发来的包到了路由器，它查不到任何记录——不知道该转给内网的哪台机器、哪个端口，于是丢掉。
所以外网连不进来，不是有个防火墙在拦。是没有条目可查。这两件事的区别很实际：前者你会去关防火墙，关完还是不通。
这也决定了后面两条路的共同起点——它们都得先由内向外制造一条映射条目，区别只在这条条目建立之后拿它干什么。
内网穿透原理的两条路：先说绕道服务器这条
既然映射条目只能由内向外建立，最直接的办法就是——让内网里的设备主动去连一台有公网 IP 的服务器，连上之后不断开。
这条连接一直挂着，路由器上那条映射条目就一直有效。之后外面的人把请求发给服务器，服务器沿着这条已经建立好的连接，把请求反向送进内网，再把响应原路带回去。
注意这里没有发生的事：服务器从来没有「连进」你的内网。它做不到，也不需要。它只是复用了你自己打出去的那条通道。所谓「穿透」，穿的不是墙，是你自己开的门。
这张图值得多看一眼，因为它说明了一件事：这条路是分段的。浏览器到公网入口、公网入口到服务器、服务器到客户端、客户端到本地服务——四段里任何一段出问题，你在浏览器上看到的都是同一个现象：「打不开」。但原因和该查的地方完全不同。这一点留到最后一节。
代价也在这张图里：数据全程要经过中间那台服务器。于是速度的上限是那台服务器分给你的带宽，而不是你家的宽带；而带宽是要花钱买的——免费内网穿透的额度与代价那篇把这笔账算过，这里不重复。
还有一件事这张图没说，但读者一定会想到：数据既然全程经过第三方，那安全吗？这个问题是真的，后面单独有一节。
P2P 打洞：让服务器介绍完就退场
中转那条路的代价是数据全程经过服务器。那能不能不经过？
难点很清楚：两端都在内网，都没有一个对外的固定地址，谁也找不到谁。但上一节那条约束里其实藏着办法——两边都能主动往外发包，都能因此在自己的 NAT 上制造一条映射条目。
于是可以这样：双方先各自向同一台服务器报到。这一下做了两件事，一是在各自的 NAT 上留下了条目，二是让服务器看到了两边转换之后的公网地址和端口——注意是转换后的，两端自己并不知道那个地址长什么样。
服务器把这两个地址交换给双方。接着 A 往 B 的公网地址发一个包。这个包多半到不了 B，因为 B 的 NAT 上还没有任何关于 A 的记录，查不到就丢掉。但它在 A 自己的 NAT 上留下了一条：我往那个地址发过东西。于是 B 再往 A 发包时，A 的路由器查到了这条记录，放行。洞就是这么打通的。
这件事几乎都在 UDP 上做，下面这张图也是。TCP 也能打，但它要求两端几乎同时发起连接，路由器之间的行为差异更大，成功率低得多；所以常见做法是先用 UDP 把直连打通，再把要传的东西装进去跑。
整个过程里，服务器没有转发过一个字节的业务数据，它只交换了两个地址。介绍做完就退场，之后的流量走两端直连。
这是两条路在成本上的分水岭。中转那条，你传多少服务器就得转多少，带宽是硬成本；打洞这条，服务器只在建立连接时出场一次。有些工具敢承诺「不限速」，底气就在这里。
顺带纠正一个流传很广的划分：不少文章把 P2P 打洞划到 WebRTC、实时音视频、P2P 下载那一类去，言下之意是它跟「访问自己家里那台设备」没关系。并不是——去搜一下 stun内网穿透，2026 年 9 月初的前排大半是 NAS 用户在用它跑远程访问。还有个更隐蔽的默认：一说到「两端都在内网」，很多人条件反射就是中转，而这恰恰是打洞最典型的场景。
但它有个前提没说：打洞不是每次都能成。
打洞成不成，看两端 NAT 的组合
上一节那台服务器做的事——告诉两端「你在外面长什么样」——在标准里有个名字：STUN。
但那一节我含糊过去一个地方。服务器交给 B 的那个地址，是 A 向服务器报到时留下的。A 转头去连 B 的时候，路由器给它的还是同一个外部端口吗？
这个问题的答案不取决于 A，取决于 A 家的路由器。而路由器们的做法不一样——这就是 NAT 分型的由来。常见的分法是四型，差别全在「谁能顺着这个洞回来」：
- 完全锥形——只要你往外发过包，任何人都能顺着那个外部端口进来。
- 地址限制——只有你发过包的那台主机能回来，它换个端口也行。
- 端口限制——再严一档：必须是你发过包的那台主机、那个端口。
- 对称型——你每换一个目标，路由器就给你换一个外部端口。这一型最难打，因为服务器看到的那个端口，不是 A 转头去连 B 时会用的那个。
十六格里只有三格是叉，归起来是两种情况：对称型碰上端口限制，以及两端都是对称型。
这值得强调一句：「对称型就打不通」是个流传很广的简化说法。对称型碰上完全锥形或地址限制照样能通——那两型根本不校验端口，你换不换它都放行。真正打不通的，是双方都在挑剔端口的时候。
还有一件事该说清楚：上面这套四型分类出自 RFC 3489，也就是 STUN 的初版。后来的 RFC 4787 认为它不够精确，改用两个正交维度来描述——映射行为和过滤行为，各自三档。四型是这两个维度的常见组合，好记，但描述能力不如两维度。中文互联网上搜到的几乎都是四型，所以这篇也按四型讲；要抠细节，看 RFC 4787。
那怎么知道自己家是哪一型？家用路由器后台一般不告诉你。最容易拿到的现成结论来自游戏机——PS、Xbox、Switch 的网络测试都会报一个 NAT 类型（开放 / 中等 / 严格）。它和这四型不是严格对应，但方向一致：报「严格」的，多半是端口限制或对称型，打洞就悬。
还有一层要留意。如果你的宽带没有公网 IP，你多半在运营商的大内网里，等于中间又多了一层转换、多了一道关卡。这是国内打洞成功率普遍不如直接拨号环境的一个现实原因。
那打不通就用不了了？不是。打洞类工具的通行做法是回落到中转——先试直连，试不通就走服务器转发。你那侧看到的只有「连上了」，看不到它走的是哪条。
这也正好解释了开头那两个定义为什么能长期共存：同一个工具，在你家可能走的是直连，在别人家里走的是中转。
和端口映射、DDNS 到底差在哪
讲到这里可以顺手厘清几个常被混为一谈的东西。它们的区别不在技术细节，在前提。
| 方案 | 前提与用途 |
|---|---|
| 端口映射 | 要有公网 IP。让外面能找到内网某台设备的某个端口 |
| UPnP | 要有公网 IP。同上，只是让设备自己去路由器上加这条规则，不用你手动填 |
| DDNS | 要有公网 IP。它解决的是「地址会变」，不是「没有地址」 |
| 内网穿透 | 不需要公网 IP。压根就没有公网 IP 的时候怎么办 |
前三行的前提都是同一个：你得先有一个公网 IP。端口映射是你手动在路由器上写一条映射条目——注意，还是那个词，只不过这一次是你自己写的，不是由内向外自动建的。UPnP 是让设备自己去写。
DDNS 最常被误当成内网穿透的替代品，其实两者解决的问题是正交的：一个是「地址会变」，一个是「没有地址」。你要是没有公网 IP，DDNS 把域名解析过来，指到的还是一个内网地址，照样没人能访问。
判断很简单：先确认你到底有没有公网 IP。方法是登录路由器看 WAN 口拿到的地址，再跟你在网上查到的出口 IP 比一比——两个一样就是有；WAN 口上是 100.64.x.x 或 10.x.x.x 这类地址，说明你在运营商的大内网里。
有，端口映射是最直接的路，没有中间商也就没有中间商的代价；没有，才轮到这篇讲的两条路——没有公网 IP 时的内网穿透方案那篇专门讲了这种情况。
数据流经第三方，这个顾虑是真的
走中转那条路，数据确实全程经过一台不属于你的服务器。这一点不该绕过去。
但要分开两件事：经过，和看得见。 HTTPS、SSH、RDP 这些协议本身就是加密的，中间那一段拿到的是密文——这不取决于服务商做了什么，是协议给的。反过来，你要是映射了一个明文 HTTP 的后台，那中间当然什么都看得见，不管走的是谁家的服务器。
不过更现实的风险不在这一段。你把一个服务映射到公网，它就真的在公网上了。 扫描器不需要知道你是谁，它只是在扫全网的开放端口；一旦 SSH 或远程桌面上了公网，通常很快就会有东西找上门。比起中间那台服务器，这个才是大多数人真正会栽的地方。
能做的事也在这一层：把入口收窄。只允许特定 IP 段访问、给映射加访问口令、开爆破防护。这些都不需要你懂底层，是界面上的开关。
顺带纠正一个流传的说法：有文章讲「因为内网设备并不与外网设备直接相连，所以安全性毋庸置疑」。这话是反的。不直连只说明没人能直接摸到你的内网地址，而你主动映射出去的那个服务，是实打实暴露在公网上的——内网穿透违法吗那篇把安全与合规这两层讲得更细。
所以连不上的时候，该查哪一段
回到开头那个场景。客户端显示在线，浏览器打不开。
有了前面的机制，这条路的形状就清楚了：你的浏览器 → 公网入口 → 中间那台服务器 → 装在内网的客户端 → 你要访问的那个本地服务。 四段里任何一段断掉，你在浏览器上看到的都是同一个「打不开」，但要查的地方完全不同。
按出问题的概率从高到低：
先看本地服务起没起。 这是最常见的一段，也是最容易被跳过的——因为它离「网络问题」最远，人的第一反应总是去怀疑网络。诊断信息里如果写着 connection refused 或者 i/o timeout，说的就是这一段：客户端所在的那台机器上，那个端口根本没有东西在监听。先在本机访问一次，本地都不通，外面自然不通。
再看映射本身写对没有。 本地地址填成了 127.0.0.1 而服务只监听内网网卡、端口填错一位、协议选了 TCP 但服务走的是 UDP——这些都会表现成「连不上」。
再看客户端在不在线。 机器休眠、网络切换、客户端被防火墙拦掉，都会让那条由内向外的连接断掉——一断，路由器上那条映射条目也就过期了，整条路的地基没了。
最后才轮到公网那一侧。 浏览器缓存、DNS、你当前所在网络的出站限制（公司网络封非常用端口是常事）。这一段的特征是：换个网络、换台设备试一下，往往就通了。
至于中间那台服务器那一段——你查不了，也最少出问题。它有没有就绪，诊断信息会直接告诉你。
如果你映射的是群晖或其他 NAS，NAS 内网穿透那篇有更贴合这个场景的排查步骤。
原理的用处不在于背下来。它的用处是：出问题的时候你知道这条路一共几段、每一段能坏在哪，于是不必挨个乱试。
开头那两个互相矛盾的定义，现在应该不矛盾了——它们讲的是同一条路的两种走法。你手上那个工具此刻走的是哪条，取决于两端路由器的类型和它当时的判断；但不管走哪条，路的形状是一样的：先由内向外开一条口子，再让外面的请求顺着它进来。
