解析请求走出代理通道，真实位置就暴露了。风控和网络问题的共同点是：表面症状相似，根因差别很大，先取证再动手。

下面按“先判断范围、再处理、最后防复发”的顺序展开，涉及 DNS泄漏、代理 的关键动作都给了具体做法，可以照着走。

情形一

系统 DNS 直连本地运营商。

出现异常先回退到上一个已知可用状态，再慢慢找原因。

情形二

浏览器自带 DoH 绕过代理。

容易踩的坑：只改出问题的那一台、不做同步，后面会反复踩同一个坑。

情形三

代理只转发 TCP，UDP 解析直连。

条件允许的话先在测试环境走一遍，再动生产。

验证

用 DNS 泄漏检测页看解析服务器归属。

常见问题

Q：DNS泄漏这类问题，最快的判断办法是什么？
先确认现象的范围：只有单台还是全部、只在某个时段还是持续。范围一缩小，原因基本就浮出来了。

Q：按文中的步骤做完，还需要注意什么？
把处理过程和最终生效的参数记下来。同类问题再出现时直接对照记录，比重查一遍快得多。

小结

回到这篇的四个环节：情形一、情形二、情形三、验证。把证据链固定成流程，比反复试错划算得多。相关判断标准建议做成表格长期维护。

相关阅读：WebRTC 泄漏是怎么回事、时区语言和 IP 对不上会怎样、Canvas 与 WebGL 指纹怎么绕过。