V2Ray 故障排查大全

01 / 先确认影响范围

无法上网：从本地连接开始

“连接成功”通常只表示客户端已经启动处理流量，不代表目标网站一定可达。浏览器打不开页面时，先记下发生时间、正在使用的节点、代理模式和受影响的应用，再判断是所有连接中断，还是只有某个网站失败。保留这些条件，后续测试才有可比性；如果边换节点边换网络，暂时恢复也难以知道是哪一步起了作用。

先把基础网络与代理链路分开

先在客户端中清除系统代理，并暂时停止已启用的 TUN 模式，再访问平时可以直接打开的网站。如果仍然失败，检查无线网络是否需要网页认证、网线是否连接、系统日期是否准确，以及其他设备能否使用同一网络。此时不宜继续修改订阅或路由，因为代理之前的基础连接已经异常，应先恢复网络，再重新启动客户端。

基础网络正常后，打开 v2rayN，选中需要测试的配置并设为活动服务器，查看底部日志或日志窗口。重点不是寻找一条看起来醒目的报错，而是确认启动后有没有立即出现配置解析失败、监听地址占用或内核退出。界面能够打开不等于内核已经运行；若内核没有成功监听，浏览器把请求交给本地端口后仍然无法继续。

在“设置 → 参数设置”中核对本地监听端口；部分界面把相关项目放在“Core 基础设置”中，名称会随界面实现有所变化。记下实际值，不要仅凭教程示例填写。本文使用的 10808 只是示例，若客户端设置不同，测试命令也应同步替换。系统代理端口、浏览器手动代理端口和客户端监听端口必须对应。

用一次显式代理测试缩小范围

下面的 Windows 命令会先检查回环地址是否有程序监听，再让一次请求显式经过 SOCKS 代理。第二条只适用于该端口确实提供 SOCKS 服务的情况；混合端口也需确认包含该协议。测试地址使用示例域名，实际复测应选用已知可访问的 HTTPS 地址。不要因为示例网站本身暂时不可达，就直接认定客户端故障。

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://example.com/

若端口测试失败，回到内核启动和端口占用检查；若端口成功而请求失败，查看同一时刻的内核日志，继续检查节点连接与域名解析。若显式代理请求成功，但浏览器仍失败，说明至少这条代理链路能够工作，下一步应检查浏览器扩展、系统代理和应用自身代理设置，而不是立即重装客户端。

区分全局故障与单个应用故障

只有一个网站失败时，先换同类型的另一个网站，再观察日志中的出站选择。如果其他网站正常，故障可能与目标站点、分流命中、证书或账户状态有关。浏览器显示的 HTTP 错误页面也与连接超时不同：能够收到明确的响应状态，往往说明请求已经到达某一服务，不能把所有页面错误都归结为节点离线。

只有一个应用失败时，确认它是否读取系统代理。部分程序使用独立的网络设置，部分流量使用 UDP，不能仅凭浏览器能打开页面来判断所有应用都应正常。先在应用设置中核对代理协议与端口；确需接管更多流量时，再了解 TUN 模式的权限与路由影响。不要同时启用多个接管工具来碰运气，这会让流量入口变得难以判断。

02 / 检查连接建立过程

节点超时：分清端口与握手

超时表示某个阶段没有在等待期限内完成，并不直接说明节点配置错误。客户端的延迟测试、建立 TCP 连接、TLS 握手和实际网页请求可能使用不同的目标与测试方式，因此结果不能互相代替。先保留原始错误和发生时间，再沿“本地监听 → 服务端地址解析 → 服务端端口 → 协议握手 → 目标访问”的顺序检查。

先确认客户端实际使用了哪个配置

在 v2rayN 中确认活动服务器是否就是刚刚测试的条目，尤其注意同名节点、不同订阅分组和更新后重新出现的旧配置。节点名称只是标签，不能据此判断真实地址或协议。打开编辑窗口核对服务器地址、端口、用户标识、传输方式和 TLS 设置，并与配置提供方的原始信息逐项比较，避免手动补全看似熟悉的参数。

对于使用 TLS 的配置，服务器地址与握手使用的服务器名称不一定相同，后者通常对应 SNI 或 serverName。使用 WebSocket 时，还需核对路径和 Host；使用 gRPC 时，应确认服务名称。每个字段都有明确用途，不应随意用网站域名替换。若订阅导入内容完整，优先保留原始值，先检查是否误选了其他条目或过期配置。

系统时间也会影响握手。若日志出现证书尚未生效、已经过期或名称不匹配，先检查设备日期、时区和自动校时状态，再核对服务器名称。不要把关闭证书验证当作常规修复：它可能掩盖地址配置错误或中间设备干扰。设备时间正常而证书仍异常时，应让服务维护方检查证书与服务配置。

把端口可达与协议可用分开验证

Windows 可使用下面的命令检查远端 TCP 端口；这里的地址与端口仅用于说明语法，需换成配置中的实际值。测试期间不要公开包含账户标识的完整链接。结果为成功，只说明 TCP 连接能够建立，不代表认证、TLS、传输层和代理出站都已经通过；失败也可能来自防火墙、网络路径或服务未监听，而不是客户端界面的问题。

Test-NetConnection -ComputerName example.com -Port 443

若 TCP 端口无法连接，先在同一设备上换一个已知正常的网络复测，再对比另一条配置。不要连续快速重复大量测试，等待连接超时本身就需要时间。若仅某个网络失败，保留网络差异作为线索；若多个网络对同一服务端口都失败，应由服务维护方检查监听端口、入口规则、证书续期和服务运行状态。

根据对照结果决定修复位置

端口可达但握手失败时，重点回看协议与传输参数，并确认所用内核支持该配置组合。V2Fly 与 Xray 的能力并非在所有字段上完全相同；不要只因为条目能导入，就认定当前内核一定能够执行。若启动日志明确提示未知字段或不支持的功能，应按配置需求选择兼容的客户端设置，而不是删除字段直到日志不再报错。

只有真实请求失败、节点测试却正常时，应检查服务端的目标访问能力和客户端路由。节点测试通过只能证明测试所覆盖的路径正常。修复后仍用原来的目标请求复测，并观察对应日志是否命中了预期出站；如需更细的逐层说明，可阅读节点超时排查顺序，把成功停在哪一层记录下来，避免重新从头猜测。

03 / 区分获取与解析

订阅失败：先检查更新路径

订阅更新至少包括获取地址内容、识别内容格式和写入节点列表三个环节。“更新失败”可能发生在任意一步，与已经保存的节点是否可连接没有必然关系。先保留现有分组，不要一开始就删除全部节点。记录更新时使用的是“更新订阅（不通过代理）”还是通过代理的方式，以及日志中最后一条与订阅有关的错误。

核对完整地址，但不要公开访问凭据

在“订阅分组设置”中打开对应分组，确认地址没有多余空格、换行、中文标点或截断的查询参数。订阅地址通常带有识别账户的内容，复制时应从可信来源获取完整文本，不能只复制浏览器展示出来的一部分。本文示例统一使用 https://example.com/sub，它不是可用订阅，也不应直接填入客户端期待产生节点。

若原地址曾在聊天记录、截图或公开文档中出现，应先按提供方的方式重置订阅访问凭据，再使用新地址。排错时只需记录域名是否能解析、返回状态和错误摘要，不需要把完整链接交给他人。即使是临时求助，查询参数、用户标识和完整订阅响应也应隐藏；节点列表里还可能包含其他连接信息，不能只遮住名称。

确认账户状态是否有效，以及订阅入口是否已经更换。返回空列表可能是当前分组没有可用条目，也可能是提供方没有给该账户分配配置；它与客户端无法解析是两类问题。先查看更新日志中的响应与条目数量，再向配置提供方核对账户状态。不要通过猜测地址路径或手工修改访问参数来寻找替代入口。

分别测试直连更新与代理更新

当当前节点已经失效，而更新订阅又依赖该节点时，会出现“需要新节点才能更新、需要更新才能拿到新节点”的循环。如果订阅域名在当前网络可直接访问，先使用“更新订阅（不通过代理）”。若直连路径不可用而另有一条已知可用的配置，再尝试通过代理更新。两种方式都失败时，应分别记录结果，不要只写“订阅打不开”。

直接在浏览器访问订阅地址，可以辅助判断是否存在认证页面或网页提示，但不能据此认定客户端也能成功更新。浏览器可能使用不同代理、缓存或登录状态；客户端收到的可能是另一种响应。尤其遇到要求登录、网页验证或网络认证的页面时，返回状态看似成功，内容却是 HTML，而不是客户端能够识别的订阅数据。

处理格式不兼容与更新后的差异

有些订阅入口按客户端类型返回不同格式。能够作为网页下载，并不表示内容适合 v2rayN、v2rayNG 或 v2flyNG。若日志显示内容已获取但没有识别出节点，应在提供方的订阅选项中选择适合该客户端的格式。不要把任意配置文件改成另一种扩展名，也不要将完整订阅交给来源不明的转换服务，避免连接信息外泄。

更新后节点数量变化时，先检查当前筛选条件、选中的订阅分组和列表排序，再判断条目是否真正丢失。相同名称也可能对应更新后的地址，旧条目被替换并不一定是错误。如果有手动添加的配置，应放在独立分组中管理；更新订阅前保留必要的本地备份，但不要把备份放进公开共享目录或自动上传的截图文件夹。

04 / 保持测试条件一致

速度慢：区分延迟与吞吐

打开网页慢、下载速度低和视频缓冲并不是同一种性能问题。网页包含解析、建立连接、握手和多个资源请求，下载更依赖持续传输能力，实时应用还会受抖动与丢包影响。先写清楚慢在什么操作上，再选择对应的对照测试。仅凭节点列表里的一个延迟数字排序，不能判断它在所有任务中都更快。

建立可重复的性能对照

测试时固定同一设备、同一网络、同一目标和相近时段，暂停后台同步、系统更新及其他下载。先确认本地直连速度是否也在下降，再比较不同节点的同一请求。如果同时更换测试网站和节点，目标服务器的负载差异会混入结果。一次速度变化只能作为线索，应在相同条件下复测，避免把偶然波动当成稳定结论。

使用 v2rayN 的测试功能时，要先区分 TCP 连接测试与实际请求测试。前者主要观察建立连接是否及时，后者会涉及更多链路环节；显示为空或超时，也可能是测试目标不可达，而非所有目标均失败。记录测试类型与目标，结合浏览器实际访问判断，不要为了得到好看的数字反复修改测试设置，最后却失去了可比性。

无线信号强不等于链路稳定。可以在同一台电脑上靠近路由器复测，或在条件允许时用有线网络对照；移动网络则关注信号变化、热点共享与套餐限速。若家中多台设备同时传输大量数据，出口拥塞会影响所有节点。此时换客户端通常没有帮助，应先排除本地网络竞争，再观察代理路径是否仍然明显偏慢。

观察慢发生在哪个阶段

如果首次打开页面慢，随后刷新明显加快，优先检查 DNS、连接复用与握手阶段；若开始很快、持续下载逐渐下降，则需要看服务端带宽、目标限速和网络拥塞。若仅某个网站慢，换同类目标对照并检查分流命中，确认请求是否绕到不合适的出站。不要为了一个网站的表现，直接把所有流量都改成同一种路由方式。

日志可以帮助观察连接是否频繁重建、是否重复解析失败，但排错期间不宜长期使用极高详细度的日志。大量磁盘写入会增加负担，也会保留更多访问记录。截取问题出现前后的短时间窗口即可；问题定位后恢复日常日志级别。若要共享日志，只保留错误上下文，并移除订阅地址、用户标识和不需要公开的访问目标。

对使用 UDP 的应用，需要确认协议组合、客户端配置和服务端都支持对应流量。浏览器网页正常，并不能证明实时应用的数据路径相同。某些网络还会对 UDP 有不同处理方式，因此应使用应用自身的连接状态作为依据。切换到 TUN 模式前先理解其接管范围，不要把它当作提高带宽的开关；它主要改变入口，不会凭空增加出口能力。

避免用高风险设置掩盖性能问题

遇到部分大页面卡住、某些连接可用而另一些长时间等待时，可以把路径 MTU 列为后续排查项，但不要一开始就随意设置极小的数值。先排除 DNS、协议不兼容与目标故障，确认问题与某一网络或隧道模式相关后，再按客户端说明逐步调整，并记录原值。每次调整后都应复测正常网站与原故障目标，防止只修复一处却影响其他连接。

传输方式、复用与并发参数也不是越大越好。服务端资源有限或链路不稳定时，增加并发可能加剧竞争；不匹配的复用设置还可能带来兼容性问题。优先使用配置提供方给出的组合，只有在具备明确对照条件时才做单项实验。若换一个可用节点即可恢复，而本地设置没有变化，记录节点差异通常比继续堆叠参数更有价值。

05 / 确认由谁解析域名

DNS 问题：追踪解析路径

DNS 把域名转换为连接所需的地址，但在代理环境里，系统、浏览器、客户端和远端都可能参与解析。出现“找不到服务器”或域名相关超时，不应立即把所有 DNS 地址替换成同一个公共服务。先确认失败的是节点服务器域名，还是要访问的网站域名，再查是哪一层发起了查询，以及查询本身是否有可用的网络路径。

先区分入口域名与目标域名

如果客户端尚未连接节点，就已经提示服务器地址解析失败，问题发生在代理入口之前。此时把解析请求全部交给尚未建立的代理，可能形成循环依赖。先用系统工具查询节点域名，检查当前网络的解析服务是否可达；必要时按配置提供方建议使用合适的解析路径，但不要把节点域名直接替换为任意查到的地址，证书和路由也可能依赖域名。

若节点已连接，只有某些目标域名失败，应看客户端日志中的解析错误与出站选择。通过域名规则分流时，域名是否保留、在哪一步转换为地址，会影响规则匹配。浏览器启用独立的安全 DNS 后，也可能与系统查询结果不同。先记录现有设置，再临时做一项对照，不要同时更改浏览器、系统和客户端三处 DNS。

下面的查询命令分别用于 Windows 与常见的桌面环境。它们主要反映系统当前解析路径，不代表客户端内置解析器必然获得相同结果。查询成功后仍需验证实际 HTTPS 请求；直接打开解析出来的 IP 不是等价测试，因为许多网站依赖域名进行证书验证、虚拟主机选择和内容分发。

# Windows PowerShell
Resolve-DnsName example.com

# 具备 nslookup 的系统
nslookup example.com

用代理测试确认解析责任

SOCKS 测试中，socks5h 会把目标域名交给代理端处理，而某些工具使用 socks5 时会先在本地解析。两种结果不同，说明解析路径值得进一步检查，但不能只靠这一处差异判断具体故障位置。还需要结合客户端的 DNS 设置、路由策略和日志，确认远端解析请求究竟走向哪里，是否被错误地指回本地。

使用加密 DNS 时，也要先解决解析服务自身的可达性。解析服务采用域名地址，可能需要引导解析；若它的连接又依赖当前故障路径，就会出现启动阶段持续等待。不要照抄不明来源的整段配置。应先明确它服务哪些域名、通过哪个出站访问、失败时如何处理，再依据当前内核支持的格式填写，避免把不同内核的字段混用。

IPv4 与 IPv6 的可达性差异同样会造成“有时能开、有时等待”。域名可能同时返回两类地址，而当前网络只对其中一类提供完整路径。先比较日志中实际尝试的地址族，再在客户端支持的范围内做临时策略对照。不要只因为一次失败就永久关闭整台设备的 IPv6；应确认变化确实与问题有关，并保留恢复原设置的记录。

把 DNS 与路由规则一起检查

路由排查可以从简单规则开始。下面是 Xray 风格的路由片段，不是完整可直接启动的配置；其中 proxy 与 direct 必须对应现有出站标签。它说明域名规则与地址规则的区别，不应直接覆盖客户端生成的全部配置。图形客户端通常会重新生成运行配置，持久修改应通过“路由设置”等受支持入口完成。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

规则通常按顺序匹配，过宽的前置规则可能让后面的精细规则没有机会命中。局域网地址也不应随意送往远端代理，否则本地管理页面和内网服务会受影响。修复 DNS 后，再观察同一目标是否命中预期出站；只看到查询返回地址，并不能证明路由与连接已经完成，最好保留一条实际请求日志作为验证。

最后再考虑清理缓存。Windows 的 ipconfig /flushdns 只清除系统 DNS 缓存，不会自动清除浏览器独立缓存、客户端缓存或远端缓存。先修正错误来源，再关闭并重新打开相关应用复测；如果每次清缓存只能短暂恢复，应继续检查解析策略与网络切换，而不是把反复清理缓存当作长期使用步骤。

06 / 核对应用流量入口

系统代理不生效：检查接管范围

系统代理是操作系统提供给应用的一组代理设置，不是对全部网络流量的强制接管。v2rayN 中选择“自动配置系统代理”后，通常只有读取相应设置的应用会使用它；独立代理配置、浏览器扩展、命令行环境变量和 TUN 模式还可能形成其他入口。排查时先确认目标应用到底读取哪一套设置，再处理对应位置。

核对系统地址与本地监听

Windows 用户先在 v2rayN 的“系统代理”菜单中选择“自动配置系统代理”，再到系统“设置 → 网络和 Internet → 代理”核对实际生效的地址与端口。具体项目可能表现为手动代理或设置脚本，应以客户端当前工作方式为准。不要只看托盘图标颜色；系统设置被其他程序改写后，客户端界面未必能立即反映所有变化。

地址为本机回环时，应与客户端真实监听端口一致。127.0.0.1 只代表当前设备，适合本地应用连接本机客户端；它不能用来让手机访问电脑代理。若端口曾被修改，系统与浏览器可能还保存旧值。先通过显式代理请求确认新端口可用，再重新应用系统代理设置，避免在一个未监听的地址上反复切换模式。

macOS 可在“系统设置 → 网络”中选择当前网络服务，进入“详细信息 → 代理”检查设置；不同系统界面名称可能略有差别。无线与有线连接可能对应不同网络服务，切换网络后需要核对当前项。Linux 桌面环境的系统代理入口与应用读取方式不完全一致，有些应用只认自身设置，不能照搬另一种桌面的操作结果。

排除多套代理设置互相覆盖

若浏览器和其他应用表现不同，暂时停用浏览器中的代理扩展，并检查是否存在启动参数或管理策略。命令行工具则可能读取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 和 NO_PROXY 等环境变量。修改环境变量后，已启动进程可能仍保留旧值，需要重新打开终端或应用；系统代理切换不一定会同步改掉这些变量。

不要同时运行多个会修改系统代理或默认路由的工具。它们可能交替覆盖地址，也可能让本应直连的代理出口再次进入另一条隧道，形成循环。先退出其他接管程序，保留单一客户端与明确的入口，再测试原应用。若必须组合使用，应先明确每一段的监听地址和流向，而不是依赖默认设置自动衔接。

“不改变系统代理”并不等于“清除系统代理”。前者通常保留系统当前状态，后者才会主动移除客户端设置的代理入口。因此关闭窗口、退出托盘与清除代理也不能互相替代。遇到退出客户端后无法上网，先检查系统是否仍指向本地端口；正常恢复设置后再复测，不要通过重新启动失效节点来维持基础网络。

局域网共享与 TUN 分开排查

手机需要使用电脑代理时，应在电脑的“参数设置”中启用“允许来自局域网的连接”，确认监听端口与电脑内网地址，再按需设置防火墙入站规则。防火墙规则应限制为可信网络和必要端口，不要为排错整体关闭防护。手机与电脑还需要能在局域网互访，访客网络隔离和热点限制都可能阻断连接。

TUN 模式异常则重点查看虚拟接口、权限和路由是否创建成功。启用后如果连节点服务器自身都不可达，需检查是否出现出口再次被接管的循环。先关闭 TUN，用显式本地代理确认节点可用，再单独启用并对照。更多共享操作见允许局域网连接设置；复测时既检查目标应用，也检查本地网络服务是否仍可访问。

07 / 区分界面与内核进程

客户端崩溃：保留现场再修复

客户端打不开、窗口闪退和节点内核退出需要分开处理。前两种主要影响图形界面，后一种可能表现为界面仍在但所有请求失败。先记录操作系统、芯片架构、下载的包类型，以及故障发生在启动、导入还是连接时。不要直接删除整个用户目录，因为订阅分组、路由规则和问题日志可能都在其中，删除后反而难以还原原因。

核对安装包与系统环境

先到客户端下载页核对平台与架构。Windows 的 v2rayN 桌面版与经典 WPF 版是不同界面实现，运行依赖与系统适配要求应按所选包的说明确认；macOS 应区分 Apple Silicon 与 Intel；Linux 还要区分处理器架构和发行版包格式。包能下载完成，不表示适合当前设备，架构错误可能在启动阶段就退出。

Windows 上若出现明确的运行时缺失提示，按错误中指出的组件与架构处理，不要下载来源不明的散装动态链接文件。便携式目录应完整解压后再运行，不能只把主程序拖出压缩包。路径权限、临时目录清理和文件被安全软件隔离也会导致启动不完整，应结合系统提示逐项核对，而不是把所有失败都归结为系统版本。

macOS 提示无法验证开发者时，先确认文件来源与下载包类型，再按“系统设置 → 隐私与安全性”中的相关提示处理。不要为打开一个应用而整体关闭系统安全机制。若提示文件损坏、组件缺失或架构不匹配，也不应一律当成权限问题；可结合macOS 首次打开与权限说明区分拦截提示和真正的程序异常。

读取日志，而不是反复重启

能打开界面时，先查看客户端日志与内核日志是否分别存在。若导入后立即报配置错误，优先找第一条解析失败或字段不支持的记录；后续大量连接失败可能只是它的连带结果。若每次点击连接都提示端口占用，应检查是否已经有另一个实例运行，而不是不停换端口，最终让系统代理与监听设置进一步分离。

Windows 可用下面的命令检查示例端口的监听进程编号。得到编号后，在任务管理器中确认程序身份；不要根据一个不熟悉的编号直接结束系统进程。若是重复启动的客户端，先从托盘正常退出多余实例，再重启一个。若确有其他服务需要该端口，给客户端选择空闲端口后，还要同步更新所有引用该端口的应用设置。

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

Linux 图形程序启动即退出时，可以从终端启动已安装的程序，观察缺失依赖、显示环境或权限相关错误。软件包安装器的错误也应先处理完毕，再测试应用；手动复制单个可执行文件未必能补齐依赖。若程序在普通权限下能够运行，就不应为了方便长期以管理员身份启动，只有确有需要的网络接管功能才单独处理权限。

以最小配置定位损坏范围

怀疑用户配置损坏时，先退出程序，再按客户端支持的方式备份配置目录，保留原文件不动。若需要新建配置环境，应使用新的用户数据目录或按说明重置，不能默认换一个安装目录就一定得到独立配置。先在空白环境确认界面能打开，再只加入一条已知有效的配置，暂不导入全部路由、订阅与自定义参数。

若最小环境正常，再按订阅、路由、特殊网络功能的顺序逐项恢复，每恢复一项都重新测试。某一步恢复后重现崩溃，就能把范围缩小到该部分，而不必丢弃所有设置。若两个界面版本表现不同，可阅读桌面版与 WPF 版区别，按系统适配选择，但不要把换界面当作节点或 DNS 故障的通用修复。

08 / Android 网络与后台限制

移动端专项：权限与网络切换

Android 上首选 v2rayNG，需要 V2Fly 内核兼容路径时可考虑 v2flyNG。两者的图形操作相近，但内核支持范围和部分设置不能简单视为完全一致。手机出现连接后仍无法访问、锁屏断开或切换网络后失效时，应先检查 VPN 授权、应用路由和后台运行状态，再回到节点与 DNS，避免把移动系统限制误判成服务端故障。

先确认 VPN 服务真的启动

首次启动连接时，系统会请求建立 VPN 连接的授权；只有同意后，客户端才有条件建立相应的本地虚拟网络接口。状态栏出现 VPN 标识也只说明服务已建立，不代表远端节点已经连接成功。启动后立即查看应用日志，确认没有配置解析失败、权限被拒绝或服务随即停止，再使用已知目标做实际访问测试。

同一用户环境中的 VPN 服务通常不能由多个应用同时接管。若已有其他网络工具、工作环境策略或系统服务占用入口，新连接可能替换原服务，也可能无法建立。先停止其他接管应用，再启动单一客户端。设备受组织管理时，还应检查管理策略是否限制 VPN 配置；不能通过反复安装不同客户端绕过设备本身的授权要求。

若配置了“始终开启的 VPN”或“阻止不通过 VPN 的连接”，客户端未启动或连接失败时，系统可能按策略阻断其他网络。排错前记下这些选项，必要时临时关闭进行基础网络对照，结束后再按需要恢复。不要只在应用内停止连接，却忽略系统仍要求所有流量经过一个已经停用的服务。

检查分应用代理与后台运行

只有部分应用异常时，查看客户端是否启用了分应用代理或排除列表，注意当前模式是“仅代理选中应用”还是“绕过选中应用”。同一份应用列表在两种模式下意义相反。修改后重新建立连接，并彻底退出再打开目标应用，以免旧连接仍沿用先前路径。若工作资料与个人资料分离，还需确认正在测试的应用属于哪个环境。

锁屏后中断而亮屏恢复，常与系统电池优化、后台数据或厂商的自启动管理有关。到系统应用信息中检查电池策略和后台联网权限，在需要持续连接时给予合适权限，但不必关闭整台设备的节能机制。观察断开时 VPN 标识是否消失、应用服务是否重启，以及日志有没有重新启动记录，从而区分进程被回收与远端连接超时。

前台服务通知有助于判断运行状态，某些系统还会独立管理通知显示。通知不见了不必然说明内核已经停止，应结合系统 VPN 状态和日志判断；反过来，通知仍存在也不保证远端可用。若每次恢复后台权限后仍会在相同条件下中断，记录锁屏时长、供电状态和网络类型，再逐项对照，避免一次改动多个系统选项。

切换网络后重新验证解析与出口

从无线网络切到移动数据后，原有连接可能已经失效，DNS、IPv6 和默认路由也可能改变。先等待网络本身就绪，再断开并重新连接客户端，然后打开新的请求测试。若只有某个无线网络失败，检查是否需要网页认证或存在设备隔离；若只在移动数据下失败，则比较节点端口可达性与解析结果，而不是直接重置所有应用数据。

手机接入电脑共享的代理时，需要在无线网络的代理设置中填写电脑的局域网地址与实际 HTTP 或混合端口，不能填写手机自身的回环地址，也不能把只提供 SOCKS 的端口当作 HTTP 端口使用。该设置通常只影响遵循无线代理的应用。测试前先确认电脑保持开机、客户端正在监听，并按系统代理章节检查局域网连接与防火墙。

若导入成功却启动报错，回看配置所需的内核能力。v2rayNG 与 v2flyNG 应使用各自支持的配置格式与功能组合，不要靠改节点名称判断兼容性。需要重新安装时，从Android 下载入口按处理器架构选包；多数较新的设备适合 arm64，不确定时可参考通用包说明，而不是根据文件大小猜测。