常见代理连接失败问题排查指南

代理连不上时，同时换节点、改 DNS、重装客户端，会让原因更难辨认。本文是一条可以从头走完的排查线：先记录现象、按顺序缩小范围，再执行对应修复，用原来的应用确认恢复。各小节给出基本处理；涉及更细的分支时，可以继续阅读配套专项文章。

先保存当前配置、节点选择、本地端口和系统代理状态。备份可能包含凭据，应只保存在自己的设备上。排查一次只改一项；没有改善就恢复，再进入下一步。本文命令是诊断示例，不代表本站对具体服务商的实测。

排查前先确认的判断顺序

症状与原因速查表

症状	最可能的原因	对应小节
添加订阅后列表为空或提示解析失败	订阅格式不对、地址不完整、订阅域名无法访问	V2RayN 导入订阅失败
节点显示正常，浏览器打不开网页	系统代理未开启、模式为直连、规则分流到 DIRECT	Clash 显示已连接但无法上网
之前正常，现在更新订阅报错	订阅到期、地址变更、通过失效节点更新	订阅更新失败
浏览器能用，某些软件不走代理	软件不读取系统代理、扩展覆盖、UWP 回环限制	系统代理不生效
能用但很慢、视频卡顿	高峰拥塞、节点距离远、全局模式绕路	网络延迟过高
所有节点同时失败，TCPing 却正常	时间、认证、协议参数或共同出口异常	时间不同步导致握手失败
日志出现 no such host、lookup timeout	系统或内核 DNS、节点启动解析异常	DNS 解析失败
日志出现证书或握手相关报错	时间错误、SNI 不匹配、HTTPS 扫描拦截	TLS 与证书错误
客户端启动失败或提示端口占用	其他程序占用了本地端口	端口被占用

V2RayN 导入订阅失败

症状：在订阅分组设置中添加地址后执行更新，节点列表仍为空，或日志提示更新失败、解析失败；也可能导入了一堆名称乱码、无法使用的节点。

可能原因：

• 订阅地址复制不完整，或首尾带了空格、换行。
• 订阅格式或协议参数与当前客户端版本不匹配。
• 当前网络无法访问订阅域名，例如 DNS 解析异常或域名被干扰。
• 首次更新时选择了“通过代理更新”，而此时还没有可用代理。
• 订阅已到期或流量用尽，服务端返回空内容。

排查步骤：先看更新日志，分辨下载超时、HTTP 报错和解析失败。必要时只在自己的设备上检查返回内容：协议链接、编码列表、YAML、HTML 登录页和到期提示代表不同情况。看起来像 Base64 不等于内容有效；HTTP 200 也不等于返回了节点。v2rayN 官方列出的格式以协议标准或内部格式为准，应使用服务商为当前版本提供的入口。

解决与验证：重新复制匹配客户端的官方订阅入口；没有可用节点时先尝试“不通过代理”，已有可用节点时再对照代理下载。成功后确认节点没有意外清空、分组已启用，并用选定节点实际访问。完整导入过程见订阅导入指南，所有下载与解析分支见订阅更新失败专项排查。

Clash 显示已连接但无法上网

症状：客户端界面显示内核运行中，节点延迟测试正常，但浏览器打不开境外网站，或者所有网站都打不开。

可能原因：

• 只启动了内核，没有开启系统代理（或 TUN）。
• 运行模式被切换成了“直连”。
• 规则把目标网站分配给了 DIRECT，或“节点选择”组当前选中的是 DIRECT。
• 浏览器中的代理管理扩展覆盖了系统代理设置。
• TUN 模式与其他 VPN 软件同时运行，路由互相冲突。

排查步骤：先用命令行绕过浏览器，直接经本地端口访问测试地址，判断问题出在“代理本身”还是“系统代理与浏览器”：

# macOS / Linux：端口以客户端设置为准，7890 仅为常见默认值
curl -q --proxy http://127.0.0.1:7890 --noproxy localhost --connect-timeout 10 --max-time 20 --head https://example.com/

# Windows（PowerShell 中需写 curl.exe，避免调用别名）
curl.exe -q --proxy http://127.0.0.1:7890 --noproxy localhost --connect-timeout 10 --max-time 20 --head https://example.com/

有效 HTTPS 响应说明这一次显式请求完成；还要在连接列表中找到 example.com，核对命中规则和实际出站。它可能仍被分配到 DIRECT，因此成功响应本身不证明节点可用。显式请求经预期节点成功、浏览器却失败时，才把重点转到系统代理与浏览器。失败时根据连接被拒绝、解析、TLS 或超时错误分别继续。

只出现 HTTP/1.1 200 Connection established 不算目标访问成功：它是本地代理接受 CONNECT 隧道的回复，之后仍可能握手失败。继续看目标自己的 HTTP 响应和 curl 错误；目标返回 403、404 等状态时，连接已到达响应方，但还未满足“原任务正常完成”的验收条件。

解决与验证：开启系统代理，确认模式和目标规则，在策略组选择可用节点；临时停用个人浏览器代理扩展后重开浏览器。回到原目标并查看新连接是否使用正确出站。规则与模式见 Clash 基础教程，具体接管问题见系统代理专项排查。

订阅更新失败

症状：订阅以前可以正常更新，最近更新时报错或超时，节点列表停留在旧版本。

可能原因：

• 套餐到期、流量用尽，或你在面板中重置过订阅地址。
• 服务商更换了订阅域名，旧地址已经失效。
• 客户端设置为“通过代理更新”，而当前使用的节点恰好已失效，形成循环依赖。
• 本地 DNS 无法正确解析订阅域名。
• 短时间内频繁更新，被服务端限制。

排查步骤：先登录面板确认账户状态和最新订阅地址；然后切换“通过代理 / 不通过代理”两种更新方式各试一次；最后检查订阅域名的解析结果是否正常：

# 将 sub.example.com 替换为你的订阅域名
nslookup sub.example.com
# 只为本次查询指定 DNS，不修改系统；服务器在当前网络也可能不可达
nslookup sub.example.com 1.1.1.1

解决与验证：使用最新地址，并比较直连与代理下载。DNS 返回不同 IP 对 CDN 域名可能正常，不要求完全一致；先确认是否超时或返回错误，再调整相应解析路径。遇到频率限制按服务端提示等待。更新成功后启用新配置，选节点实际访问；保留旧配置直到验证完成。状态码、格式和安全恢复详见订阅更新失败。

系统代理不生效

症状：客户端运行正常，部分浏览器能访问，但另一些浏览器、命令行工具或应用依然直连；或者开启系统代理后设置很快又被改回。

可能原因：

• 客户端选择了“不改变系统代理”，或系统代理开关未开启。
• 该程序本身不读取系统代理设置（命令行工具、部分游戏和开发工具很常见）。
• 部分沙盒或 UWP 应用受本机回环限制，无法连接 127.0.0.1 上的代理端口。
• 另一个代理客户端或安全软件随后又改写了系统代理。
• 设备由公司统一管理，组策略锁定了代理设置。

排查步骤：查看系统当前实际生效的代理设置。

# Windows：当前用户常见的代理字段，只查询不修改
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v AutoConfigURL
# WinHTTP 代理是另一套独立设置，部分系统服务读取它
netsh winhttp show proxy

# macOS：查看系统代理整体状态
scutil --proxy
# 查看指定网络服务的 HTTP / HTTPS 代理（服务名以“网络”设置中显示的为准）
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"

在手动代理场景下，ProxyEnable 为 0x1 且 ProxyServer 指向正确端口，是设置已写入的线索；PAC、自动发现、管理策略及应用独立设置仍需单独检查。WinHTTP 是另一套 API 的配置，显示直连不等于浏览器没有代理。macOS 还要确认查询的是当前实际使用的网络服务。

解决与验证：只保留一个个人客户端修改系统代理；不读取系统设置的应用，在自身设置中指定匹配协议的端口。个别沙盒应用先确认是否为回环限制，再按官方说明处理。需要 TUN 时单独启用并检查路由与 DNS，不能保证所有应用协议都被支持。验证原应用的新连接与实际出站，随后确认关闭客户端后直连仍正常。完整步骤见系统代理不生效。

网络延迟过高

症状：可以访问，但网页加载慢、视频频繁缓冲，真连接延迟明显高于平时，或同一节点在不同时段差异很大。

可能原因：

• 晚高峰跨境链路拥塞，或节点用户过多（超售）。
• 选择的节点地理距离远。
• 使用了全局模式，国内网站也绕道境外。
• 本地 Wi-Fi 信号差、路由器负载高，问题出在“第一公里”。
• TUN 与其他 VPN 叠加，流量被多层转发。

排查步骤：先排除本地网络。关闭代理后对路由器做连续 ping，观察是否有丢包和明显抖动：

# Windows：ping -n 20 <地址>；macOS / Linux：ping -c 20 <地址>
# 192.168.1.1 为常见路由器地址示例，请替换为你自己的网关
ping -c 20 192.168.1.1

到网关的异常可以作为局域网线索，先改用有线对照；部分网关会限制 ICMP，不能只凭一次 ping 判断。普通 HTTP/SOCKS 代理不转发系统 ping，它也不能代表代理出口质量。本地正常时，同一目标、同一时段比较多个节点，再在不同时段重复，记录实际应用任务是否完成。

解决与验证：检查目标是否意外绕路，选择对该目标实际表现更好的节点；地理距离和节点名称只能提供线索。用原视频、网页或通话任务复测，并在原故障时段确认。完整对照步骤见延迟与丢包排查，记录方法见线路性能测试，线路原理见 IEPL 线路是什么。

时间不同步导致握手失败

症状：多个节点的实际连接同时失败，日志可能提示时间、认证或有效期错误。TCPing 正常仅说明相应 TCP 端口可连接，不能排除认证、协议参数及出口故障。

可能原因：部分代理协议在认证时会校验时间。以 VMess 为例，Xray 文档要求设备的 UTC 时间误差在 120 秒以内，与时区无关。时区设置错误但“显示时间看起来正确”时，实际 UTC 时间可能已经偏差数小时。

排查与解决：

# Windows：在管理员终端查看时间同步状态
w32tm /query /status
# 立即同步（需在管理员身份的终端中运行）
w32tm /resync

macOS 可在“系统设置 → 通用 → 日期与时间”检查自动时间与时区；Linux 按发行版的时间服务处理。核对年份、日期和实际 UTC 时间，而不只是时钟显示。组织管理设备的时间源交由管理员确认。

验证：同步后重新发起原请求。时间准确但仍失败时，继续核对最新订阅、认证和协议参数，不要反复修改时间；证书确实过期时，应由服务端续签，不能把本机时间调回过去。

DNS 解析失败

症状：日志出现 no such host、Could not resolve host 或 lookup ... timeout，也可能只在开启 TUN 后出现。先识别失败的是订阅域名、节点域名、目标域名还是 DNS 服务器本身。

排查与解决：用上文的 nslookup 方法比较默认查询与指定服务器查询，同时看客户端的解析日志。系统查询成功不代表内核和浏览器使用相同 DNS；节点的启动解析也不能依赖尚未连接成功的节点。Fake-IP 模式出现映射地址并不自动代表污染，应核对 DNS 与后续流量是否进入同一内核。

验证：原域名查询、原应用实际访问及正确出站三者都恢复，再确认内网与局域网没有受影响。修改前记录原值，不要直接清空 DNS 或复制整套陌生配置。完整分支见 DNS 解析失败专项排查，原理见 DNS 与代理分流。

TLS 与证书错误

症状：日志中出现 certificate、x509、handshake 等与证书或握手相关的报错；或开启代理后浏览器提示证书不受信任。

可能原因：

• 系统时间错误，证书被判断为“尚未生效”或“已过期”。
• 节点配置中的 SNI（服务器名称）与服务端证书不一致。
• 公司网络或安全软件开启了 HTTPS 扫描，在中间替换了证书。
• 客户端或内核版本过旧，不支持节点使用的新协议参数。

排查与解决：先分清客户端到节点的握手与浏览器到目标网站的 HTTPS，再按明确错误检查时间、名称、有效期和信任链。更新官方订阅并核对参数；在自己的另一网络做同目标对照。受组织管理的 HTTPS 检查由管理员确认，个人安全软件的临时对照测试后恢复设置。从官方渠道更新兼容客户端与内核。

验证：保持证书校验开启，原节点与原目标均不再出现错误，浏览器也无告警。通用 handshake failed 不一定是证书问题，需保留更早的日志。完整方法见 TLS 与证书错误排查。

端口被占用

症状：客户端启动时报错，提示端口已被使用；或客户端看似正常，系统代理却连不上。

可能原因：另一个代理客户端仍在后台运行（包括托盘中未完全退出的进程），或者其他软件恰好使用了相同端口。

排查步骤：

# Windows：查找占用 7890 端口的进程 PID（端口替换为你的设置）
netstat -ano | findstr :7890
# 根据 PID 查看进程名称（12345 替换为上一步查到的 PID）
tasklist /FI "PID eq 12345"
# PowerShell 写法
Get-NetTCPConnection -LocalPort 7890 -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess

# macOS：查看监听 7890 端口的进程
lsof -nP -iTCP:7890 -sTCP:LISTEN

解决方法：从托盘彻底退出冲突的客户端，必要时在任务管理器或活动监视器中结束残留进程；如果必须同时运行两个程序，就在其中一个的设置里修改本地端口，并同步修改依赖该端口的浏览器扩展或命令行配置。

先确认进程身份，保存其必要工作，不要仅凭 PID 强制结束未知系统服务。修复后重新查询监听进程，确认端口归属当前客户端，再完成一次显式请求与应用访问；仅消除启动提示还不算验证完成。

仍然无法解决时如何求助

先恢复没有改善的临时 DNS、模式、浏览器和安全软件改动，保留有效修复及其原因。确认原应用、原目标和预期出站已经恢复，再重启客户端复测；关闭接管后也应能正常直连。

仍未解决时，向服务商或社区提供以下信息：

• 操作系统及版本、客户端名称及版本、内核版本；
• 出现问题的时间和时区，是否所有节点、所有目标、所有应用都受影响；
• 直连、显式代理、另一节点和另一接入网络的对照结果；
• 已经按本文尝试过的步骤和结果；
• 第一条相关错误及上下文（删除完整订阅地址、密码、UUID、认证头与内部地址后再发送）。

请在遵守当地法律法规和服务条款的前提下使用代理工具。如果你是刚开始配置客户端，建议先回到 V2RayN 安装与使用教程 或 Clash 基础教程 确认基础设置。