你有没有遇到过这样的情况：用某款远程协作软件开视频会议，对方一直显示“正在连接”，自己却能正常说话？或者家里两台设备想直接传文件，结果死活连不上——明明都在同一个Wi-Fi下，怎么还像隔着一堵墙？这堵“墙”，往往就是NAT；而能帮你摸清这堵墙结构的“探路小兵”，就是STUN。
NAT不是防火墙，但比防火墙更爱“藏”
NAT（网络地址转换）是路由器干的活。它把家里的192.168.1.x这类私有IP，换成公网IP发出去，再把回包准确送回来。听起来很贴心？问题在于：它太“贴心”了——默认不让你主动被外网访问。比如你手机发起一个UDP请求到服务器，路由器记下了“这个内网端口发出的包，等回包时要转给它”，但别人直接往这个公网IP+端口发数据？路由器大概率直接丢掉：不认识你，没主动找我，不放行。
STUN不是穿墙工具，是“报坐标”的信使
STUN（Session Traversal Utilities for NAT）协议本身不帮你翻墙、不开端口、不改路由表。它的核心任务就一个：问一句“我现在从外面看，我的IP和端口是多少？”
举个例子：
你的笔记本在公司内网，IP是10.20.30.40:56789，连上STUN服务器（比如stun.l.google.com:19302）后，服务器会原路返回：“嘿，我收到你从 203.208.40.112:62345 发来的请求”。这个203.208.40.112:62345，就是你在公网上的“出口坐标”——也就是NAT分配给这次连接的映射地址。
关系很简单：STUN靠NAT“露脸”，NAT靠STUN“报备”
没有NAT，STUN毫无意义——设备有真实公网IP，直接互相连就行，何必问自己长啥样？
没有STUN，很多P2P应用（如WebRTC音视频、某些游戏联机、局域网穿透工具）就只能乖乖走中继服务器，延迟高、带宽贵、还容易卡。
常见场景对比：
- 你用微信视频通话：微信后台悄悄调用STUN获取双方公网映射，尝试直连；失败才切到腾讯服务器中转。
- 用某款远程桌面软件控制老家电脑：软件启动时先打个STUN请求，确认两边NAT类型（对称型？全锥型？），再决定要不要拉第三方中继。
动手看看你的NAT“性格”
打开浏览器，访问 https://webrtc.github.io/samples/src/content/peerconnection/stun/，点“Start”——页面会显示你当前的本地IP、STUN探测到的公网IP/端口，以及NAT类型（如“Port Restricted Cone”）。注意看：如果本地IP和公网IP完全不同，且端口也变了，恭喜，你正处在典型的家用NAT后面。
小提醒
STUN不是万能钥匙。遇到“对称型NAT”（Symmetric NAT），每次请求都分配新端口，STUN返回的坐标可能下一秒就失效——这时候就得请出TURN（中继）或ICE（组合策略）来兜底。但不管怎样，摸清NAT的脾气，永远是打通P2P的第一步。