代理能连接但打不开网页怎么办？Windows、macOS、iPhone、Android 排查

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

简答：代理显示“已连接”只说明客户端完成了某一段连接，不代表浏览器已经正确使用代理，也不代表目标网站一定能返回页面。最快做法是先关闭代理确认原始网络，再用无痕窗口测试；随后检查系统代理开关、地址和实际监听端口，最后依次排查 DNS、规则、TUN、节点出口和浏览器缓存。

定义：“代理能连接但打不开网页”是指客户端显示连接或延迟正常，但浏览器请求在本机代理、DNS、分流规则、节点转发或目标网站响应中的某一环节失败。

先做三分钟定位：不要先盲目换节点

先关闭代理或暂停客户端，用同一浏览器打开一个你平时能访问的普通网站。如果关闭后仍打不开，问题优先落在 Wi-Fi、宽带、系统 DNS 或浏览器本身；如果关闭后能打开、开启后才失败，继续检查代理设置和客户端转发。

故障现象与优先检查项

现象	优先判断	先做什么
所有网站都打不开	系统代理、监听端口、节点转发或 TUN	核对地址、端口和代理类型，再短时切换全局模式
只有部分网站打不开	规则误分流、DNS 解析或目标网站限制	查看该域名命中的策略，临时改为代理或全局测试
只有一个浏览器打不开	浏览器代理、扩展、缓存或旧连接	用无痕窗口、访客模式或另一浏览器对比
客户端延迟正常但网页打不开	延迟测试只验证了部分握手，不等于网页请求完整成功	测试实际网页请求、检查出口和规则，不要只看延迟数字

全局模式只用于短时验证：如果全局模式能打开而规则模式不能，说明问题更可能在规则或策略组；验证结束后恢复规则模式，避免让所有流量长期走同一策略。

第一层：检查系统代理、协议类型和监听端口

系统代理里的服务器地址、端口和代理类型必须与客户端当前配置一致。HTTP、HTTPS 和 SOCKS5 不是可以随意互换的标签；例如客户端只监听 SOCKS5，而系统却填成 HTTP，浏览器可能直接报代理连接失败。端口不要照抄固定示例，应以客户端“端口、混合端口、HTTP 端口或 SOCKS 端口”页面显示的实际值为准。

Windows

打开“设置”→“网络和 Internet”→“代理”，检查“自动检测设置”、脚本和“手动代理”是否与当前客户端配置一致。微软说明 Windows 支持自动检测、脚本和手动代理，手动配置需要服务器地址或 IP 与端口，详见 Windows 代理设置说明。
在命令提示符执行 netstat -ano | findstr LISTENING，只核对客户端实际配置的端口是否处于 LISTENING。没有监听，说明客户端未启动对应入站；端口被其他程序占用，则回到客户端修改端口或关闭冲突程序。
浏览器若显示 ERR_PROXY_CONNECTION_FAILED，优先检查代理地址、端口和是否误开了旧脚本；不要先清空全部浏览数据。

macOS

打开“系统设置”→“网络”→当前网络→“详细信息”→“代理”。Apple列出的代理类型包括 HTTP、HTTPS、SOCKS、自动代理发现和 PAC 文件，路径与说明见 Mac 代理设置说明。
确认客户端监听类型与系统勾选项一致；如果使用 SOCKS，只在 SOCKS 代理处填写地址和端口，不要同时留下旧的 HTTP 或 PAC 配置。
终端执行 scutil --proxy 查看系统代理状态，输出中的 HTTPEnable、HTTPPort、SOCKSEnable 和 SOCKSPort 应与客户端实际配置对应；显示启用但端口不一致，就是优先修复项。

iPhone 与 Android

iPhone：在“设置”→“Wi-Fi”→当前网络右侧信息按钮→“配置代理”中检查关闭、自动或手动状态。Apple资料确认 iOS 的 Wi-Fi 高级设置可配置 HTTP 代理与 DNS，具体入口可能随系统版本或管理策略变化，参考 Apple iOS 网络高级设置说明。
Android：打开“设置”→“网络和 Internet”→“Internet”→当前 Wi-Fi→“编辑”→“高级选项”→“代理”。Google说明该路径可选择代理配置类型并保存设置，但不同厂商和 Android 版本的菜单名称可能不同，参考 Pixel 代理设置说明。

第二层：DNS、缓存与解析报错怎么处理

ERR_NAME_NOT_RESOLVED 或 DNS_PROBE_FINISHED_NXDOMAIN 通常表示域名解析没有得到可用结果，但不能仅凭错误码断定一定是 DNS 污染；也可能是域名写错、规则把 DNS 请求送到错误的解析器，或本地缓存仍保存旧结果。

Windows DNS 检查与清理

执行 nslookup example.com，把 example.com 换成实际打不开的域名。若返回“Non-existent domain”或超时，记录当前 DNS 服务器和结果；若能返回 IP 但浏览器仍打不开，继续检查代理、规则和 TLS。
管理员命令提示符执行 ipconfig /flushdns，然后重新打开浏览器测试。若仍失败，再按微软给出的网络重置顺序执行 netsh winsock reset、netsh int ip reset、ipconfig /release、ipconfig /renew、ipconfig /flushdns，完成后重启 Windows；命令顺序见微软 Windows Wi-Fi 排查说明。

macOS DNS 检查与清理

终端执行 dig example.com 或 nslookup example.com，观察是否返回地址、查询是否超时，并记下使用的 DNS 服务器。
先关闭再打开 Wi-Fi，或在“系统设置”→“网络”→当前网络→“详细信息”→“DNS”中删除明显失效的手动 DNS 后重新测试。
如需刷新 macOS 的本地 DNS 缓存，可在终端执行 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder，输入密码时终端不会回显字符；命令没有成功提示并不代表网页一定恢复，必须重新执行 dig 和浏览器测试。Apple文档说明 macOS 与 iOS 可由系统或网络扩展管理 DNS 配置，具体取决于系统版本和配置方式，见 Apple DNS Settings 文档。

如果使用 mihomo 类客户端，DNS 配置可能包含 nameserver、fallback、respect-rules、fake-ip 等字段。不要随意复制别人的整段配置；先检查 DNS 是否启用、规则是否生效，以及代理节点域名是否有单独的解析策略。字段含义以 mihomo DNS 配置文档为准。

第三层：规则、TUN 与节点出口分别验证

节点延迟正常只代表某个测试请求在规定时间内完成，不等于所有网页、DNS、HTTPS 或长连接都能正常转发。一个常见情况是规则把目标域名判定为 DIRECT，于是浏览器实际没有走代理；另一种情况是 TUN 已开启，但虚拟网卡、系统路由或防火墙没有正确接管流量。

打开客户端日志，访问一个明确打不开的域名，查看该请求命中的策略：若显示 DIRECT，临时改为代理策略；若显示代理但连接立即失败，继续查看节点握手、TLS 或超时信息。
短时切换全局模式测试。全局模式可打开、规则模式打不开，优先修规则；两者都打不开，优先修节点、DNS、端口或 TUN。
如果依赖 TUN，检查客户端是否显示虚拟网卡已启用、自动路由是否打开，以及系统安全软件是否拦截核心程序。mihomo 文档说明 TUN 可通过自动路由把流量导入虚拟接口，也列出了 Windows 防火墙放行核心程序和 macOS 防火墙添加应用的处理方向，参考 mihomo TUN 文档。
若只有某个网站失败，使用浏览器无痕窗口并测试同域名的其他页面。如果只有该站点失败，可能是目标网站的地区、出口 IP、账号状态、TLS 或风控限制；此时不要反复刷新，也不要提交账号、Cookie、验证码或完整日志，先联系服务提供方或网站管理员确认。

按平台快速复核：Windows、macOS、iPhone、Android

四个平台的最短复核路径

平台	设置路径	判读重点
Windows	设置 → 网络和 Internet → 代理	手动代理是否开启、地址和端口是否匹配；命令行用 `netstat -ano` 核对监听
macOS	系统设置 → 网络 → 当前网络 → 详细信息 → 代理	是否残留 PAC、HTTP 或 SOCKS；用 `scutil --proxy` 对照状态
iPhone	设置 → Wi-Fi → 当前网络 → 配置代理	关闭、自动、手动三种状态不要与客户端重复叠加；DNS 也要检查
Android	设置 → 网络和 Internet → Internet → Wi-Fi → 编辑 → 高级选项 → 代理	不同厂商路径可能不同；确认 Wi-Fi 代理与客户端模式没有冲突

若你使用的是按应用接管流量的客户端，系统 Wi-Fi 代理和客户端本地代理可能同时生效。遇到循环代理、网页一直转圈或全部网站都失败时，先只保留一种接管方式，再测试。

常见报错与对应动作

不要只看错误码，按现象执行下一步

报错或现象	常见环节	处理动作
`ERR_PROXY_CONNECTION_FAILED`	代理地址、端口、协议或客户端监听	核对实际端口，用 `netstat` 或 `scutil --proxy` 检查；关闭旧 PAC
`ERR_NAME_NOT_RESOLVED`	DNS、缓存、规则中的 DNS 分流	执行 `nslookup` 或 `dig`，清理缓存后再测
`DNS_PROBE_FINISHED_NXDOMAIN`	解析器认为域名不存在或返回空结果	核对域名拼写，换网络对比，检查客户端 DNS 策略
网页一直转圈但无明确报错	节点转发、TLS、MTU、浏览器旧连接或目标站响应	新开无痕窗口，临时换节点或网络；只有在服务文档明确要求时才调整 MTU

什么时候应该停止本地排查

出现以下情况时，不建议继续反复改配置：多个设备和网络都无法访问同一目标；客户端日志显示服务端拒绝、认证失败或节点超时；目标网站明确返回地区、账号或安全验证提示；或者只有该目标站点失败而其他网站正常。此时保存脱敏后的时间、平台、错误码、使用的策略名称和节点地区，删除订阅链接、账号、Cookie、完整 IP 和私密日志后，再联系服务提供方。不要为了“验证一下”关闭系统安全保护，也不要安装来源不明的证书或配置文件。

已核实/未核实速查：截至 2026-10-19，本文引用的系统设置、Windows 网络命令、Apple 网络配置、Android 代理路径和 mihomo 配置字段均来自对应公开资料；不同客户端版本的菜单名称、默认端口、节点状态和实际可用性未在本文逐一核实，应以当前软件界面与服务提供方文档为准。

下一步：把客户端设置核对到具体平台

如果你已经确认是客户端菜单或订阅配置问题，可以继续阅读 Clash Verge Rev 怎么导入订阅链接？完整步骤与失败排查；使用 iPhone 或 iPad 时，参考 Shadowrocket 怎么添加订阅链接？iPhone 与 iPad 操作步骤；使用 Stash 时，查看 Stash 怎么导入订阅和配置节点？第三方整理的操作与排查步骤；Windows 与 macOS 用户也可以分别对照 Clash Verge 使用教程和 Clash Verge for Mac 使用教程。这些页面只用于操作路径参考，具体端口、协议和配置字段仍以当前客户端与配置文件为准。

常见问题

代理显示已连接，为什么节点延迟正常，网页还是打不开？

延迟测试通常只覆盖某个测试请求或握手，不能证明 DNS、规则、HTTPS、网页正文和长连接都正常。先看访问目标域名时的日志和命中策略；如果规则模式失败而全局模式成功，优先修规则；两种模式都失败，再查端口、DNS、TUN 和节点转发。

遇到 ERR_PROXY_CONNECTION_FAILED，应该先换节点吗？

不建议第一步就换节点。先检查客户端是否仍在监听实际配置端口，系统代理地址和端口是否一致，HTTP 与 SOCKS5 类型是否填错，以及浏览器是否残留旧 PAC。确认本地设置无误后，再用另一个节点或网络做对比。

Windows 和 macOS 怎么清理 DNS？

Windows 可在管理员命令提示符执行 <code>ipconfig /flushdns</code>，必要时按微软顺序执行 Winsock、TCP/IP、释放续租和 DNS 刷新命令。macOS 可先执行 <code>sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder</code>，随后用 <code>dig 域名</code>重新查询；清理缓存后仍要检查客户端 DNS 和规则。

iPhone 或 Android 需要同时设置系统代理和客户端代理吗？

通常先选择一种流量接管方式进行测试，不要无目的地叠加。iPhone 在当前 Wi-Fi 的“配置代理”中检查状态，Android 在当前 Wi-Fi 的高级选项中检查代理；如果客户端本身使用系统 VPN、TUN 或本地代理，系统 Wi-Fi 代理可能与它冲突，具体以客户端文档为准。

网页只有一个站点打不开，是不是节点坏了？

不一定。单个站点失败还可能来自目标网站的出口 IP 限制、地区策略、账号状态、TLS、Cookie 或临时故障。先测试同域名其他页面、无痕窗口和另一网络；如果其他网站正常且目标站点持续失败，应停止反复刷新并联系服务提供方或网站管理员。

排查时可以把完整日志、订阅链接或 Cookie 发给别人吗？

不建议。分享前应删除订阅链接、账号、Cookie、验证码、完整 IP、内网地址和身份标识，只保留平台、时间、脱敏错误码、策略名称和必要的日志片段。不要安装来源不明的证书或配置文件，也不要为测试长期关闭系统安全保护。