问题诊断 / 按症状查阅

V2Ray 故障排查手册

连接、订阅、DNS 与代理设置：先定位故障所在环节，再修改对应参数。

本页是系统查阅手册，不要求从头读完。首次安装与导入请先走入门指南的操作主线；已经完成配置但结果不符合预期时，按下方症状进入对应章节。桌面端以 v2rayN 为主，安卓端分别说明 v2rayNG 与 v2flyNG。不同界面的菜单名称可能略有差异，应以功能含义和实际监听值为准。

诊断记录 · 每次只改变一个条件

建议记录：发生时间、网络类型、当前客户端、启用的代理模式、目标应用，以及同一时刻的错误日志。保留修改前的设置截图，再做一次可重复的请求。

日志只截取故障前后的相关行。分享前删除订阅地址、服务器地址、用户标识、密码和连接链接；不要公开完整配置文件。

无法上网：先分清本地入口与远端连接

“已启动”只说明客户端尝试运行，并不表示浏览器流量已经进入代理，也不表示远端服务器完成了连接。先把现象说清楚：是所有应用都失败，还是只有一个浏览器；是全部网站打不开，还是某一类目标失败；关闭代理后能否恢复普通连接。这个分类能把问题分成基础网络、本地监听、应用接入和远端出站四段，避免一开始就更换所有节点。

建立不经过代理的对照

在 v2rayN 中先清除系统代理，并确认 TUN 已关闭，再用浏览器访问平时能够直连的站点。如果此时仍失败，检查无线网络是否需要登录认证、系统时间是否正确，以及网络适配器是否取得地址。公共网络的认证页面通常需要先直连打开；在认证完成前测试节点，只会得到一组没有区分度的超时结果。不要把基础网络故障当作订阅故障处理。

直连正常后，恢复一个已知配置，暂时只保留一种接入方式。桌面端可以先使用系统代理，先不启用 TUN，也不同时运行其他代理程序。到“参数设置”检查本地监听端口，再从运行日志确认内核已经启动。若界面显示端口与日志不同，以本次成功启动的实际监听信息为准；端口不是固定常量，修改后还要同步修改手动设置代理的应用。

用显式代理请求隔开两段链路

下面的 Windows 命令明确指定 HTTP 代理入口，适合检查“应用是否没有接入系统代理”这一分支。示例假定当前 HTTP 或混合监听端口确实为 10808；如果你的设置不同，先替换端口。它不适用于只提供 SOCKS 的入口。测试目标也要选择当前网络中允许访问、且能够稳定响应的 HTTPS 站点。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

如果提示无法连接到本地代理，先处理内核未启动、端口填写错误或端口占用。若已经连接本地代理，随后才出现远端连接或 TLS 错误，则继续看下一章。显式代理请求成功、浏览器失败时，优先检查浏览器独立代理、扩展和应用缓存，不必马上改服务器配置。这个对照比仅观察托盘图标更可靠，因为它实际穿过了本地入口。

检查路由是否把请求送错出口

进入“路由设置”，确认当前选择的规则集与预期一致。某个目标被规则送往直连时，即使服务器健康，也可能出现与代理完全相同的失败表象。临时使用一个规则较少的测试方案，只为确认目标能否通过代理访问，验证后恢复原来的分流。不要长期用扩大代理范围来掩盖规则错误，否则后续很难分辨究竟是哪条规则起了作用。

若只有特定应用失败，核对该应用使用的是 HTTP、SOCKS 还是自身的连接方式。系统代理通常不会自动覆盖所有程序，也不保证接管所有 UDP 流量。先查看应用是否支持显式填写代理，再决定是否需要 TUN。若只在开启 TUN 后失败，记录虚拟网卡、权限和路由变化，按TUN 模式说明重新核对，而不是同时修改 DNS 与节点。

最后把结果写成一句可复现描述，例如“直连正常，显式 HTTP 代理成功，浏览器失败”。这句话已经把排查范围缩到应用接入层。若“直连正常，本地端口可连接，所有远端请求失败”，才进入节点和传输参数检查。完成恢复后保存有效配置，删除临时测试规则，避免下次启动又切回有问题的方案。

节点超时：区分端口、握手与目标站失败

超时表示在限定时间内没有得到预期响应，但没有说明卡在哪一层。连接服务器端口、建立加密传输、通过身份验证、由服务器连接目标站，都可能各自超时。先在运行日志中找到本次请求的第一条相关错误，而不是只读最后一行“失败”。记录错误发生前是否已经建立连接，以及失败是否只跟某个目标或某种网络有关。

先确认服务器入口能够到达

打开当前服务器的编辑窗口，对照提供方给出的地址与端口。复制地址时要排除前后空格，不要把完整网页地址填进服务器地址栏，也不要把订阅地址当成节点地址。域名和地址栏中的端口应分别填写。若订阅内容近期变更，先更新对应分组，再重新选择有效条目；手工修改旧条目并不一定会在下一次订阅更新后保留。

在 Windows 中可用下面的命令检查服务器的 TCP 入口。这里的示例域名只用于展示命令语法，运行时换成当前节点的真实地址和端口，且不要把替换后的命令公开分享。测试失败说明本机到该 TCP 入口没有建立连接；测试成功则仅说明端口可连接，不能证明协议、用户标识或传输参数正确。对于采用其他传输方式的配置，也不能把这项测试当作完整验证。

Test-NetConnection -ComputerName server.example.com -Port 443

如果多个节点都只在同一个网络失败，可以切换到另一个可信网络复测同一条配置。不要同时换网络与节点，否则无法判断变量。若某一个服务器在所有网络都失败，而其他服务器正常，应向配置提供方确认入口状态。反复缩短测试间隔不会让超时更有信息量，反而可能触发连接限制，适当间隔后再测一次即可。

端口通了，再核对传输与安全参数

TCP 入口正常但日志出现握手错误时，逐项比对协议、传输类型、TLS 设置和服务器名称。WebSocket 的路径与 Host、gRPC 的服务名称、REALITY 的公钥与短标识，都需要与服务端保持对应；不能因为端口相同就认为参数可以互换。路径大小写和前导斜杠也可能影响匹配，优先重新导入完整连接信息，而不是靠猜测补齐字段。

设备时间偏差也会影响证书有效期判断或部分认证流程。先开启系统自动校时，再检查日志中的证书名称、有效期和信任链提示。不要用“跳过证书验证”作为日常修复方式：它会绕开本来应该发现的问题，并不能修复服务器名称配置错误。若服务器证书本身异常，应由服务维护方修复，客户端只负责填入正确的连接参数。

读懂不同错误的排查方向

日志线索	常见含义	优先检查
`connection refused`	连接被主动拒绝	目的端口、监听服务、防火墙拒绝规则
`i/o timeout`	某段读写等待超时	错误关联的地址、发生阶段、当前网络
`certificate`	证书相关校验失败	系统时间、服务器名称、证书链
`EOF`	对端提前结束连接	传输类型、身份验证、服务端日志

这些关键词不是一对一的诊断结论。例如读写超时可能发生在目标站一侧，提前结束连接也可能来自中间网络设备。必须结合前后日志和对照测试。若服务器连接建立后只有单个网站失败，检查该网站的路由与服务器侧访问条件；不要仅凭一次目标站异常就认定整个节点失效。

客户端列表中的延迟测试还可能使用不同目标和不同连接方法。端口测试成功而真连接测试失败，通常说明需要继续检查协议后的链路。具体差异见节点延迟与下载测速说明。向维护方反馈时提供时间、协议类别、错误阶段与已做的网络对照，不要发送完整凭据，这样更容易得到可执行的答复。

订阅失败：分别检查请求、解析与分组显示

订阅更新包含三个独立步骤：客户端下载地址内容，把返回内容解析成服务器条目，再写入某个订阅分组。界面显示“失败”时，先确定失败属于哪一步。请求失败往往与网络、地址或证书有关；解析失败往往是返回了网页或不兼容格式；更新成功却看不到条目，则可能只是选错了分组。直接重复点击更新通常不会改变这些条件。

核对地址与更新所走的网络

在 v2rayN 中进入“订阅分组设置”，编辑目标分组，检查地址是否完整保存。订阅链接可能包含访问凭据，应从可信来源完整复制，不要手工拼接，也不要在公开截图中展示。聊天软件换行、复制到末尾的中文标点、已经过期的访问参数，都可能让客户端请求一个看似相近但实际不同的地址。先保存，再执行该分组的更新。

区分“通过代理更新”和“不通过代理更新”的入口，或查看当前界面提供的等效设置。如果现有节点已经失效，而订阅更新又被指定必须经过这些节点，就会形成无法自行恢复的循环。此时先测试订阅地址能否直连获取；若提供方要求使用可用代理访问，则需要保留一个已知有效的连接作为更新通道，不应通过清空列表来解决。

浏览器能打开订阅地址，也不能直接证明客户端一定能读取。浏览器可能使用另一个代理、保留登录状态，或经过了网页验证。检查客户端日志中的响应状态：未授权或禁止访问通常需要重新确认账户与链接权限，找不到资源要核对地址，服务端错误则应稍后重试并联系提供方。不要把这些响应都归因于客户端内核。

请求成功后，判断内容能否被识别

成功的网络响应可能仍然是一张登录页、提示页或网络认证页面，而不是节点数据。若日志提示无有效服务器、解析失败或格式不支持，先向订阅提供方确认该地址面向哪类图形客户端。网页订阅说明与真正的订阅内容入口不是同一个概念；同样，某些专用配置格式也不能直接作为通用连接列表导入。

不建议把完整订阅粘贴到在线转换页面排错，因为其中可能包含全部访问凭据。先在本地确认返回内容的类型，必要时只向维护方描述“返回网页”或“无法识别的配置格式”。如果手中同时有单条连接链接，可先通过客户端的剪贴板导入功能测试一条；单条可用而订阅失败，说明应聚焦订阅获取与格式，不必重新排查所有网络设置。

更新成功但列表为空或出现重复条目

回到服务器列表检查当前订阅分组、搜索框和筛选条件。更新另一个分组，并不会让当前视图自动显示它的全部内容；有时旧的关键字筛选仍在生效。确认分组中保存的是本次编辑的地址，而不是名称相近的另一个条目。若同一地址重复建立了多个分组，应先对照确认再删除重复组，避免误删唯一的有效来源。

当订阅更新后服务器名称或排序变化，原来选中的条目可能已经被替换。重新选择有效条目，再执行连接验证。手工改过的服务器参数也可能被订阅覆盖，因此个性化调整应放到独立分组并注明来源。对自动更新导致的问题，保留更新前后的时间和条目变化，比单纯说“更新后不能用”更有排查价值。

若只有自动更新失败，手动更新正常，检查电脑休眠、启动顺序和更新时的网络状态。客户端启动瞬间可能还没有可用网络，也可能在代理内核就绪前发起请求。先用手动更新确认链路，再调整更新安排，避免把定时条件问题误当作格式问题。安卓端还要考虑后台限制，相关流程见本页末章。

首次配置可按订阅导入步骤重新核对操作顺序；概念性疑问可查FAQ。反馈订阅问题时只提供状态码、错误类型和分组操作过程，隐藏完整地址与访问参数。修复后验证一次更新、一次选中服务器和一次实际请求，三项都正常才算闭环。

速度慢：把延迟、吞吐与应用等待分开

“慢”至少包含三种体验：点击后很久才开始加载、传输开始后持续速度低、播放或会议周期性中断。第一种常与解析和连接建立有关，第二种更接近可用带宽与拥塞，第三种可能涉及抖动、丢包或应用流量没有正确接管。先记录是哪一种，再选择测试方式；仅按列表里的一个延迟数字排序，很容易选到不适合当前任务的服务器。

让两次测试具备可比性

使用同一台设备、同一个目标和同一种代理模式，暂时关闭其他大流量任务。先测试一个节点，再只切换节点复测，避免同时更换路由和 DNS。大文件下载会消耗实际流量，也可能影响其他用户，不必为了比较重复运行很久。观察连接建立时间和稳定传输阶段即可；浏览器缓存命中时的瞬间完成，不代表远端链路真的更快。

先检查本地无线网络质量和设备负载。远离接入点、无线频段拥挤、系统正在同步文件，都可能降低所有连接的速度。用同网络下可直连的服务做参照，如果直连也明显变慢，应先处理基础网络。条件允许时使用有线连接做一次对照；这不是长期使用要求，而是为了排除无线链路这一层变量。

延迟低不等于大流量传输快

端口连通测试主要反映建立连接的等待时间，真连接测试还会受到代理握手和测试目标影响，下载测速则更容易暴露带宽与拥塞。三者不是同一项指标，也不应期望数值完全一致。远端线路可能往返时间较长但吞吐稳定，也可能连接很快却在高峰期拥塞。选会议或交互应用时关注稳定性，选持续下载时还要看传输阶段的表现。

如果同一个节点只对某个站点慢，检查目标站本身、内容分发路径与命中的路由。服务器所在网络到目标站的路径，和本机到服务器的路径并不是一回事。可以用另一个稳定目标复测，或切换另一个节点访问相同目标；不要仅凭一个网站的响应就把所有配置都重置。有关测试含义，参见TCPing、真连接与下载测速的差别。

检查接入方式、分流与资源占用

进入运行日志确认慢请求走的是预期出站。某条宽泛规则可能把目标送到了不合适的路径，也可能只有网页走代理，下载组件却使用独立连接。特别是应用内的更新器、媒体组件和命令行工具，未必遵循同一套系统代理设置。先给应用显式配置受支持的代理；确有接管需求时再测试 TUN，不要把扩大接管范围当作通用加速措施。

桌面端同时开启多层代理、虚拟网络和安全软件扫描时，可能引入额外处理。逐一关闭重复组件作短时对照，但不要直接关闭所有系统防护。观察客户端和内核的 CPU、内存占用；如果请求期间处理器持续繁忙，应检查是否出现大量重复连接或日志写入。调试结束后恢复普通日志级别，避免长时间记录详细连接造成磁盘和隐私负担。

只有在特定网络中出现“大请求卡住、小请求正常”时，才进一步考虑路径 MTU 或分片问题。先比较系统代理与 TUN 的表现，确认现象可重复，再依据客户端支持的设置做小范围调整。随意填写很小的 MTU 会降低效率，也可能掩盖其他故障。不要照抄一个号称通用的参数；修改前记录原值，测试无改善就恢复。

最后检查是否把 DNS 等待误认为速度低。如果首次访问很慢、后续请求明显正常，重点记录解析和连接建立阶段；如果整个下载过程都低速，再关注拥塞和链路稳定性。保留同条件下的对照结论，不必公开具体服务器信息。恢复后将临时改动逐一撤回，仅保留能够复测证明有效的设置，避免积累无法解释的“优化参数”。

DNS 问题：确认由谁解析、查询走哪条路

DNS 故障常表现为域名打不开、首次加载等待很久，或者同一个目标在不同应用中结果不一致。不要只看到浏览器的解析提示就立即更换所有 DNS 地址。一次访问可能经过操作系统缓存、浏览器安全 DNS、代理内核解析和远端服务器解析；先弄清当前请求究竟在哪一层解析，再判断该修改哪一处。否则新设置可能根本没有被该应用使用。

系统解析结果不是完整代理结果

先查看日志里报错的域名是什么：它可能是目标网站，也可能是服务器地址，还可能是 DNS 服务自身的域名。服务器使用域名时，内核在连接代理之前就需要解析它；这一步失败会让全部代理请求受影响。目标域名解析失败则可能只影响一部分站点，两者处理顺序不同。记录错误中的角色，不必把真实地址公开出来。

Windows 可使用下面的命令观察系统当前解析结果。它适合核对系统 DNS 是否能回答，以及回答是否来自预期的服务器，但不能证明浏览器或代理内核采用了相同结果。成功得到地址后仍连接失败，问题也可能位于路由、目标端口或传输握手，不应继续把所有错误归结为 DNS。

Resolve-DnsName example.com

需要测试远端解析时，可以使用 SOCKS 的域名转交方式，让代理链路接收域名而不是本地先解析的地址。下面假定当前 SOCKS 或混合入口为 10808。若入口只支持 HTTP，应改用适合该入口的测试方法，不能把协议不匹配得到的错误解释为解析失败。

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

加密 DNS 也需要先有可用路径

使用基于 HTTPS 的 DNS 时，DNS 服务本身也需要连接，且其域名可能需要引导解析。如果把解析服务的连接强制送入一个尚未成功建立的代理，就可能出现循环依赖：代理等服务器解析，解析又等代理连接。先确保服务器地址的基础解析和 DNS 服务的可达路径成立，再增加分流策略；不要一次叠加多个互相依赖的解析入口。

在 v2rayN 中检查当前内核对应的 DNS 设置，并区分普通代理与 TUN 场景。不同内核的配置字段不一定兼容，不能把一份配置里的 DNS 段直接粘进另一种内核。优先使用界面提供的配置入口，确认保存后内核已重新加载。若修改的是某个未被选中的配置文件，界面上看似已经改动，实际运行的仍是旧方案。

把解析与路由匹配一起检查

域名规则依赖请求中保留的域名信息，IP 规则则依赖目标地址和数据文件。浏览器先解析、应用仅提交 IP、流量探测未获得域名等情况，都可能让域名规则无法匹配。Sniffing 能为部分连接补充可识别的目标信息，但不保证覆盖所有协议，也不是 DNS 的替代品。先观察请求携带的信息，再检查命中规则，避免把“没拿到域名”误写成规则语法错误。

下面是 Xray 风格的路由规则片段，用于说明域名与 IP 条件的写法，不是完整客户端配置。它依赖可用的 geosite、geoip 数据以及已定义的 direct 出站。两个条件分别放在两条规则里，更容易观察匹配过程。不要将片段覆盖到整份配置文件；在图形界面中应使用路由编辑功能建立对应规则。

{
  "rules": [
    {
      "type": "field",
      "domain": ["geosite:cn"],
      "outboundTag": "direct"
    },
    {
      "type": "field",
      "ip": ["geoip:private"],
      "outboundTag": "direct"
    }
  ]
}

数据文件缺失、标签拼写错误和规则顺序不合适，都可能造成预期外的出站。更完整的规则顺序可查geosite 与 geoip 分流说明。排错时只临时调整与目标相关的规则，不要为一个解析问题删除整套分流；保留一份原始配置，便于验证后恢复。

修改后关闭浏览器旧标签页或重启相关应用，必要时再清理系统 DNS 缓存。清缓存只是让新请求重新查询，不会修复错误的服务器地址和循环依赖。若只在浏览器异常，检查它的安全 DNS 是否绕过系统设置；若只在 TUN 异常，检查虚拟网络下的 DNS 路由。最后同时验证普通域名和当前服务器域名，确认基础连接与目标访问都已恢复。

系统代理不生效：检查应用是否进入本地入口

系统代理是一组供应用读取的网络设置，不等同于系统中所有流量都被强制接管。v2rayN 已设置系统代理，但某个应用仍然直连，可能是应用不读取系统设置，也可能是独立代理、环境变量或其他软件覆盖了入口。先用显式代理请求验证内核，再判断系统设置是否写入，最后检查目标应用。按这个方向排查，可以避免把接入问题误判成节点失效。

对应实际端口与监听地址

在“参数设置”中查看本地监听地址、HTTP 或混合端口，并确认运行日志没有启动失败。系统代理指向的地址应与这个入口一致。单机使用通常指向回环地址；“允许来自局域网的连接”影响其他设备访问本机入口，不是修复本机代理的必要开关。不要为了让浏览器工作就扩大监听范围，特别是在公共网络中。

如果改过端口，先清除旧系统代理，再重新应用当前配置，随后关闭并重开目标应用。部分程序只在启动时读取代理设置，旧连接也可能继续复用原路径。使用任务管理器确认程序确实退出，而不是仅关闭窗口。若显式指定新端口可以访问，系统代理模式仍失败，优先检查残留设置和应用自身策略，不必再次修改服务器。

按平台检查实际生效的位置

平台	检查位置	容易遗漏的边界
Windows	设置 → 网络和 Internet → 代理	应用可能采用独立设置或另一套网络接口
macOS	系统设置 → 网络 → 当前网络服务 → 详细信息 → 代理	设置与当前使用的网络服务有关
Linux	当前桌面环境的网络代理设置	桌面设置与终端环境变量可能彼此独立

Windows 的用户代理设置与部分系统服务采用的网络设置可能不同。因此浏览器成功、后台服务失败，并不必然是客户端有故障。不要为了某个服务贸然修改全局网络配置；先查该应用是否提供自己的代理入口。macOS 切换网络服务后，应重新检查正在使用的服务，而不是只看之前连接的那一项。

Linux 下，图形应用、桌面会话和终端进程可能分别读取不同配置。终端环境中的 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 也可能保留旧地址，大小写变量的处理还依赖程序实现。先用显式代理参数测试，再检查当前进程继承的环境；清理后重新启动终端。不要把所有变量同时指向不同协议的端口，否则后续更难判断实际使用了哪一项。

排除覆盖设置与代理回路

浏览器代理扩展、另一套代理客户端和网络管理工具可能反复写入系统代理。关闭重复工具后观察地址是否仍自动变化。只保留一个负责系统代理的程序，避免两个进程互相覆盖。若客户端退出后网络仍异常，先确认内核是否还在后台运行，再使用“清除系统代理”；若程序已无法启动，可到系统设置中手动移除指向失效本地端口的配置。

代理回路则是另一类问题：应用请求进入代理后，内核自己的出站又被重新送回入口，最终出现重复连接或资源持续升高。启用 TUN 与额外系统级代理组件时尤其需要注意排除路径。先退回仅系统代理的最小配置，确认正常后再逐项恢复接管功能。不要通过不断换端口掩盖回路，因为循环的路由关系并没有改变。

当一个应用明确采用自带网络栈时，按它的说明填写 HTTP 或 SOCKS 入口，注意 SOCKS 与 HTTP 地址格式不能互换。有些实时通信功能还会使用 UDP，网页能开不代表语音连接也被覆盖。复测时同时观察应用表现和客户端日志中是否出现对应请求；日志没有请求是重要线索，说明应先查接入，而非服务端。

恢复后记录“哪个设置负责哪个应用”，并将不用的旧配置清理掉。首次选择模式可回到入门指南；与分流相关的判断见路由设置步骤。保留一个显式代理测试命令作为基线，下次系统更新或切换网络后，可以快速判断问题发生在应用层还是连接层。

客户端崩溃：分开处理界面退出与内核失败

“打不开”需要先区分两个进程层次：图形界面本身无法运行，还是界面可以打开但代理内核启动后立即退出。前者更接近程序文件、运行环境、用户数据或权限问题；后者通常能从内核错误日志找到配置、端口或文件路径线索。不要一看到启动失败就删除整个用户目录，订阅、路由和本地设置可能都在其中，先备份再隔离故障。

保留现场与确定启动失败范围

先记录双击后的具体表现：完全没有窗口、窗口出现后关闭、停在后台，还是主界面提示内核运行失败。检查任务管理器或系统活动监视器，确认是否已经存在另一个实例。若旧进程仍占用文件和端口，重复启动可能产生新的错误。正常退出旧进程后再试；不要在不确认进程用途的情况下结束名称相似的系统服务。

若界面无法打开，查看程序自己的日志目录或系统应用错误记录，优先寻找文件无法读取、依赖缺失和权限拒绝。程序放在受限制目录、从压缩包临时位置启动或文件没有完整解压，都可能影响运行。按下载中心选择对应平台与处理器架构的包，完成正常安装或解压流程，再从固定目录启动，不要混用不同发行形式的程序文件。

内核启动失败时先读第一条错误

界面正常而内核退出时，打开运行日志，从启动时刻向后看第一条有明确字段或地址的错误。后续“进程结束”“连接失败”通常只是结果。端口占用要定位具体监听地址与端口，配置错误要定位字段层级，数据文件错误要定位路径。详细方法可查Xray 内核启动失败排查，避免只凭最后一句提示反复重装。

Windows 可用下列命令检查示例端口的占用情况。把端口换成日志实际提示的值，再根据返回的进程编号在任务管理器核对程序。发现占用时优先关闭重复客户端，或给当前客户端选择一个未占用端口，并同步系统代理与手动配置的应用。不要随意终止未知进程，更不要把更改端口后出现的应用连接失败当作新的服务器故障。

Get-NetTCPConnection -LocalPort 10808 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, State, OwningProcess

手工编辑 JSON 后无法启动，要检查多余逗号、缺失引号、括号层级和字段类型。语法正确也不代表配置可用：字段可能不属于当前内核，出站标签可能未定义，规则引用的数据也可能缺失。尽量从图形界面修改，并使用客户端支持的检查入口；不要把网上一段独立配置片段直接替换完整配置，尤其不要混用不同内核的结构。

用独立数据目录隔离用户配置

如果程序本体可以运行，但原用户数据一载入就崩溃，可在备份后使用客户端支持的独立目录或配置隔离方式建立干净测试环境。原目录先改名保留，不要直接删除。若干净环境正常，再分批恢复订阅、服务器和路由，每恢复一类就启动验证一次。这样可以定位损坏数据或不兼容设置，而不是把旧问题整包复制回来。

更新后出现故障时，先核对新旧程序是否混放在同一路径，以及系统实际启动的快捷方式指向哪里。桌面版与 WPF 版的界面和运行依赖不同，不应靠互相替换可执行文件来切换。处理器架构也要与设备一致。只有日志明确指向运行环境缺失时，才按对应发行说明补齐依赖，不要安装一组来源不明的所谓修复组件。

安全软件若隔离了某个程序文件，应先确认文件来源与检测记录，并使用系统允许的恢复和例外机制处理，不要直接关闭所有防护。向支持人员反馈时，提供系统平台、处理器架构、所选发行形式及第一条错误，不上传完整用户目录。更多关键词解释见运行日志解读。最终同时验证界面启动、内核运行和实际代理请求，避免只修复窗口而遗漏连接层。

安卓专项：VPN 权限、分应用与后台保活

安卓端优先使用 v2rayNG，使用 V2Fly 内核配置时可选择 v2flyNG。两者的界面与内核选项并不完全相同，排错时要先确认正在运行哪一款，而不是照另一款客户端的菜单逐字寻找。下载入口见Android 客户端下载。开始前保留订阅信息，并记录问题是在连接按钮按下后立即发生，还是锁屏、切换网络或运行某个应用后出现。

确认 VPN 授权与实际接管状态

首次启动连接时，系统通常会弹出 VPN 连接授权。只有同意授权并成功建立本地 VPN 接口后，客户端才能接管相关应用流量。状态栏图标只说明接口存在，不说明远端服务器可用；连接后仍要打开一个目标做实际验证。若授权窗口没有出现或一闪而过，先到系统的 VPN 设置中检查已有配置和管理策略。

同一用户环境中通常不能让多个基于 VPN 接口的网络工具同时工作。其他 VPN、局域网工具或使用本地 VPN 的过滤程序，可能替换当前连接。先全部断开，只启动一个客户端复测。若系统设置了始终开启某个 VPN，或启用了阻止未经过 VPN 的连接，还要核对它指向的应用是否正是当前使用的客户端；错误组合可能让断线后的所有访问都被系统阻止。

检查分应用规则是否与预期相反

打开客户端的分应用或应用代理设置，确认当前列表表达的是“仅代理选中应用”还是“绕过选中应用”。两种含义相反，不能只看勾选数量判断。浏览器正常而另一个应用失败时，先查看该应用是否在实际接管范围内。刚安装的应用可能还没有加入列表，修改后应断开并重新连接，让系统 VPN 路由和应用范围重新生效。

客户端的本地监听入口与系统 VPN 模式也应分开理解。仅开启本地代理服务，并不一定能让普通安卓应用自动使用它；反过来，VPN 接管正常时也没有必要给每个应用再填写一个本地代理。若同时启用无线网络的手动代理设置，可能引入重复路径。先退回客户端默认的 VPN 使用方式，取消多余的手工代理，再验证节点本身。

锁屏断线与切网失败的处理顺序

如果前台连接正常，锁屏一段时间后失效，先检查系统电池管理对客户端的限制。按设备提供的设置允许必要的后台运行，关闭针对该应用的过度省电限制，并保留连接通知。不同设备的菜单名称不同，应按应用信息中的电池、后台活动和网络权限查找。不要一开始就给所有应用放开后台限制，只调整负责连接的客户端。

无线网络与移动网络切换后，旧连接可能仍引用原网络状态。先断开再重连，观察是否恢复；如果每次切网都能复现，再记录前后网络类型和日志。公共无线网络还可能需要先完成网页认证。省流量模式、漫游限制或只允许某类网络的应用权限，也会造成“在家正常、出门失败”的表象，应与服务器故障分开检查。

只有某个网络出现域名异常时，核对系统的私人 DNS 设置以及客户端内部 DNS 设置。两者不一定由同一条链路承载，不能假定关闭其中一个就会自动启用另一个。先记录原设置，临时退回系统自动选择做对照，再参考本页 DNS 章节检查服务器域名和目标域名。不要在无法解释结果时连续添加多个 DNS 地址，这会让失败路径更难复现。

区分网页、实时通信与订阅后台问题

网页可打开而语音、游戏或其他实时功能失败，可能与 UDP、分应用范围或服务端支持有关。先确认该应用流量被接管，再核对节点协议与提供方的能力说明，不能仅凭网页成功就推断所有传输都可用。若只在一个应用异常，尝试其自带的网络诊断；不要为了单个功能把所有路由与 DNS 同时重置。

订阅在前台手动更新成功、后台自动更新失败时，优先检查后台网络限制和更新时机，不要立即删除订阅。安装时若提示包不适用，核对设备架构并按下载页选择 arm64 或通用版，不把安装兼容性误认为连接问题。更换客户端前先确认原配置的协议与目标内核相容，三款客户端的定位对照见横向评测。

若仍无法定位，整理“何时正常、何时失败、重连是否恢复”的三项对照，再附上隐藏敏感内容后的错误日志。常见概念可以回查名词解释，基础操作可返回入门指南。清晰的复现条件比连续重装更有帮助，也能让下一次相同故障直接从已验证的分支开始排查。