开了代理还显示其他 IP？WebRTC 候选地址与实际链路怎么查
开了代理，WebRTC 页面却显示另一个 IP，先看那是主机地址、映射地址，还是中继地址，再检查实际选中的连接。候选列表不等于正在传输的链路；但候选未被选中，也不代表地址没有被页面收集。这两点都要核对。
作者：小六｜资料核对日期：2026年11月2日
本文适合浏览器实时通话、数据通道或 WebRTC 检查页面中的 IP 不一致问题。普通网页查询显示的出口，只说明对应网页请求的路径，不能代替另一条实时连接的检查。
先认清候选地址的类型
WebRTC 建立连接时，会通过 ICE 寻找可用路径。“候选”可以理解为备选的联络方式；本端和对端各有候选，最后需要选出配合使用的一对。
以下以本地候选为例，列出三种常见类型：
| 类型 | 通俗理解 | 不能直接推出什么 |
|---|---|---|
| host | 本机接口上的地址 | 不能一律当作宽带公网出口 |
| srflx | 通常经 STUN 发现的地址和端口映射 | 不能仅凭出现就认定媒体使用这条路径 |
| relay | TURN 为连接提供的中继地址 | 不能直接等同于机场节点地址 |
类型定义可查 MDN 候选类型说明。例如 192.168.1.10 属于内网地址，不能拿它与网页显示的公网出口直接比较；host 也不保证总是内网地址，还可能涉及公网接口。
同一页面列出多个地址时，先确认是本地候选还是远端候选。把对方或服务器的地址认成自己的出口，也会得出错误结论。
为什么系统代理开着，结果仍可能不同？
RFC 8828指出，在配置了应用代理、同时仍允许直接访问互联网的环境中，WebRTC 的 STUN 检查可能绕过这类代理并呈现客户端公网地址。浏览器的地址处理策略也会影响结果。
因此，需要分别检查网页请求、候选收集与实时传输。只把系统代理切到开启，不能单独证明三者已经采用同一条路径。若使用 TUN，也要核对实际路由与排除项，相关概念可看本站接管方式与分流指南。
这里还要区分两个问题：页面获得了哪些地址信息，以及媒体或数据真正走了哪条连接。检查目标如果包含地址信息控制，不能只确认最后选中的路径就结束。
在 Chrome 中怎样留下可核对的记录？
可以按下面的顺序操作：
- 先打开
chrome://webrtc-internals/，再在另一个标签页开始一次可中断的测试会话。 - 保持诊断页打开，找到与目标网页和开始时间相符的 PeerConnection。
- 查看该会话的候选类型、选中候选对和传输统计，避免混入其他标签页或旧通话。
- 记下浏览器版本、代理接管方式、测试时间和观察结果，再做下一次对照。
WebRTC 官方的问题报告指南提供了这个诊断入口，并建议在建立通话前打开。界面与字段展示以安装版本为准；没有选中候选对时，应先确认会话是否已经建立。
测试页若只收集候选而没有建立对等连接，就可能没有正在传输的候选对。不要把这类结果当作实际通话媒体路径的完整报告。
统计字段怎样串起来看？
在支持相应标准统计的环境中，transport 的 selectedCandidatePairId 指向选中的候选对，见 MDN 字段说明。
再通过候选对中的 localCandidateId 和 remoteCandidateId 对照两端信息；若提供 bytesSent、bytesReceived，可观察对应计数是否随会话变化。这些字段见候选对统计文档。
不要只挑一条候选记录截图，也不要只看“已收集”就判断“已使用”。统计反映的范围是对应会话与传输，仍需和本机客户端的连接记录、规则和出口一起对照。
TURN 中继和代理节点有什么区别？
TURN 用来帮助 WebRTC 双方转发流量，通常由应用提供或配置。WebRTC 官方说明介绍了其作用。代理客户端选择的节点则属于另一层连接安排，两个名称相似的“中转”概念不能直接画等号。
看到 relay 候选，只说明收集到了 TURN 中继候选；还要检查它是否被选中，以及本机到 TURN 的连接实际经过哪里。因此，TURN 地址和网页出口不同，本身不足以判定代理失效。
要调整设置，怎样避免越改越乱？
先明确目标：是实时连接不可用，还是希望相关连接与地址收集符合自己的路径预期。记录原设置，固定同一浏览器和测试页面，每次只改变一个条件，并重新建立测试会话。
如果涉及 UDP 连通性，可继续看实时应用连接排查。浏览器策略、客户端接管、节点转发能力和应用是否提供 TURN，需要分别确认，不能仅凭一个开关承诺全部解决。
求助时保留候选类型、是否被选中、会话时间与脱敏的路径记录即可。遮住完整公网地址、会话标识、认证信息和订阅链接，不必发送整份诊断转储。
想交流 WebRTC 地址与代理出口不一致的问题，可以带上这些线索：Telegram 联系我
评论