代理开了但 DNS 解析失败怎么办：7步排查与复测

更新于 2026-10-25 · kejibear.shop

简答：先不要反复换节点：先用IP与两个不同域名做分流测试。若IP可达而域名失败，再依次检查系统代理、规则直连、浏览器安全DNS、Hosts、私人DNS和客户端日志；修复后用命令行与浏览器分别复测。

定义：代理环境中的DNS解析失败，是域名没有被正确转换为IP，或DNS查询走了与代理、浏览器或系统设置不一致的路径。

先做分流测试：判断到底是不是DNS故障

“代理已连接”不等于网页请求已经完成。客户端可能只建立了代理通道，但系统代理没有生效、规则把请求直连、浏览器使用了独立DNS，或者代理端无法解析目标域名。最快的办法是先做三组对照：访问一个已知可用的IP地址、查询两个不同域名、再用命令行发起一次代理请求。

现象	优先判断	先做什么
IP和所有域名都失败	节点、系统代理、TUN、VPN或防火墙	确认系统代理或VPN状态，暂时用全局模式做单变量对照，并查看客户端日志
IP可达，多个域名失败	本地或代理端DNS路径	执行`nslookup`、`dig`或`Resolve-DnsName`，记录超时、NXDOMAIN或正常回答
只有一个域名失败	域名记录、Hosts、规则或IPv6记录	换第二个域名，并分别查询A和AAAA记录
命令行成功，浏览器失败	浏览器代理、DoH、扩展或缓存	检查浏览器独立代理和安全DNS，使用无痕窗口复测
解析成功但连接超时	TCP、TLS、IPv6、MTU或出口链路	用`curl -v`验证代理请求，再转向连接层排查

微软的DNS排查文档把问题分为DNS客户端、DNS服务器以及中间网络设备三类，并建议核对IP、网关、DNS服务器、查询结果和缓存。可参考Microsoft Learn 的 Windows DNS名称解析故障说明。

理解解析路径：本机DNS、浏览器DNS还是代理端DNS

目标域名的解析可能发生在本机网络、浏览器、代理客户端、虚拟网卡或代理服务器。排查时不要只看客户端是否显示“已连接”，而要确认实际的DNS请求从哪里发出、由谁返回结果。

SOCKS5协议允许请求中携带IPv4地址、IPv6地址或域名地址类型。RFC 1928规定了客户端与SOCKS服务器协商、发送目标地址以及由服务器处理连接请求的基本流程，具体客户端是否把域名交给代理端解析，则要结合软件实现和日志确认，不能仅凭“SOCKS5”四个字判断。协议参考RFC 1928：SOCKS Protocol Version 5。

浏览器的DNS over HTTPS（DoH，基于HTTPS传输DNS查询）也可能独立于系统DNS工作。RFC 8484定义了DoH的协议形式；Firefox官方说明则提供了Default、Increased、Max、Custom和Off等保护级别。代理连接异常时，可以暂时记录当前设置，再关闭浏览器独立DoH做一次对照，确认是否存在两条DNS路径。参考RFC 8484：DNS Queries over HTTPS和Firefox官方DNS over HTTPS说明。

判断原则是一次只改一个变量：先记录代理模式、DNS模式、浏览器设置和网络类型，再逐项关闭或切换。不要同时更换节点、DNS、浏览器和VPN，否则即使恢复，也无法知道真正原因。

Windows：用命令确认DNS、缓存和代理请求

查看网络配置：打开命令提示符，执行ipconfig /all，记录当前网卡的IPv4地址、默认网关和DNS服务器。微软文档建议先核对这些项目，确认设备使用了有效的TCP/IP配置和正确的DNS地址。
清理DNS缓存：执行ipconfig /flushdns，重新打开浏览器后再测试。该命令只清理本机DNS缓存，不会修复节点、代理端DNS或防火墙问题。
查询目标域名：执行nslookup example.com，记录Server、Address和返回状态；再执行Resolve-DnsName example.com，观察A、AAAA记录是否都能返回。
区分超时与不存在：如果命令提示超时，重点检查DNS服务器是否可达、UDP或TCP 53是否被防火墙拦截，以及代理客户端是否接管了DNS。如果返回NXDOMAIN或“Name does not exist”，先换第二个域名，并检查Hosts文件和规则。
验证代理是否真的参与：按客户端支持的协议执行类似curl -v -x http://代理地址:端口 https://example.com/的测试。SOCKS客户端可以尝试其支持的远程解析写法，例如curl -v --proxy socks5h://代理地址:端口 https://example.com/；这里的协议、地址和端口必须替换为自己的配置，命令结果只用于定位，不代表所有客户端都以同样方式解释参数。

微软资料指出，UDP 53被防火墙规则阻断、Hosts文件存在错误映射、DNS服务器地址错误或不可达、多个DNS服务器中部分不可达，都可能造成名称解析故障。若DNS查询超时，先检查安全软件、防火墙和网络设备，而不是立即判断节点失效。

macOS与Linux：用dig、系统DNS和日志交叉验证

macOS和Linux可以先执行dig example.com，查看status、SERVER和ANSWER SECTION；再分别执行dig A example.com与dig AAAA example.com，确认是全部记录失败，还是只有IPv6记录异常。

macOS查看DNS：按2026-10界面核对，打开“系统设置—网络—当前网络—详细信息—DNS”，记录手动填写的DNS服务器。若同时安装了VPN、过滤器或代理客户端，先记录其DNS接管状态。
Linux查看解析服务：检查/etc/resolv.conf；使用systemd-resolved的系统可执行resolvectl status和resolvectl query example.com。如果NetworkManager、VPN和代理客户端都在管理DNS，应暂时只保留一条接管路径。
验证请求路径：使用curl -v通过当前HTTP或SOCKS配置请求测试域名。若代理握手成功但域名解析失败，问题更接近代理端DNS或远程解析；若curl成功而浏览器失败，则重点检查浏览器代理、DoH、扩展和缓存。
检查日志入口：在客户端打开连接日志、DNS日志或TUN日志，搜索timeout、resolve、NXDOMAIN、拒绝、TLS和连接失败等关键词。公开记录时不要粘贴账号、密码、订阅链接或完整凭据。

如果改过DNS、代理或VPN配置，请保留原值和回滚方法。一次只改变一个设置，完成查询和网页复测后，再进入下一项。

iOS与Android：先排除系统DNS和VPN冲突

iOS三步排查

导入并开启：确认配置已经导入，系统VPN权限已允许，客户端显示已连接；同时检查是否存在其他VPN、内容过滤器或设备管理配置。
验证：访问两个不同域名，并查看客户端的连接日志或DNS测试结果。若命令行不可用，就用客户端内置测试和浏览器访问结果做对照。
复测与回滚：暂时关闭其他VPN、过滤器和浏览器独立DNS，再重新连接。若仍需重置网络设置，Apple说明该操作会移除Wi‑Fi网络与密码、蜂窝网络设置、VPN和APN设置，因此应放在其他方法之后，并先备份当前配置。参考Apple关于iPhone或iPad无法连接网络的支持说明。

Android三步排查

导入并开启：确认客户端配置已导入、VPN权限已允许，并检查“始终开启VPN”或“阻止无VPN连接”等选项是否影响测试。
验证：分别在Wi‑Fi和移动数据下测试两个域名，查看客户端日志中的DNS模式、TUN状态和查询错误。
检查私人DNS：按2026-10界面核对，进入“设置—网络和互联网—私人DNS”。Android官方提供“关闭”“自动”和“私人DNS提供商主机名”三种选项；排障时先记录原设置，再暂时切换到“自动”做单变量对照。参考Android官方高级网络设置说明。

移动设备最常见的排查难点是系统VPN、私人DNS、浏览器安全DNS和客户端TUN同时接管。不要一次关闭所有功能后直接下结论，应记录每次改变，并在Wi‑Fi和移动数据上分别复测。

按错误提示选择处理顺序

错误表现	可能位置	处理顺序
DNS_PROBE_FINISHED_NXDOMAIN	域名无可用记录、Hosts、错误DNS或规则	换第二个域名，查询A和AAAA记录，检查Hosts与规则
ERR_NAME_NOT_RESOLVED	浏览器没有得到可用解析结果	检查浏览器DoH、系统代理和客户端远程DNS设置
DNS查询超时	DNS服务器不可达、UDP/TCP 53受阻或代理端无响应	检查防火墙、网络切换、客户端日志和DNS服务器地址
解析成功但网页超时	TCP、TLS、IPv6、MTU或出口连接	用curl验证代理请求，再检查IPv4/IPv6和客户端规则
只有浏览器打不开	浏览器代理、DoH、扩展或缓存	无痕窗口测试，关闭扩展和独立DNS后复测

如果只有一个域名失败，不要马上把问题归因于节点；如果多个域名、多个网络和命令行均失败，才适合进一步检查客户端、节点或网络侧故障。涉及网络服务时，请遵守所在地法律与服务条款。

修复后复测：用记录避免误判

修复后至少完成五项复测：一个此前失败的域名、一个不同域名；一次Wi‑Fi和一次移动数据或其他网络；一次A记录和一次AAAA记录查询；一次浏览器访问和一次curl代理请求；最后查看客户端日志，确认请求没有被错误地直连。

测试时间：YYYY-MM-DD HH:mm
设备与系统：Windows、macOS、iOS或Android
网络类型：Wi‑Fi、移动数据或其他
代理模式：规则、全局、TUN或系统代理
DNS路径：系统、浏览器DoH、客户端远程DNS、私人DNS或未知
目标域名：可脱敏记录
查询结果：成功、超时、NXDOMAIN或其他
curl结果：代理成功、代理拒绝、DNS失败、TLS失败或超时
日志关键词：只记录错误类型，不粘贴账号、密码、订阅链接或完整凭据

结论应写成“在什么设备、什么网络、什么代理模式下，哪些域名成功或失败”，而不是笼统写“DNS坏了”。多网络、多设备对照后仅目标服务异常时，可考虑已公开主体信息的服务，再按本文方法核对DNS与客户端日志。

常见问题

代理显示已连接，为什么DNS仍然会失败？

连接状态通常只代表客户端与代理节点建立了通道，不代表系统DNS、浏览器DNS、目标TCP连接和HTTPS请求都正常。应先用IP与两个域名做分流测试，再查看客户端日志。

nslookup成功但网页仍打不开，是否说明DNS没问题？

只能说明nslookup使用的解析路径返回了结果，不能证明浏览器使用同一条路径。还要检查浏览器代理、DoH、规则、TCP连接和TLS握手。

SOCKS5是否一定由代理服务器解析域名？

不一定。RFC 1928定义了SOCKS5可以传递域名地址类型，但具体客户端是否把域名交给代理端处理，要以软件实现、配置和日志为准。

把DNS改成其他服务器就一定能解决吗？

不一定。若系统代理未生效、TUN冲突、防火墙阻断、Hosts错误或代理端解析失败，单纯更换本地DNS不会修复故障。

为什么只有一个网站打不开，其他网站正常？

可能是该域名自身记录、Hosts、规则、IPv6记录或站点连接问题。先测试第二个域名，再分别查询A和AAAA记录。

Windows的ipconfig /flushdns会删除代理配置吗？

不会。该命令只清理本机DNS缓存，不会删除代理、VPN、订阅或路由器配置。执行后仍要重新查询并观察结果。

关闭浏览器安全DNS后恢复，应该一直关闭吗？

不必直接下结论。先确认代理客户端是否提供稳定的DNS接管路径，再根据兼容性、隐私和所在网络要求选择统一的DNS方式。

Android私人DNS应该选关闭、自动还是指定主机名？

排障时先记录原设置，再用“自动”做单变量对照；测试完成后根据客户端要求和网络环境决定是否恢复原值或使用指定主机名。

iPhone重置网络设置会删除什么？

Apple说明会移除Wi‑Fi网络与密码、蜂窝网络设置、VPN和APN设置，因此应先保存当前配置，并把网络重置放在其他排查方法之后。

排查时可以同时开启多个VPN或DNS工具吗？

不建议。多个工具同时接管VPN、TUN、系统代理或DNS会增加变量；应保留原配置，逐个关闭冲突组件并记录每次变化。