chapter one
无法上网：先分离本地网络与代理故障
“打开代理后所有网页都无法访问”并不能直接说明节点失效。浏览器请求从应用到目标站点，至少会经过系统代理、本地监听端口、客户端路由、协议连接和 DNS 解析。任何一层中断，表面现象都可能相同。最有效的起点不是重装，而是先确认关闭客户端后网络是否恢复，再判断问题位于代理链路还是基础网络。
建立不经过代理的基准结果
先在客户端中关闭系统代理或停止连接，完全退出设置了独立代理的浏览器，再重新打开一个普通网页。如果此时仍不能访问，优先处理 Wi-Fi、有线网络、路由器登录、网络认证或上游连接问题。可临时切换到另一条已知可用的网络做交叉测试，但不要立刻修改客户端配置。若关闭代理后访问正常、开启后立即失败，故障才属于客户端链路。
桌面端还要区分“关闭客户端窗口”和“退出后台进程”。v2rayN 关闭主窗口后通常仍可留在托盘运行，系统代理也可能继续指向本地端口。应从托盘菜单退出，随后检查系统代理是否恢复为关闭状态。若浏览器设置过独立 HTTP 或 SOCKS 代理，也要暂时改回“使用系统设置”或关闭手动代理，以免旧端口继续接管请求。
确认本地监听端口确实存在
系统代理只负责把请求送到本机地址，例如 127.0.0.1 与某个监听端口；真正接收请求的是客户端内核。若内核没有启动、端口被其他程序占用，系统代理即使显示开启也无法工作。v2rayN 中应先查看运行日志，确认配置已加载且没有“address already in use”一类端口占用提示。Windows 可在终端中检查常见本地端口是否处于监听状态：
netstat -ano | findstr LISTENING
netstat -ano | findstr 10808第二条命令中的端口应替换为客户端设置页显示的实际端口。若没有任何输出，说明当前端口没有进程监听；若输出对应的进程标识不是正在运行的客户端，则可能存在端口冲突。此时可以退出占用程序，或者在 v2rayN 中修改本地监听端口，然后同步更新浏览器手动代理、命令行环境变量及其他依赖旧端口的软件。详细定位方法可继续阅读本地端口冲突排查。
用最小配置排除路由规则干扰
确认监听正常后，将路由模式暂时切到全局，并选择一个已确认可用的节点。全局模式能绕开自定义规则、域名分类和直连出口配置，适合判断问题是否由分流造成。如果全局模式可用而原模式不可用，应恢复原模式后逐条检查规则顺序，尤其是排在前面的 domain、geosite、geoip 与兜底规则。规则通常从上到下匹配，过宽的直连规则会让本应进入代理出口的请求提前结束匹配。
如果全局模式仍不可用，再换同一订阅中的另一个节点。单个节点失败而其他节点正常，说明本地代理链路基本完整，问题集中在节点参数或服务端状态；所有节点都失败，则继续检查系统时间、防火墙、协议参数和 DNS。不要将“延迟测试有数值”等同于网页一定可访问，某些测试只验证 TCP 建连，不能覆盖完整协议握手、传输层和目标请求。
| 基准结果 | 优先检查范围 | 下一步 |
|---|---|---|
| 关闭代理仍无法上网 | 本地网络、路由器、网络认证 | 先恢复基础网络 |
| 开启代理后全部失败 | 监听端口、内核启动、系统代理 | 检查日志与端口 |
| 只有个别节点失败 | 节点状态、协议与传输参数 | 进入节点超时章节 |
| 全局可用、分流失败 | 路由规则顺序与出口 | 缩减自定义规则 |
chapter two
节点超时：按连接层次核对参数
节点超时表示客户端在规定时间内没有得到预期响应，但超时发生的位置可能不同：域名无法解析、目标端口无法建立 TCP 连接、TLS 握手失败、协议身份参数不匹配，都会落到相近的错误提示。排查时应从不依赖节点配置的条件开始，逐步进入协议细节，避免在本地网络尚未确认时反复编辑 UUID、路径或传输方式。
先检查系统时间与目标地址
系统时间偏差会影响 TLS 证书有效期判断，也可能破坏依赖时间窗口的认证流程。Windows、macOS、Android 与 Linux 都应开启自动设置日期、时间和时区，然后重新同步一次。若设备长期休眠、双系统切换或主板电池异常，时间偏差更容易出现。修正时间后应彻底停止内核并重新连接，已有连接不会自动重做全部握手。
随后核对节点地址。地址如果是域名，先确认设备能够解析它；如果是 IP，则排除复制时多出的空格、端口分隔符或协议前缀。节点地址栏通常只填写主机名或 IP，不应把完整订阅链接、网页路径或 https:// 一并放入。端口必须是订阅提供的目标端口，本地 SOCKS 或 HTTP 监听端口不能填到服务器端口位置。
区分网络不通与协议握手失败
桌面系统可用系统工具观察目标主机是否能建立 TCP 连接。Windows PowerShell 可执行以下命令，其中主机与端口替换为节点配置中的值：
Test-NetConnection example.com -Port 443Linux 或 macOS 可使用：
nc -vz example.com 443命令只检查目标端口，不验证 VMess、VLESS、Trojan 或传输层配置。端口测试失败，通常应先检查本地网络、目标地址、端口和服务端可达性；端口测试成功而客户端握手失败，则把注意力转向协议参数。部分网络环境会限制诊断命令，因此单次失败不是最终结论，最好用另一条网络复测。
阅读日志时关注错误发生的阶段。域名解析类错误通常含有 lookup、resolve 或 DNS 相关描述；connection refused 表示目标明确拒绝连接；timeout 表示请求未在时限内返回；certificate、handshake、TLS 类错误则多与域名、证书名称、系统时间或 TLS 参数有关。不要只截取最后一行，前后十余行常包含真正触发失败的地址与出口名称。
逐项比对协议与传输字段
手动录入节点时，应把协议层与传输层分开核对。VMess 常见关键项包括地址、端口、用户标识、加密或安全选项；VLESS 需要核对用户标识、流控、加密项以及对应传输设置；Trojan 重点是密码、TLS 服务名称与传输参数。WebSocket 还要核对路径和 Host，gRPC 要核对服务名，REALITY 配置则需按订阅提供的信息核对服务名称、公钥、短标识与指纹。任意字段看似接近但不完全一致，都可能造成握手失败。
如果节点来自订阅，优先重新更新订阅而不是手动修补字段。订阅提供方调整传输参数后，旧节点名称可能不变，但内部配置已不同。更新前先确认订阅地址本身有效，更新后选择新生成的节点并重启内核。若所有节点同时超时，按节点超时排查顺序检查本地网络与系统时间；只有一个节点失败时，保留其他节点作为对照，不要清空整个订阅组。
chapter three
订阅失败：判断下载、解析还是覆盖问题
订阅更新由三个连续步骤组成：客户端请求订阅地址，取得响应内容，再把响应解析为节点并写入订阅分组。界面只显示“更新失败”时，需要通过日志和更新结果判断失败发生在哪一步。订阅地址无法请求、返回登录页面、内容格式不受支持、分组筛选隐藏节点，最终都可能表现为列表为空。
先确认订阅地址完整且类型正确
复制订阅链接时，应从提供订阅的管理页面完整复制，不要手工省略查询参数。链接尾部的 token、参数或路径通常用于识别订阅，缺失一个字符就可能返回错误页面。粘贴到 v2rayN、v2rayNG 或 v2flyNG 后，检查开头和结尾是否混入中文引号、换行、空格或聊天软件附加的标点。二维码导入后也应查看订阅条目，而不是只确认扫码动作完成。
订阅链接与单节点分享链接用途不同。订阅链接用于定期拉取一组配置，单节点链接通常以协议名称开头，只代表一条配置。将单节点链接放入订阅管理，客户端可能提示格式错误；反过来，把订阅地址当作单节点导入，也不会得到预期结果。多设备迁移时可参考订阅链接、配置导出与二维码迁移对比，根据更新需求选择方式。
通过响应现象定位请求阶段
更新时观察日志中的 HTTP 状态、重定向、超时或解析提示。连接超时说明客户端尚未取得响应，应检查当前网络、订阅域名解析和系统代理路径；出现未授权或禁止访问，通常需要重新取得有效订阅地址；返回成功但解析数量为零，则要怀疑响应内容不是客户端支持的订阅格式，或者返回的是网页文本。订阅地址可能带有有效期或设备规则，失效后应在原服务入口重新生成，不能通过修改本地节点参数修复。
如果普通网络可以直接请求订阅，应先关闭“通过代理更新订阅”做一次测试；如果订阅只能在代理连接可用时取得，则选择一个已经可用的旧节点，再启用代理更新。关键是避免循环依赖：当前没有可用节点，却要求订阅更新必须经过代理，更新自然无法启动。不同客户端对该选项的名称略有差异，应以订阅设置和更新日志为准。
更新成功但看不到节点
日志显示订阅取得成功后，继续检查分组、筛选和覆盖行为。先切换到刚更新的订阅分组，清除名称筛选条件，再查看是否启用了按关键词包含或排除节点的规则。筛选词中的空格、正则表达式或大小写差异，都可能把全部节点隐藏。若客户端支持更新时删除旧配置，更新结果为空还可能导致原列表被清空，因此调整订阅设置前应先导出当前可用配置。
同一个订阅重复添加会产生名称相同但来源不同的分组，用户容易在旧组中寻找新节点。建议保留一个有效条目，给分组设置能识别来源的名称，然后执行一次完整更新。订阅内容发生变化后，当前已选节点可能已经不存在，需从新列表中重新选择并启动连接。只看到列表更新，不代表运行中的内核已切换到新配置。
若导入后节点存在但全部超时，应停止处理订阅本身，转到上一章核对网络与节点参数。若只有部分节点缺失，可对照客户端支持的协议与传输类型。桌面端优先使用 v2rayN，Android 可使用 v2rayNG；需要 v2fly 内核生态时再选择 v2flyNG。客户端获取入口与适用平台以下载中心为准。
| 更新结果 | 可能阶段 | 检查重点 |
|---|---|---|
| 请求超时 | 下载订阅 | 网络、DNS、代理更新选项 |
| 返回未授权 | 访问订阅 | 链接有效性与完整参数 |
| 解析数量为零 | 解析内容 | 响应格式、网页跳转、客户端支持 |
| 成功但列表为空 | 写入与展示 | 分组、筛选、覆盖设置 |
chapter four
速度慢：拆分本地带宽、节点与路由影响
速度慢不能只用一次网页打开时间判断。首次访问包含 DNS、TCP、TLS 与内容加载，浏览器缓存、目标站点负载和本地无线信号都会改变结果。排查需要在相同设备、相同网络和相近时间内建立对照：关闭代理测基础网络，开启代理测多个节点，再比较全局与分流模式。只有控制变量，才能确认瓶颈在本地、节点还是规则。
建立可重复的对照测试
先停止大文件同步、系统更新、云盘上传和其他设备上的高流量任务。关闭代理后，选择固定的测试目标记录下载、上传与响应表现；随后开启代理，使用同一目标重复测试。每种状态至少执行两次，舍弃明显异常的一次。测试期间不要同时切换 Wi-Fi 频段、浏览器、节点和 DNS，否则结果无法比较。
无线网络应特别关注信号质量与干扰。设备靠近路由器后速度明显恢复，说明代理并非主要瓶颈。电脑可改用有线网络做对照，Android 可在 Wi-Fi 与移动网络之间切换一次。移动网络切换后地址与路由都会改变，因此只用来判断当前 Wi-Fi 是否异常，不应把两种网络的绝对速度直接当成节点质量差异。
正确理解延迟测试与实际吞吐
延迟测试反映建立连接或完成特定请求所需时间，不等于持续下载速度。低延迟节点可能带宽有限，高延迟节点也可能在大文件传输时保持稳定。真连接测试可以帮助排除完全不可用的节点，但节点选择仍应结合目标访问、持续传输和稳定性。不要根据单次排序频繁切换，连接反复重建本身也会增加等待。
选择同一订阅中的两到三个节点测试。如果所有节点都比基础网络慢很多，检查客户端是否启用了额外的链式代理、过度复杂的路由或不合适的传输设置；只有某个节点慢，则优先更换节点。若高峰时段变慢而其他时间正常，通常属于路径或服务端负载变化，本地重装客户端不能改变上游容量。
检查分流、并发与应用代理方式
全局模式下所有请求都经过代理，包括本可直连的大文件、系统更新和局域网服务。这会增加节点负担，也可能让局域网访问绕远。切回绕过局域网或合理的分流模式后，确认本地地址、打印机、存储设备和常用直连域名进入正确出口。自定义规则要从具体到宽泛排列，避免一个过宽的代理规则把全部流量提前捕获。规则语法与优先级可查看domain、ip 与 geosite 路由规则说明。
浏览器扩展、下载工具和开发环境可能不使用系统代理，而是配置独立 SOCKS 或 HTTP 端口。端口类型填错时，有些请求会失败重试，表现为速度缓慢。检查应用设置中的协议类型是否与客户端入站一致，SOCKS 代理不要误填到 HTTP 代理栏。命令行工具还可能读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，旧环境变量会覆盖当前系统设置。
若只在开启 DNS 特定模式后变慢，可能是解析服务器响应慢、错误回退或域名被分到不合适的出口。先恢复客户端默认 DNS 配置并重启内核，再观察首个请求与后续请求的差异。首个请求慢、刷新后正常，通常更接近 DNS 或连接建立问题；持续传输速度低，则更接近链路带宽、节点负载或本地网络质量。
chapter five
DNS 问题：从解析结果到路由出口逐层检查
DNS 把域名转换为可连接的地址。出现“IP 可以访问、域名打不开”“部分域名间歇失败”“连接日志提示 lookup error”时，应把 DNS 作为独立环节排查。V2Ray 客户端既可能使用系统解析，也可能通过内核配置指定服务器、查询策略与出口。系统 DNS 和客户端 DNS 同时被修改后，问题容易相互叠加。
先判断是否真是域名解析失败
关闭代理与开启代理分别查询同一个故障域名，观察是否能返回地址。Windows 可使用：
nslookup example.comLinux 或 macOS 可使用：
dig example.com
# 系统未提供 dig 时
nslookup example.com查询有结果并不代表最终连接一定成功，但完全无结果、返回服务器失败或长时间等待，说明解析链路值得继续检查。浏览器可能启用自身的加密 DNS，与系统命令使用不同解析路径，因此还要在浏览器设置中临时恢复为系统默认，再做一次对照。若命令正常而只有一个浏览器失败，优先处理浏览器缓存、扩展与独立 DNS 设置。
清理缓存并恢复单一控制点
域名记录变化后，系统、浏览器和客户端都可能保留旧缓存。Windows 可在管理员终端执行：
ipconfig /flushdns清理后应完全关闭浏览器，并重启客户端内核。Linux 的缓存方式取决于系统服务，可先查看是否使用 systemd-resolved，再执行：
resolvectl status
sudo resolvectl flush-caches不要在同一轮排查中同时修改路由器 DNS、系统 DNS、浏览器 DNS 和客户端 DNS。推荐先把浏览器恢复为跟随系统，把客户端 DNS 恢复默认，只保留系统这一处可观察设置。确认基础解析正常后，再逐项启用客户端的远程解析、域名策略或分流 DNS。这样可以明确是哪一层引入异常。
核对查询策略与出口关系
配置中的 domainStrategy 决定路由规则在何时使用域名解析结果。AsIs 倾向于保留域名参与匹配；其他策略可能在需要时解析为 IP，再应用 IP 规则。它不是单纯的“DNS 开关”，修改后会影响路由命中。若规则依赖 geoip，而域名始终未解析为 IP，对应规则可能不会按预期工作；若过早解析，又可能让域名规则失去优先机会。
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}上例表示保留域名，并让私有地址走直连出口。实际客户端可能通过图形界面生成完整配置，不应直接覆盖客户端管理的配置文件。需要自定义时，先导出当前配置作为参考，只修改相关字段，并在重启内核后查看生成日志。JSON 中逗号、引号或层级错误会导致整个配置加载失败，而不是只让 DNS 部分失效。
还要注意 DNS 查询本身走哪个出口。若指定的解析服务器只能通过某条路径访问，而 DNS 请求被错误送往另一个出口，就会形成“节点已连接但域名无法解析”的现象。先使用客户端默认设置验证，再根据需求绑定 DNS 出口。局域网域名、设备名称和内部服务通常依赖本地解析，全部交给远程 DNS 后可能无法找到本地设备，应为私有域名和私有地址保留直连路径。
| 现象 | 常见原因 | 验证方式 |
|---|---|---|
| 所有域名都失败 | 系统 DNS 不可用或 DNS 出口错误 | 分别测试系统与客户端状态 |
| 只有浏览器失败 | 浏览器独立 DNS、缓存或扩展 | 恢复系统 DNS 并停用扩展 |
| 局域网名称失效 | 本地查询被送往远程解析 | 为私有域名保留本地路径 |
| 首次访问很慢 | 查询超时后回退 | 查看日志中的解析耗时与错误 |
chapter six
系统代理不生效：检查接管范围与端口一致性
客户端显示“系统代理已开启”，只表示操作系统的代理字段被写入，不代表所有应用都会遵循这些字段。浏览器通常跟随系统代理，部分命令行工具、商店应用、游戏和独立网络程序则可能忽略系统设置。排查时要先确认本地代理服务正常，再确认目标应用采用哪种代理机制，最后检查系统代理地址与客户端监听端口是否一致。
验证代理地址和监听端口
在 v2rayN 设置中查看本地 HTTP、SOCKS 或混合入站端口，再打开操作系统代理设置，确认地址为本机回环地址，端口与客户端显示一致。端口修改后，旧的系统代理值不会在所有情况下自动同步；如果系统仍指向旧端口，请先关闭系统代理，再通过客户端菜单重新开启。不要把服务器端口填入系统代理，系统代理连接的是本机客户端，不是远端节点。
Windows 可用 PowerShell 查看当前用户代理配置：
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" |
Select-Object ProxyEnable, ProxyServer, AutoConfigURLProxyEnable、ProxyServer 与自动配置地址可能同时存在。如果以前使用过代理脚本，AutoConfigURL 仍可能影响应用行为。先记录原值，再从系统设置中关闭不再使用的自动配置。不要直接删除不了解的企业或组织策略；受管理设备应先确认网络策略要求。
区分系统代理、TUN 与应用独立代理
系统代理主要影响主动读取操作系统代理配置的应用。TUN 模式通过虚拟网络接口接管更广范围的流量，两者不是同一个开关，也不应在故障不明时同时反复切换。若浏览器可用而某个应用不可用，先查该应用是否支持系统代理；若应用提供 HTTP 或 SOCKS 设置，按客户端入站类型手动填写本机地址与端口。若应用完全不支持代理，再评估是否需要 TUN，而不是把系统代理故障扩大为全局配置改造。
命令行工具通常有独立设置。以临时环境变量为例，HTTP 代理与 SOCKS 代理格式不同：
# HTTP 代理示例
set HTTPS_PROXY=http://127.0.0.1:10809
# PowerShell 当前会话
$env:HTTPS_PROXY="http://127.0.0.1:10809"端口仅为写法示例，必须替换为客户端实际 HTTP 入站端口。环境变量只对当前会话或其子进程生效，永久变量还可能在客户端退出后继续存在。排查完成后应清除不再需要的变量，避免以后出现“系统代理关闭但命令行仍走旧端口”的现象。
处理代理残留与局域网例外
客户端异常退出、系统更新或账户切换后，代理字段可能保留。典型现象是托盘中已没有客户端，但浏览器仍提示代理服务器拒绝连接。此时在系统设置中手动关闭代理，重新启动客户端，确认内核监听后再开启。若重启客户端仍自动写入错误端口，检查配置中的本地端口是否重复、是否有多个 v2rayN 实例同时运行。
局域网访问异常时，检查代理例外和路由规则。回环地址、私有网段及本地域名通常应直连。代理绕过列表只影响遵循系统设置的应用，V2Ray 内核中的路由规则则决定已进入内核的请求从哪个出口离开，两者层级不同。只修改其中一处未必能解决全部应用。先用 IP 访问局域网设备，再用设备名访问；IP 正常而名称失败，应回到 DNS 章节处理本地解析。
当一个浏览器正常、另一个浏览器失败时，比较二者是否都使用系统代理。扩展可能强制固定代理、自动配置脚本或直连模式。创建一个不加载扩展的临时浏览器配置进行测试，比逐个猜测扩展更快。若所有遵循系统代理的应用都失败，则回到端口监听与内核日志；若仅单个应用失败，问题通常位于应用自身配置。
chapter seven
客户端崩溃：保留日志并缩减运行条件
客户端无法启动、打开后立即退出、导入配置时卡死或运行一段时间后崩溃，需要先区分图形界面与内核进程。界面退出不一定代表内核同时停止，内核报错也不一定导致界面崩溃。处理前应记录故障动作、日志路径和系统环境，随后用最小配置启动，逐步恢复订阅、路由和额外功能。
确认是界面退出还是内核失败
先查看托盘和任务管理器。v2rayN 主窗口关闭后可能继续驻留托盘；真正崩溃时，界面进程会消失，系统事件记录中可能留下应用错误。若界面仍在但节点无法连接，应查看客户端运行日志，这更接近内核启动或配置加载失败。若界面完全无法出现，则检查应用日志、系统事件、运行目录权限和依赖环境。
Windows 可打开“事件查看器”，在 Windows 日志的应用程序部分按故障时间寻找对应记录。Linux 桌面版可从终端启动应用，观察标准输出，并查看当前用户服务日志。若配置了用户级自启动，可执行：
systemctl --user status v2rayn
journalctl --user -u v2rayn --since today服务名称应以实际创建的单元为准。Linux 安装与用户级自启动流程可参照v2rayN Linux 桌面版安装教程。macOS 出现无法启动时，应确认应用位于稳定目录、当前账户可读取配置目录，并从系统日志中按启动时间定位错误。
用空白配置验证基础启动
在操作配置文件前先退出客户端及相关内核进程，然后备份配置目录。不要直接删除唯一配置。将现有配置目录改名，让客户端生成一份新的默认配置；如果空白配置可以启动，说明程序主体可运行，故障多半来自旧设置、订阅数据、路由规则或界面状态。随后不要一次性复制整个旧目录，而应按订阅、路由、自定义 DNS、界面设置的顺序逐项恢复。
如果导入某条配置后立即崩溃，可在备份中定位最近修改的订阅或节点。异常长的节点名称、损坏的 JSON、错误的编码和不完整的导入内容都可能触发解析问题。手动编辑 JSON 时应使用支持 UTF-8 的文本编辑器，并先检查基本语法。以下命令可在安装了 Python 的桌面系统中验证 JSON 是否能被解析：
python -m json.tool config.json该命令只检查 JSON 语法，不验证 V2Ray 字段是否符合客户端要求。语法通过后，仍需根据日志核对出站标签、路由引用、DNS 服务器和协议字段。由客户端自动生成的文件可能在退出时被覆盖，因此不要在客户端运行期间直接编辑。
检查权限、占用与资源压力
应用目录或配置目录不可写时，客户端可能无法保存设置、更新订阅或展开运行文件。将应用放在当前用户可正常读写的位置，避免直接在压缩包预览中运行。企业设备、受控目录和同步盘可能附加权限或文件锁，测试时可换到普通用户目录。不要长期用管理员权限掩盖目录问题；先确认哪些文件实际需要写入。
安全软件可能阻止新进程启动、限制本地监听或隔离运行文件。应在系统记录中确认是否存在明确拦截事件，再依据组织策略处理。盲目关闭所有防护无法给出稳定结论，也可能掩盖真正的端口或权限错误。若系统记录没有拦截，继续查看端口占用、配置解析和依赖错误。
节点和订阅数量很大时，启动解析、界面渲染与延迟测试会增加资源占用。先停用自动测试、清理重复订阅并缩小筛选范围；如果只在批量测试时崩溃，应减少并发任务。运行一段时间后内存持续增长，可记录触发操作与资源变化，然后重新取得当前平台客户端进行覆盖安装。覆盖前保留配置备份，安装后先用默认配置启动，再导入必要内容。
chapter eight
移动端专项：Android 后台、VPN 与网络切换
Android 上的 v2rayNG 与 v2flyNG 通常通过系统 VPN 接口接管应用流量。移动端故障除了节点和订阅，还会受到省电策略、后台限制、始终开启 VPN、私人 DNS、Wi-Fi 与移动网络切换的影响。排查顺序仍从基础网络开始，但要额外确认系统是否允许客户端持续在后台运行，以及当前 VPN 接口是否被其他应用占用。
确认系统 VPN 接口与基础网络
先停止客户端连接，确认浏览器在当前 Wi-Fi 或移动网络下可以正常访问普通网页。随后启动 v2rayNG 或 v2flyNG，接受系统 VPN 连接请求，并观察状态栏是否出现 VPN 标识。如果系统提示已有 VPN 正在运行，应先关闭其他使用 VPN 接口的应用。Android 同一用户空间通常只能维持一个主要 VPN 接口，多个应用不能同时接管。
连接按钮显示已启动但状态栏没有 VPN 标识时，检查系统是否撤销了授权，或客户端是否在创建接口时立即报错。进入系统的 VPN 设置，查看“始终开启 VPN”和“阻止未使用 VPN 的连接”等选项。若这些选项绑定了另一应用，当前客户端可能无法正常工作；若绑定当前客户端但节点不可用，阻止直连会表现为所有网络都中断。排查期间可暂时关闭强制项，确认基本连接后再按需求恢复。
处理后台停止与锁屏断连
如果前台使用正常，锁屏数分钟后断开，重点检查电池优化和后台活动限制。将当前客户端加入不受限制或允许后台运行的范围，并允许必要的前台服务通知。不同设备对后台策略命名不同，但判断方法一致：保持屏幕亮起时连接稳定，锁屏后进程消失或 VPN 标识消失，说明系统回收比节点故障更可疑。
部分系统还会按应用限制后台数据。确认客户端可以使用 Wi-Fi、移动数据和后台数据；若只在移动网络下失败，检查是否关闭了该应用的移动数据权限。数据节省模式可能限制后台连接，测试时可暂时允许客户端不受限制。调整后应从最近任务中划掉客户端并重新打开，让新的系统策略作用于新进程。
不建议同时开启多个“自动启动”“后台保护”工具反复修改系统状态。先只调整系统电池与数据权限，观察一段时间。如果问题消失，再逐步恢复其他限制。连接日志中的 EOF、network changed 或接口关闭提示，结合 VPN 标识消失的时间，可以帮助判断是网络切换、系统回收还是远端主动断开。
排查私人 DNS、分应用代理与网络切换
Android 的私人 DNS 位于系统网络设置，与客户端内部 DNS 并非同一层。出现域名无法解析时，可把私人 DNS 暂时设为自动，客户端 DNS 恢复默认，然后重新连接。若恢复正常，再单独启用其中一项。私人 DNS 主机名本身无法解析或无法连接时，系统可能在客户端建立 VPN 前就出现域名问题。
分应用代理允许指定哪些应用进入 VPN。若浏览器正常而目标应用不通，先确认目标应用在包含列表中，或者没有被排除。规则模式切换后，部分已建立连接仍沿用旧网络，需要完全关闭目标应用再打开。系统组件、下载服务与应用主进程有时使用不同进程完成请求，因此只勾选表面应用不一定覆盖全部流量；排查时可暂时改为全部应用进入 VPN，确认后再收紧范围。
Wi-Fi 与移动网络切换会改变底层连接。切换后客户端通常需要重建会话，短时间中断属于连接重建过程；如果长期无法恢复，可手动停止并重新启动连接。只在某个 Wi-Fi 下失败时，检查该网络的认证页面、DNS 和路由；只在移动网络下失败时，检查客户端数据权限、网络类型及目标地址可达性。不要把网络切换后的旧测试结果与新网络混合比较。
| 移动端现象 | 优先检查 | 处理方向 |
|---|---|---|
| 锁屏后断开 | 电池优化、后台限制 | 允许后台与前台服务运行 |
| 无法创建 VPN | 其他 VPN 应用、系统授权 | 释放接口并重新授权 |
| 仅部分应用失败 | 分应用代理列表 | 暂时改为全部应用测试 |
| 切换网络后不恢复 | 旧会话与底层网络变化 | 停止后重新建立连接 |
| 域名失败但连接存在 | 私人 DNS 与客户端 DNS | 恢复单一 DNS 控制点 |
如果完成本章后仍无法判断，可在疑难解答中按问题分类查找短答案。需要重新配置时，从快速上手教程重新走一遍订阅导入、节点选择与连接验证；不要在旧配置上连续叠加未经验证的修改。