V2Ray 故障排查
连接、订阅与系统代理

无法上网：先分清哪一段断开

出现所有网页都打不开时，先不要删除配置。一次连接通常经过应用、接管入口、本地内核、远端服务器和目标站点。界面显示已运行，只能说明客户端进入运行状态，不能证明每一段都通。先退出其他代理工具，暂时关闭 TUN，再把系统代理设为「清除系统代理」。访问平时能够直接打开的网站，确认基础网络、无线认证和默认网关仍然工作。

先恢复直连，再检查本地监听

如果清除代理后仍无法访问，先检查网络是否需要网页登录、系统时间是否准确，以及其他设备在同一网络是否正常。此时继续更换节点通常没有意义。若直连恢复，再启动 v2rayN，选定已有服务器，执行「重启服务」，查看日志里有没有内核退出、配置解析失败或监听失败。不要只看托盘图标；窗口仍在而内核已退出时，浏览器会连接到一个不存在的本地服务。

打开「设置」中的「参数设置」，记录「本地混合监听端口」。下面命令以实际设置为 10808 的情况说明；若端口不同，先修改命令。先查是否存在监听，再对照进程，不能把任意占用这个端口的程序都当成正确内核。仅看到监听成功，证明的是本机入口已建立，还需要下一步验证远端连接。

# Windows PowerShell：查看监听地址、端口和所属进程
Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# 向本地 HTTP 代理发起一次明确的请求
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:10808 https://example.com/

命令中的目标仅用于演示请求形式，不保证在当前网络中可达。实际排查应选一个已知可用、允许访问的目标，并保持前后测试一致。收到目标的 HTTP 响应，即使是拒绝访问或重定向，也与连接超时不同：它说明请求已走到某个 HTTP 服务。遇到证书错误则继续核对时间、目标名称和证书链，不要通过关闭证书验证把错误掩盖掉。

用结果决定下一步，不用猜测替代验证

如果显式代理请求成功，再选「自动配置系统代理」，完全退出并重新打开浏览器后复测。仍失败时，用另一个没有代理扩展的浏览器对照。只有一个应用异常，多半应检查该应用自身的代理、缓存或网络权限；全部应用异常，再看系统接管。隐私窗口不一定禁用了全部扩展，不能把它当成彻底排除扩展影响的证据。

若只有部分站点失败，先记录失败域名、错误类型和发生时间，检查是否命中了直连规则。临时切换路由只能作为对照测试，不应把所有流量长期改走同一路径来遮住问题。恢复原规则后，针对目标检查域名匹配、解析结果和规则顺序。路由变更以后要建立新连接，旧连接仍可能沿用原出口，立即刷新一次不一定反映新设置。

结束本轮时写下「直连是否正常、本地是否监听、显式代理是否成功、应用是否跟随」四项结果。它们比一句「不能上网」更便于继续定位。有关单个问答可查疑难解答；若监听端口无法建立，转到本地端口占用排查，不要反复重装客户端。

节点超时：区分传输连接与协议握手

节点测试显示超时，并不等于服务器已经停止运行。测试可能停在域名解析、建立连接、加密握手或获取测试目标响应的任意阶段。先确认测试使用的目标与方式，避免把某个测试站点不可达理解为所有请求都失败。保留当前节点配置，选同一订阅里另一个已知可用的服务器对照；不要一次刷新订阅、切换内核和改传输参数，否则无法判断是哪一步改变了结果。

沿日志顺序找出首个错误

先核对服务器地址和端口是否完整，尤其检查复制时混入的空格、换行或端口截断。域名解析失败时优先处理解析；连接被拒绝通常说明到达的地址上没有相应服务，或者中间设备主动拒绝；连接超时则只说明规定时间内没有完成连接，不能单凭这条日志确定责任位置。记录首条相关错误，后续一串连接取消可能只是前一个失败引发的连锁结果。

在 Windows 可以检查远端端口能否建立普通 TCP 连接。下例让 PowerShell 交互读取已有配置中的地址与端口，不把真实信息写进命令历史。测试成功只代表 TCP 层可达，不证明账号、传输路径或 TLS 参数正确；失败也不直接证明服务端损坏。该方法不适合用来判断仅使用 UDP 的链路，测试结论必须限定在所测协议上。

$server = Read-Host "输入已有配置中的服务器地址"
$port = [int](Read-Host "输入已有配置中的服务器端口")
Test-NetConnection -ComputerName $server -Port $port -InformationLevel Detailed

如果普通连接能建立，而客户端提示握手失败，就核对协议及传输层参数。VMess、VLESS、Trojan 的认证字段不能互换；WebSocket 的路径和 Host、gRPC 的服务名称都必须与服务端一致。使用 TLS 时，连接地址与服务器名称可能不同，不能因为地址填的是 IP 就顺手删掉服务器名称。REALITY 配置中的公钥、短标识及相关参数也必须来自正确配置，不能照着另一条节点拼接。

把时间、网络和内核分别验证

发现证书尚未生效、已过期或认证时间相关错误时，先检查系统日期、时区与自动校时结果。时间错乱会影响证书和部分认证流程，但调整时间不是所有超时的通用办法。证书名称不匹配则应检查服务器名称与配置来源，不要开启跳过证书验证作为长期修复。若公司网络需要认证或存在受管理的安全软件，也应先确认其连接策略，而不是直接关闭安全防护。

用另一种网络复测时，保持客户端、节点和目标不变。例如在获准使用的移动热点上完成一次相同请求，再回原网络测试。如果仅某个网络失败，重点查看网络认证、出口限制和地址族可达性；如果所有网络都失败，而其他节点正常，重点检查该节点的服务状态与参数。双栈网络中，域名解析到的 IPv6 地址可能没有可用路径，但不要据此永久关闭整台设备的 IPv6。

更换 Xray 或其他受支持内核前，先确认节点协议及传输方式在目标内核中可用。图形界面能保存字段，不代表任意内核都会按相同含义执行。优先使用订阅与客户端原本匹配的组合，在保留原配置后单独测试。若新配置导入后才异常，可以拿上一次可用的配置作差异对照，但不要把已经撤销或过期的认证信息当作可靠基准。

把结果交给配置提供方时，说明发生时间、网络类型、协议、是否能建立 TCP 连接，以及去除敏感信息后的首条错误。不要发送整份订阅或包含认证字段的截图。若一个节点只能连接少数目标，还要继续检查出口路由和 DNS；只有确认所有目标都在同一阶段失败，才适合把问题归到节点本身。恢复可用后，取消临时日志级别并还原测试路由。

订阅失败：分开检查获取、解析与应用

订阅更新失败至少包含三种不同情况：地址没有取回内容、内容取回但格式无法识别、列表更新成功但选中的服务器失效。先看日志究竟停在哪一步，再检查「订阅分组设置」里的目标分组。不要连续创建多个同名分组，也不要为了清理错误先删掉最后一份可用配置。更新前记录分组名称、节点数量变化和当前选中项，避免误把更新后的选择变化当成整份订阅不可用。

确认地址仍然有效，且取回的是配置

先核对地址是否完整，查询参数、大小写和末尾字符都可能影响请求。订阅地址往往具有访问权限，应当像账号信息一样保存，不要贴进公开工单、截图或在线转换工具。若地址来自网页按钮，确认复制的是订阅链接而不是账户页面、二维码图片地址或浏览器跳转页面。对网页显示内容的观察只能辅助判断，浏览器能够访问并不等于客户端请求会获得相同响应。

出现未授权、禁止访问或找不到资源一类响应时，检查订阅是否到期、令牌是否重置、地址是否发生变更。此时多换几次 DNS 通常不能解决权限问题。若响应是登录页面、验证码页面或维护通知，即使状态码表示请求成功，返回的也不是节点配置。遇到这种情况应从配置提供方获取正确入口，不要把网页正文手工编码后再导入客户端。

若请求超时，分清更新通道。已有连接正常时可以测试通过代理更新；当前没有任何可用服务器时，尝试菜单中「更新订阅(不通过代理)」所对应的路径。两者不是越多开越好，而是针对订阅服务器的可达性选择。更新请求所用通道不一定与浏览器相同；浏览器扩展、系统代理和 TUN 的组合可能让对照结果产生误导。

检查格式，再检查更新后的选择

不同客户端支持的订阅格式和扩展参数不完全相同。带有大量专用规则的完整配置文件，不一定能作为节点订阅直接导入；导入成功也不保证所有扩展字段保留。优先索取明确适用于 v2rayN 或安卓客户端的格式。必须转换时，先理解转换会处理哪些字段，尽量在可信环境完成，尤其检查传输层、TLS 和 REALITY 参数是否被丢弃。

更新后节点消失，先检查分组筛选条件和搜索框，不要立刻认定订阅返回空内容。含空格或大小写差异的过滤关键字可能把可用条目全部隐藏。清空临时搜索再观察，确认实际更新的是预期分组。如果订阅替换了原有节点，原先选中的对象可能已经不存在；重新选择列表中的一条服务器并重启服务，然后用显式代理请求验证，而不是仅看分组更新提示。

设置自动更新间隔之前，先完成一次手动更新并确认通道可靠。间隔过短会造成重复请求，也可能触发服务端限制；设备休眠、断网或后台任务暂停时，定时器未必按墙上时钟准点执行。不要因漏了一次定时更新就同时开启多个刷新任务。对频繁失败的分组，暂时恢复手动更新，记录失败时间和响应，再针对网络与权限定位。

若手动成功而自动失败，对照设备唤醒时间、网络切换及更新时的代理状态；若所有客户端同一时间失败，再检查地址和服务端状态。排查记录只写错误类型，不保存完整订阅 URL。关于分组更新方式和间隔的进一步说明，可查订阅更新失败与自动刷新设置。地址更新成功后仍超时，应转回连接层排查，不要重复刷新来碰运气。

速度慢：把延迟、吞吐与丢包分开

网页首屏慢、文件下载慢和视频间歇停顿不是同一种故障。首个请求耗时长，可能来自解析、建立连接或握手；持续下载速度低，可能受远端出口、目标站点、无线网络和本机负载共同影响。先描述可重复的症状，例如首次打开慢但刷新正常，或所有大文件都慢。不要用单次延迟测试给节点排序后就认定原因，较低的往返时间不保证更高吞吐。

固定测试条件，再比较不同路径

选择同一目标、同一文件和相近时间做对照，暂停云同步、系统下载和其他占用网络的任务。直连目标与代理目标如果不是同一个，就无法单独比较路径差异；不同内容分发节点也可能让结果波动。先在一个服务器上重复两三次，再更换服务器。不要同时开启多条测速任务，测速本身会争抢带宽，使本来可用的连接看起来异常。

下面命令将内容丢弃，只输出请求阶段耗时与平均下载速度，适合小规模重复测试。目标和端口应按实际环境调整。经过 HTTP 代理时，名称解析和连接指标的含义会受代理协议影响，不能把每一项直接当成远端 DNS 或远端服务器的独立耗时。小页面的平均下载速度容易受到握手占比影响，也不适合推断大文件上限。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total} speed=%{speed_download}\n" https://example.com/

如果每次连接都快，但首字节等待很长，检查目标服务响应和远端出口；如果首字节正常而传输中反复停顿，观察无线信号、丢包及系统资源。普通 ping 被拒绝不等于业务连接失败，连续 ping 正常也不能证明加密连接没有问题。优先采用实际使用的协议做请求，再把网络诊断工具作为旁证，而不是用某一个数字替代完整的使用结果。

排除本地资源与接管方式影响

查看任务管理器或系统监视器，关注内核进程的处理器占用、内存以及磁盘活动。老设备、节能模式和温度限制可能影响加密与转发；日志长期处于详细级别也可能带来额外写入。先恢复普通日志级别，关闭不必要的后台任务，再重试。不要为了省资源随意禁用安全软件，更不要把异常高占用一概归因于客户端，需要同时查看当时的实际流量。

分别测试显式代理、系统代理和 TUN，前提是每次只启用一种明确路径。若只有 TUN 慢，重点检查虚拟网卡、路由冲突和其他网络过滤软件。若只在大文件或特定链路上卡住，可在保留默认值的前提下排查 MTU 适配，但不要从网上抄一个数值长期使用。修改 MTU 后必须重新建立连接，并对多个目标验证，小页面正常并不足以说明问题已经解决。

视频卡顿还可能来自目标站点限速、内容分发位置或应用自己的缓冲策略。同一节点访问一个站点慢而其他站点正常，先检查目标对应的路由与出口，不必立即重装。浏览器启用的安全 DNS、扩展或缓存会让它与命令行走不同路径；应用使用 UDP 时，普通网页的 TCP 测试也不能覆盖其真实行为。对照时应注明应用、目标和传输类型。

如果晚上慢、白天正常，而本机资源和无线链路稳定，可把时段性拥塞作为待验证原因；换网络后恢复，则进一步比较本地接入链路。不要把偶尔一次变快归功于刚改的参数，至少恢复原设置做一次反向对照。确认改善可重复后，再保留必要变更。规则越复杂不代表速度越好，减少重复代理和无效过滤，通常比叠加更多「加速」设置更容易得到稳定结果。

DNS 问题：分清谁在解析目标域名

域名打不开而某些 IP 能连接，只能提示解析路径值得检查，不能立即证明 DNS 是唯一原因。HTTPS 站点依赖服务器名称和证书，直接用 IP 打开会改变请求条件。先区分系统解析、浏览器安全 DNS、代理内核解析和远端解析：同一个域名可能在不同位置得到不同结果。记录请求由哪个应用发起、用了哪种代理协议，再判断应当调整哪一层。

先观察解析结果，再处理缓存

在 Windows 使用下面命令查询系统解析结果，同时查看各网络接口的 DNS 配置。注意有线、无线、虚拟网卡可能同时存在；系统实际选择的路径不一定是正在查看的那张网卡。返回多个地址本身不是异常，内容分发和双栈服务都会产生多条记录。重点检查是否报解析失败、是否出现不符合预期的内网地址，以及结果能否通过当前网络到达。

# Windows PowerShell：检查系统解析与接口 DNS
Resolve-DnsName example.com
Get-DnsClientServerAddress

# 修正解析配置后，如需清除系统缓存
Clear-DnsClientCache

清缓存应放在修正配置之后。若上游仍有问题，清除只会再次取回相同错误结果。浏览器、客户端内核和应用自身也可能有独立缓存，系统命令不能全部清除。必要时完全退出相关应用、重启内核后重试，但不必为每次查询都重启整台设备。若问题只出现在休眠唤醒或切换网络后，优先观察旧接口的解析配置是否残留。

使用 SOCKS 时，目标名称可以由本机解析，也可以交给代理处理。下面两条命令的关键差异是域名解析位置，不是「一个安全、一个不安全」。只有本地混合端口确实提供相应服务时才这样测试。若仅远端解析方式成功，应继续检查本地解析与路由；若两者都失败，则还需要结合连接日志，不能只改 DNS 地址。

# 本机先解析目标域名
curl.exe --socks5 127.0.0.1:10808 -I --connect-timeout 10 --max-time 20 https://example.com/

# 交给 SOCKS 代理处理目标域名
curl.exe --socks5-hostname 127.0.0.1:10808 -I --connect-timeout 10 --max-time 20 https://example.com/

把域名策略与分流规则一起检查

v2rayN 路由设置中的域名策略会影响何时为了 IP 规则进行解析。以 Xray 语义为例，AsIs 不为路由主动解析目标域名；IPIfNonMatch 在域名规则未匹配时再尝试按解析出的 IP 匹配；IPOnDemand 则可能在处理 IP 规则时发起解析。具体可选项和行为还要结合当前内核，不能把一个内核的解释直接套到另一个内核。

下面片段仅用于阅读路由语义，不是可直接覆盖客户端生成配置的完整文件。它说明域名策略与规则的关系，不提供通用 DNS 地址，也不替代客户端界面设置。实际修改优先在界面完成，以免下次重启服务时被自动生成的配置覆盖。检查规则时从上到下阅读，先命中的直连规则可能使后面的代理规则根本没有机会执行。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

若使用加密 DNS，解析器本身也需要一条能够到达的连接路径。解析器域名的初始解析、连接出口和代理启动顺序若互相依赖，可能形成循环：没有 DNS 就无法连代理，没有代理又访问不到 DNS。先恢复可用的基础解析，再逐项启用高级配置。不要一次把系统、浏览器和内核全部改成同一个新解析器，否则很难知道是哪一层真正生效。

公司内网、家庭设备名称和公共域名可能需要不同解析范围。把全部查询交给公共解析服务，可能导致内部名称失效；强行让内部地址走远端，也可能破坏本地访问。恢复后分别验证公共站点、局域网服务和休眠唤醒场景。涉及 IPv6 时先检查默认路由及地址可达性，再决定是否调整单个应用的地址选择，不要用全局禁用来替代路径定位。

系统代理不生效：先查应用，再查 TUN

选择「自动配置系统代理」后仍有应用直连，先确认它是否读取系统代理。系统代理是提供给应用的代理设置，不是强制拦截所有网络请求；有些应用采用自己的配置，命令行工具也可能只读取环境变量。TUN 则通过虚拟网络接口与路由接管流量，排查范围更广。两者目标不同，不应在系统代理失败时直接同时开启所有接管方式。

理解三个系统代理选项的边界

「自动配置系统代理」通常用于将系统入口指向客户端的本地监听；「清除系统代理」用于移除相应代理设置；「不改变系统代理」表示客户端不主动修改既有设置，不等于一定直连。切换选项后到操作系统网络设置中核对地址与端口，尤其检查手动代理与自动配置脚本是否并存。其他软件可能重新写入系统设置，界面刚显示成功并不代表随后仍保持不变。

浏览器代理扩展、受管理策略以及应用内部设置都可能覆盖系统入口。先暂时停用相关扩展，再完全退出应用重开；如果浏览器由组织管理，不要擅自修改策略。Windows 中不同网络组件还可能使用不同代理配置，某些系统服务与当前用户浏览器并不共享设置。因此「浏览器能用」只能验证浏览器路径，不能推断更新服务、终端和后台程序都会使用同一入口。

命令行先用显式代理参数测试，成功后才检查环境变量，避免长期修改后忘记恢复。下例只影响当前 PowerShell 会话，适用于支持这些变量的工具；不同程序读取的变量名和优先级可能不同。NO_PROXY 可让指定目标绕过代理，若里面含有过宽的域名后缀，也会造成「部分站点始终直连」的现象。

# 仅当前 PowerShell 会话；端口按客户端实际设置调整
$env:HTTP_PROXY = "http://127.0.0.1:10808"
$env:HTTPS_PROXY = "http://127.0.0.1:10808"
$env:NO_PROXY = "localhost,127.0.0.1,::1"

# 测试结束后移除本次设置
Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue

用最小配置单独验证 TUN

只有明确需要接管不读取代理的应用时，再检查「开启 Tun 模式」。先关闭其他虚拟网络工具和重复代理，确认内核正常、普通代理请求成功，然后按客户端提示处理权限。权限不足、虚拟接口建立失败或路由写入失败，应从日志定位，不要反复点击开关。提升权限前要确认启动的是预期客户端，不要为了排查长期给整个下载目录放宽权限。

TUN 开启后全部断网，优先检查默认路由是否形成回环，客户端连接远端服务器的流量有没有再次被送回虚拟接口。多个虚拟网络工具同时修改路由时，表面上的优先级和实际流量路径可能不同。先逐个退出，再测试单一客户端。需要查看路由时，Windows 可用 route print，Linux 可用 ip route；先记录，不要照着陌生命令直接删除默认路由。

只在 TUN 下局域网不可达，应检查私有地址规则、接口选择与 DNS，而不是把「允许来自局域网的连接」打开。后者控制其他设备是否能访问本机代理监听，与本机能否访问局域网并不是同一件事。开放监听还需要考虑防火墙与可信网段，不能作为所有局域网问题的通用修复。保持本机排查与向其他设备提供代理这两个目标分离。

关闭客户端后断网，先清除系统代理，再确认虚拟接口与路由是否撤销。必要时通过正常界面重连物理网络，但不要直接执行全量网络重置，因为它可能影响固定地址、企业网络和其他虚拟适配器。恢复后测试一次正常退出及一次休眠唤醒。浏览器与终端分别排查的细节可见系统代理不生效排查，避免把应用差异误认为节点故障。

客户端崩溃：区分界面、内核与系统环境

双击没有窗口、窗口闪退和连接时内核退出，应分开处理。先检查任务管理器或系统监视器，确认是否已有进程驻留托盘，避免重复启动造成端口冲突。窗口还在但日志显示服务退出，通常不是界面崩溃；窗口完全消失，则需要查看应用日志与系统事件。记录发生在启动、更新、导入还是启用 TUN 之后，时间点比反复重启更有助于缩小范围。

检查安装形态与运行目录

从客户端下载页按系统和处理器架构选择安装包。Windows 的桌面版与经典 WPF 版使用不同界面技术，不能把其中一版的运行环境要求直接套到另一版。macOS 要区分 Apple Silicon 与 Intel；Linux 要区分发行版包格式及处理器架构。架构错误可能表现为无法执行，而不是清晰的客户端错误提示。不要通过给文件改扩展名来绕过安装方式。

使用压缩包形态时，先完整解压，再从固定目录运行；不要在压缩文件预览窗口里启动，也不要只复制一个可执行文件而遗漏随附资源。安装版则按系统提供的方式修复或重新安装。检查用户数据目录是否可写、磁盘空间是否足够，以及云同步是否正在锁定配置文件。不要把客户端放在需要频繁提权才能写入的临时位置，再用长期管理员运行来掩盖目录问题。

安全软件拦截时，先查看事件记录中的具体文件和原因，确认来源与安装流程，再按组织或设备管理要求处理。不要一开始就全局关闭保护或给整个磁盘添加排除。系统提示缺少运行组件时，按所选客户端构建的要求处理，不要下载来源不明的单个动态库填补。缺失资源、权限拒绝和架构不匹配属于不同故障，安装更多组件未必有帮助。

备份后建立干净配置对照

如果崩溃始于导入或更新配置，先正常退出进程，备份当前用户数据，再用客户端支持的方法建立独立测试环境。不要在不了解数据目录位置时批量删除文件。测试环境先不启用自启动、TUN 和自动更新，只启动界面并添加最小必要配置。若干净环境正常，逐步恢复分组、规则及其他设置；若同样崩溃，则优先检查系统环境和安装资源，而不是继续删节点。

Windows 可从事件查看器的应用程序记录中按时间查找故障模块；macOS 可查看系统提供的崩溃报告；Linux 可从终端启动图形程序观察标准错误，并查询当前用户的系统日志。不同发行版和启动方式的日志位置不相同，不应假定每个系统都有同一文件。下面命令只展示最近一段用户日志，仍可能包含个人路径和其他程序信息，分享前需要筛选。

# Linux：查看当前用户最近十分钟的日志
journalctl --user --since "10 minutes ago" --no-pager

若日志明确提示本地端口占用，先查所属进程，不要随机结束所有网络进程。Windows 可以把监听查询得到的进程编号交给 Get-Process -Id 查看名称，再通过对应程序正常退出。确实需要修改「本地混合监听端口」时，记下新值，同步更新手动配置的浏览器、终端和其他应用。系统代理应重新应用，旧环境变量不会因客户端改端口而自动更新。

Linux 桌面入口无响应，而终端启动正常时，检查启动项的执行路径、工作目录与环境变量。开机自启动失败也可能是网络尚未准备好或权限提示无法显示，不等于程序本身不能运行。相关部署边界可查Linux 桌面安装与自启动。修复后先验证手动启动，再恢复自启动，最后测试重启与正常退出。

如果问题仅发生在切换内核后，恢复原组合，并检查该配置能否被目标内核识别。报告崩溃时提供系统架构、安装形态、触发动作和去除敏感内容的错误片段，不要编造版本结论或仅写「更新后不行」。能稳定复现的最短操作链比完整录屏更易分析；确认修复后再恢复自动任务，避免测试期间被更新或订阅刷新改变条件。

安卓专项：检查 VPN 授权、后台与应用范围

安卓客户端显示已连接，但应用没有流量，先区分 VPN 服务建立成功与远端连接成功。v2rayNG 的连接按钮进入运行态，只说明本地服务已启动，还需要实际请求与日志验证。v2flyNG 作为 V2Fly 内核备选，也应按其支持的配置和菜单检查。不要在两款客户端之间来回导入后就认定节点相同，扩展字段和内核能力可能影响实际连接行为。

先确认系统授权和 VPN 占用

第一次连接时，确认系统的 VPN 授权提示已完成；授权被拒绝、被设备管理策略限制或在后台被中断，都可能导致服务不能建立。安卓通常不能让两个普通 VPN 服务同时接管流量，检查是否还有企业连接、网络过滤或其他代理应用占用。先正常停止它们，再启动待测客户端。不要反复点连接按钮，连续启停会让日志中的服务状态更难判断。

若启用了系统「始终开启的 VPN」或「阻止未通过 VPN 的连接」，客户端一旦停止，直连也可能被系统阻断。这种表现不一定是残留代理。先查看系统 VPN 设置，记录原状态，在获准修改的设备上按需调整后复测。受管理设备应遵守组织策略，不能通过删除管理组件来排查。恢复测试后，把原本需要的保护设置重新启用并检查正常断线行为。

打开客户端日志，执行一次对已知目标的请求，观察是否有对应记录。没有请求记录，先看应用范围与接管入口；出现解析错误，进入 DNS 章节；出现握手错误，回到节点超时章节。不要只看连接时长或图标颜色。用移动数据和无线网络对照时保持同一节点，先确认无线网络的网页登录已完成，否则门户认证会让代理连接与普通网页都表现异常。

处理锁屏断开与应用分流

连接后立即可用、锁屏一段时间就断开，优先检查电池优化和后台限制。不同厂商的菜单名称不相同，应在应用信息中查看电池使用、后台活动和自启动权限，而不是照抄另一个品牌的路径。先只为当前客户端调整必要选项，保持通知服务可见，再测试一次锁屏和唤醒。不要给所有应用放宽限制，这会增加耗电，也不能证明问题属于节点。

只有部分应用失效时，检查应用分流列表采用的是「仅代理所选应用」还是「绕过所选应用」这一类相反语义。一个勾选动作在不同模式下可能意味着纳入或排除。修改后停止并重新建立 VPN，再完全退出目标应用重开，因为已有连接可能保持旧路径。也要核对工作资料中的应用是否属于另一管理范围，不能假定个人空间里的选择会自动覆盖所有应用。

手机开启热点后，连接到热点的设备不一定自动经过手机客户端的 VPN。热点转发、手机本机请求和向局域网开放代理监听是不同路径，不能把手机网页可用当成共享成功的证据。排查手机本机连接时先关闭共享场景；确需向可信设备提供代理时，再单独核对监听地址、认证和网络访问范围。不要为了测试把代理入口暴露到不可信网络。

分开处理订阅、网络切换与安装问题

在 v2rayNG 中检查「订阅分组设置」，确认分组地址与启用状态，再执行「更新订阅」。若当前没有可用连接，更新请求可能需要走直接路径；具体选择应按菜单和日志确认，不能从浏览器可访问就推断客户端通道正常。更新成功后重新选中服务器再连接。订阅地址包含访问权限，不要用公共剪贴板记录工具长期保存，也不要把完整二维码交给他人排错。

无线切到移动数据后中断，先停止并重新连接一次，让服务在新网络上建立连接。若这样能恢复，继续观察系统是否限制后台网络、解析是否沿用旧状态，以及远端地址在两种网络中的可达性。不要一开始就重置全部网络设置。双栈网络和运营商地址转换可能改变连接条件，普通网页测试正常也不能完整覆盖使用 UDP 的应用，应按实际应用做对照。

最后做一轮完整验证：连接后访问目标，锁屏再唤醒，切换网络后重连，正常断开后检查直连。每个步骤都通过，才算覆盖了移动使用场景。若仍异常，整理系统版本、客户端名称、网络类型、是否锁屏相关和去敏后的首条错误，再查常见问题。需要重新建立基础配置时返回快速上手教程，不要把临时测试设置继续当作日常默认值。