NAT 类型在线检测
同端口多目标映射采样 + 出口交叉校验，输出带原始数据与判定依据的 NAT 行为报告
NAT 类型在线检测
在同一条 WebRTC 连接、同一个本地 UDP 端口上，向多个独立 STUN 目标发起请求， 比较各目标观测到的公网映射端点是否一致，据此判定映射行为（EIM / ADM / APDM）并推定 NAT 类型； 再与服务端出口 IP 交叉校验以识别 CGNAT、多出口等情况。
检测全程在浏览器本地完成，HTTP 回显仅用于校验当前访问出口 IP， 不上传任何 ICE candidate。
📊 检测结果
判定依据
可信度依据：尚未开始检测。
映射采样统计
🔌 公网出口与映射行为（交叉校验）
运行环境：待检测。
说明：HTTP 出口 IP 为服务端在传输层观测到的客户端地址，可能已被反向代理改写； STUN 映射地址为 UDP 出口侧 NAT 分配的公网端点。二者不一致通常指向多层 NAT、CGNAT 地址池或多出口负载均衡。
📑 映射行为分析
每一轮采样都在同一条连接内完成，因此轮内所有探测共用同一个本地 UDP 端口； 「本地端口相同、映射端点却不同」只能由「映射取决于目标」解释。
· 等待检测。
📡 NAT 类型速览
NAT1/2/3 的映射行为相同，差异仅在过滤行为；浏览器端只能确认「锥形族」。
❓ 未能确认的检测项
以下项目需要服务端配合或非浏览器协议能力，纯前端检测无法给出结论， 为避免误导，一律标注为未知，不做推测。
判定「是否接受未经请求的外来数据包」需要 STUN 服务端从另一个 IP / 端口主动回连映射端点 （RFC 3489 Test II / III，RFC 5780 CHANGE-REQUEST）。浏览器 WebRTC 不允许构造这类请求。
因此：全锥 / 受限锥 / 端口受限锥 三条子类型在本页只做「族」级判定，不细分。
需在 NAT 同一侧部署 STUN 服务端并观察内网主机能否访问本网络的公网映射地址 （RFC 5780 Test V）。公共 STUN 节点均位于外部网络，无法用于该测试。
影响：决定同一 NAT 后的两台设备能否直连，影响局域网内联机与内网穿透。
浏览器仅在配置 TURN over TCP 时才会发起 TCP 中继连接，无法对任意目标发起 TCP 的 STUN 探测， 因此本页只报告是否观察到 TCP host 候选，不对 TCP 映射行为下结论。
影响：部分企业网络屏蔽 UDP 后，仅 TCP 可用的场景需要单独评估。
🔬 原始探测数据
每条记录对应一次 STUN Binding 请求：探测目标 → 观测到的公网映射端点。
候选地址仅在浏览器本地分析，不会上传后端。
🎮 连接体验评估
依据本次映射行为判定给出，仅供参考。
⚙ 检测流程与判定规则
检测流程
| 阶段 | 动作 | 采集到的数据 |
|---|---|---|
| S0 | 环境检查 | RTCPeerConnection 可用性、安全上下文（HTTPS / localhost） |
| S1 | 本地候选枚举 | host 候选 → 内网 IP / 端口；浏览器启用 mDNS 时地址被混淆为 *.local |
| S2 | 映射行为采样（核心）：单条连接挂载全部 STUN，以同一本地端口向多个目标发 Binding 请求，重复多轮 | 每个目标返回的公网映射端点（IP:端口）、归属目标、协议、单轮耗时 |
| S3 | 出口交叉校验 | 服务端观测到的 HTTP 出口 IP，与 STUN 映射地址集合比对 |
| S4 | 判定引擎 | 映射行为（EIM / ADM / APDM）、端口保持、映射地址数量 → NAT 类型 |
| S5 | 未测项标注 | 过滤行为、Hairpinning、TCP 映射 → 统一标注「未知」并说明原因 |
判定规则
| 观察到的现象（同一本地端口，多个探测目标） | 映射行为 | 结论 |
|---|---|---|
| 未收到任何 srflx 映射，且 host 候选本身是公网地址 | 无转换 | 开放网络 / 无 NAT |
| 未收到任何 srflx 映射，host 候选为内网地址 | 未知 | 无法判定（UDP 受阻或 STUN 不可达） |
| 各目标返回的公网映射端点完全相同 | EIM | 锥形族（NAT1/2/3，子类型未知） |
| 各目标返回的映射地址不同 | ADM / APDM | 对称型（NAT4） |
| 映射地址相同、但映射端口不同 | APDM | 对称型（NAT4） |
| 单轮内仅 1 个目标响应（样本不足） | 未知 | 无法判定，需重试 |
⚠ 边界情况与限制
光猫 + 路由器 + 代理叠加时，浏览器只能观测到最外层的映射结果。内层 NAT 的类型无法单独测量， 因此结论代表「整条路径的等效行为」。内层为对称型、外层为锥形时，整体表现为对称型。
IPv4 地址紧张，宽带、校园网、企业网与移动网络的出口普遍使用 CGNAT。 典型特征是映射地址存在多个（地址池）或与 HTTP 出口 IP 不一致， 往往直接表现为对称型（NAT4）或接近 NAT4 的严格环境。
UDP 被完全屏蔽时采集不到任何 srflx，此时无法区分「没有 NAT」与「无法探测」，本页会标注为未知。 企业代理、SSL 检查设备也可能改写或拦截 STUN 流量，导致映射地址与真实出口不一致。
多 WAN、ECMP、负载均衡或 VPN 环境下，不同目标可能走不同出口，映射地址自然不同。 这会与对称型 NAT 的现象重合，本页只能给出「映射随目标变化」的事实，无法区分是 NAT 分配策略还是路由策略所致。
现代浏览器默认用 mDNS（*.local）隐藏内网 IP，导致「内网 IP/端口」不可见，属于隐私保护而非故障。
双栈环境下 host 候选可能包含公网 IPv6，此时即便 IPv4 侧存在 NAT，IPv6 侧也可能是直连。
不同浏览器对 STUN 节点的选取、候选去重与统计字段（如映射端点的归属目标 url）支持程度不同。
当归属信息缺失时，本页仍可使用「同轮端点是否一致」做判定，但无法指出是哪个目标返回了哪个端点。
❓ 常见问题
为什么不能给出「全锥 / 受限锥 / 端口受限锥」的精确结论？
三者的映射行为完全相同（都是端点无关映射），差异只在过滤行为： 全锥允许任意外部主机回连，受限锥只允许曾被访问过的 IP，端口受限锥还额外限制端口。 测量过滤行为必须让服务端从另一个地址主动向映射端口发起连接，这在浏览器 WebRTC 中无法做到。 因此本页只能确认「属于锥形族」，并明确标注子类型未知。
为什么每轮采样要用同一条连接？
因为 ICE 会为每条连接分配不同的本地 UDP 端口。如果每个 STUN 目标各建一条连接，本地端口不同， 映射端口自然可能不同，此时比较端口毫无意义。只有在同一连接（同一本地端口）内比较， 「映射是否随目标变化」才是有效结论。
「映射地址变化」一定是对称型 NAT 吗？
不一定。对称型 NAT 会造成映射随目标变化，但多出口路由、ECMP、VPN 或代理也会造成同样的现象。 本页会在「上游网络线索」中标注映射地址数量与 HTTP 出口是否一致，帮助你区分， 但最终归属仍需结合网络拓扑判断。
为什么结果和某些「NAT 检测工具」不一致？
不少工具由客户端直接向自建 STUN 服务端发起 RFC 3489 全套测试（含 CHANGE-REQUEST），可以给出精细子类型； 浏览器端受安全策略限制无法复现。若需要精确到 NAT1/2/3，建议使用本地客户端工具或自建 STUN 服务端。
这个检测会收集我的数据吗？
不会。候选地址与映射结果只在浏览器本地计算与展示，不会上传；api/nat.php 仅回显服务端观察到的连接来源 IP，
用于交叉校验。STUN 节点只会看到探测来源地址，这是 STUN 协议的固有行为。
说明：本页通过单个连接内的多目标 STUN 采样观测 NAT 映射行为，并辅以 HTTP 出口交叉校验。 浏览器无法执行完整的 STUN 变更请求或让远端主动回连，因此过滤行为、Hairpinning 与 TCP 映射行为均标注为未知， 结论属于「映射行为推定」，不等同于客户端级 NAT 类型测试。