V2Ray 故障排查
连接、订阅与客户端设置

无法上网：先划分故障所在链路

“客户端显示连接，但网页打不开”只说明界面进入了运行状态，不等于远端握手成功。完整链路包括应用、系统代理或虚拟网络接口、本地入站、出站配置、远端服务和目标网站。先判断请求停在哪一层，比连续更换配置更有效。记录一个稳定可复现的目标，同时准备一个在当前网络下通常能直接访问的网站作对照。

恢复直连，确认基础网络

桌面端先关闭系统代理，再停止客户端连接；Android 则断开客户端建立的 VPN。确认无线网络已连接、网关可用，必要时完成公共网络的网页认证。若停止代理后对照网站仍打不开，先检查网络登录、设备时间、路由器和运营网络，不要把基础连接问题归因于协议。公共网络认证页通常需要在直连状态下完成。

如果直连恢复正常，再启动客户端，但暂时只保留一种流量接管方式。不要同时运行其他代理、其他 VPN 或会重写网络设置的加速工具。桌面先用本地代理验证，确认出站可用之后再启用需要额外权限的接管模式。这样可以把“远端连接失败”与“流量没有进入客户端”拆开，避免两个问题互相遮挡。

核对选中配置与本地监听

在 v2rayN 中确认当前活动服务器确实是准备测试的条目，而不是只在列表里高亮了另一行。更新订阅后，活动配置可能已经变化；启动前检查地址、端口和传输选项。随后查看日志是否出现本地入站启动成功的记录。若提示端口占用，应定位占用程序，或修改客户端端口并同步应用设置，而不是不断重启。

本地 SOCKS 端口以客户端实际显示为准，下例仅在该端口确实为 10808 时使用。Windows 可在终端调用 curl.exe，macOS 与 Linux 通常使用 curl。命令显式指定代理，可绕开浏览器是否读取系统代理这一变量；目标网站的 HTTP 错误响应与连接失败要分开理解。

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

如果能返回 HTTP 响应头，说明这次请求至少走通了本地代理和远端访问路径，但不代表所有网站都可用。如果提示无法连接本地地址，检查客户端是否启动、监听协议是否匹配。若本地连接成功后才报远端错误，继续查出站日志。不要把 SOCKS 端口填进只接受 HTTP 代理的输入框，两者不能靠端口数字互换。

用路由对照判断请求去向

本地代理测试成功而浏览器失败时，优先查看浏览器代理扩展、独立 DNS 设置和缓存。只有部分网站失败时，短暂切换到代理优先的路由作对照，测试后恢复原方案。这里的“代理优先”指改变出站选择，不代表所有应用自动接入；是否进入客户端仍取决于系统代理、应用设置或虚拟网络接口。

若换路由后恢复，检查原规则是否把目标误送直连、是否命中拦截出站，以及规则集是否加载成功。规则通常按顺序匹配，前面的宽泛规则可能覆盖后面的精细规则。不要直接清空全部规则；先备份，再缩小到一个目标域名验证。企业内网、局域网设备和公共网站的访问需求不同，单一全局模式并不是长期修复方案。

用结果结束本轮排查

最终至少复测直接访问、显式代理访问和日常应用访问三条路径。显式代理可用但应用不可用，转到系统代理章节；所有出站均等待后超时，转到节点超时章节；只有域名相关请求异常，转到DNS 章节。保存能工作的配置副本，撤销测试时添加的临时规则，再逐项恢复需要的功能。

节点超时：分清连接、握手与目标响应

超时是等待结果，不是故障原因。同一个“连接失败”提示可能来自远端端口不可达、TLS 握手没有完成、传输路径错误，也可能是目标网站迟迟不回应。首先打开客户端日志，让失败操作只发生一次，再按同一时间段查找最早的错误。后面连续出现的关闭连接记录通常是连带结果，不应抢先当作根因。

按日志发生阶段判断

出现 dial tcp 与超时组合时，通常应检查地址、远端端口和网络可达性；出现 connection refused，则可能是目标端口没有服务或被主动拒绝。若已经进入 TLS 阶段，先查服务器名称、证书验证和设备时间。日志只给出证据范围，不能单凭一个短语断言远端服务一定离线，还需要网络对照。

若客户端内置测试失败而实际网页能打开，检查测试目标是否自身不可达，以及测试是否覆盖了同一条出站。TCP 建连、代理握手与网页请求测试衡量的对象不同，结果不应该直接混用。反过来，简单连通性测试成功，也不能证明认证、加密或应用层访问已经正常。

逐项核对协议与传输参数

对照可信来源给出的原始配置，核对协议、地址、端口、用户标识、加密选项与传输类型。WebSocket 需要匹配路径以及服务端要求的 Host；gRPC 需要匹配服务名称。TLS 的服务器名称与连接地址可能不同，不能把二者随意合并。地址栏能访问某个站点，也不代表该站点上的代理服务使用了同样的入口。

使用 VLESS 与 REALITY 等组合时，服务端要求的公钥、短标识、服务器名称及流控选项必须与客户端能力和配置对应。不要根据名称相似就把参数复制到另一种传输里，也不要把更换内核当作补齐参数的方法。订阅导入后若某项字段缺失，先确认客户端支持该格式，再向配置提供方核实完整信息。

设备时间错误可能让证书验证失败，也可能影响部分认证流程。先启用系统自动时间并确认时区，再重试。不要为绕过报错长期关闭证书验证；这会改变连接的安全边界，且经常掩盖服务器名称填错的问题。只有在明确的受控测试中才应分析相关选项，恢复使用前应回到正常验证设置。

建立网络与配置交叉对照

保持同一配置，分别在当前网络与另一条可信网络上测试；再保持当前网络，换一条已知可用的配置。前一种对照用于判断本地网络差异，后一种用于判断远端或单条配置差异。测试时记录是否切换了 DNS、是否仍有其他 VPN，以及失败是否只出现在 IPv6 路径，避免把多个变化算成一个结论。

域名同时返回 IPv4 和 IPv6 地址时，一条地址族的路径异常可能造成等待。先从日志确认实际连接了哪个地址，再做临时地址族对照，不要直接在整个系统中永久禁用 IPv6。若服务端地址写成域名，还要确认解析结果符合服务提供方预期；解析到错误地址时，应按 DNS 问题处理，而不是调高所有超时阈值。

处理远端不可用与重试边界

若多条独立网络都只对同一配置失败，且参数与有效期已经核实，应将问题收敛到远端服务或配置权限。提交脱敏后的首条错误、发生时间和网络对照结果，不要发送完整订阅。频繁重试不会修复服务端监听或账户限制，反而可能触发额外限制。等待确认期间切换到已验证的备用配置，并保留原始条目供后续对比。

订阅失败：区分获取、解析与配置使用

订阅更新包含三个独立阶段：从地址获取内容、把内容转换成客户端配置、选择其中一项建立连接。更新成功只说明前两个阶段完成，不保证每条配置都能连接；连接失败也不代表订阅必须重新添加。先确认界面报告的是网络错误、格式错误还是导入后列表为空，再沿对应分支处理，避免删除仍然可用的旧条目。

确认链接类型与访问凭据

HTTP 或 HTTPS 订阅地址通常返回一组可更新配置；vmess://、vless:// 等分享链接通常表达单个节点。把单节点链接填进订阅地址输入框，可能触发获取失败；把订阅文本当作普通网页地址复制，也可能丢失查询参数。先看来源页面说明，再选“订阅分组”或“从剪贴板导入”等对应入口。

检查复制内容是否包含前后空格、换行、聊天软件附加的标点，或被截断的查询字符串。订阅地址中的访问令牌应按密码处理，不要贴进公开检测站，也不要在共享设备上直接打开。若地址曾经泄露，应通过服务提供方重置访问凭据；只从客户端里删除记录并不能撤销别人已经获得的地址。

分享链接与订阅地址的操作差异，可参阅分享链接与订阅的区别。手动导入单个节点只适合临时验证，不会自动获得订阅更新能力。长期使用时应保留清晰的分组名称，区分手动条目与订阅条目，避免下次更新后误以为配置被异常修改。

判断获取失败发生在何处

查看更新日志中的 HTTP 状态与网络错误。认证或权限类响应应先核实账户、地址和有效期；过多请求类响应应停止连续刷新并等待。服务器返回成功状态但内容无法解析时，可能拿到的是登录页、维护页或网络认证页，而不是配置正文。状态码与内容类型要结合判断，不能把所有失败都归到客户端版本。

若直连无法获取订阅，而现有代理仍可用，可以在客户端提供相关选项时尝试通过现有代理更新。反过来，如果代理本身已经失效，强制更新走代理会形成依赖：获取新配置依赖旧配置，而旧配置又需要更新。先确认当前采用的更新路径，必要时切回可用的直连网络或使用已验证的临时连接。

处理内容格式与兼容问题

获取完成但导入失败时，确认订阅提供的是客户端可识别的分享链接集合，而不是另一类客户端专用格式。不要把任意 YAML、网页源码或经过二次包装的文本当成通用订阅。部分分享格式支持的参数随客户端和内核能力而不同，能显示条目名称不代表所有传输字段都已完整保留。

先在单独测试分组中导入一条来自同一来源的分享链接，核对地址、协议及传输设置是否齐全。如果单条可用而整组失败，再检查订阅内容与转换方式；如果同一条导入后就缺字段，应优先确认格式支持。不要使用来历不明的在线转换服务处理私人订阅，转换过程本身会接触地址和访问凭据。

恢复更新后的活动配置

订阅更新后，原来选中的条目可能被重命名、替换或移除。重新确认活动服务器与分组，启动一次连接并观察日志。若更新前可用、更新后失败，比较协议及传输参数，不要只比较显示名称。服务端调整也可能要求新的配置字段，旧客户端未必能完整解析；需要更新客户端时，从下载中心按平台选择安装包，并先阅读迁移说明。

恢复后只保留必要的更新频率，确认手动条目不会被误覆盖，并记录本次使用的获取路径。若同一订阅内只有个别条目异常，进入节点超时章节继续排查，不必反复重建整个分组。问题报告应包含脱敏后的状态码、解析错误和客户端名称，不能包含完整链接、用户标识或未经处理的订阅正文。

速度慢：分别观察解析、建连与传输

网页迟迟不出现、视频中途停顿和大文件下载缓慢，通常不是同一类问题。前者可能消耗在 DNS 与握手，后者更接近持续吞吐、丢包或服务端负载。先选固定目标，在相近时段以同一应用复测，记录是开始等待久，还是连接后持续慢。不要拿不同网站、不同文件和不同网络的结果直接比较。

建立可重复的测试条件

关闭后台大流量任务，确认无线信号和本地网络稳定，再用一个已知可用配置测试。笔记本可以在条件允许时对比有线网络，手机可以对比无线网络与移动数据。每次只改一项，并让测试持续到能复现原症状。客户端显示的连接测试结果不是带宽承诺，也不能单独说明长时间传输是否稳定。

如果只有某个网站慢，而其他目标正常，先考虑目标站点负载、内容分发路径和账户限制。代理出口变化可能让网站选择不同的内容服务器，表现为相同配置下不同站点差异很大。不要因为单个网页缓慢就改动全部本地参数；先通过另一个浏览器或同站点不同资源确认问题范围，再决定是否调整出站。

区分首包慢与持续传输慢

首次打开慢、第二次明显改善时，检查 DNS 缓存、TLS 会话建立与浏览器连接复用。若每次都在解析阶段等待，调路由和传输并发未必有效。若解析迅速但握手反复失败，应回到超时章节核对传输参数。持续传输逐渐下降，则要观察网络丢包、远端负载及本机资源，而不是盲目减少 DNS 超时。

可以使用终端查看一次请求各阶段累计耗时。下例仍要求本地 SOCKS 端口实际为 10808；它只帮助观察请求阶段，不是测速工具。通过代理访问时，部分解析和握手耗时可能包含代理隧道建立，不能把某个字段直接当成远端 DNS 的独立耗时，更不能用单次结果给配置排名。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -o /dev/null -sS -w "connect=%{time_connect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" https://example.com/

该命令适用于通常具备这些终端工具的 macOS 与 Linux 环境。Windows 使用时可调用 curl.exe，并把输出文件改为 NUL。对照必须使用相同目标和相同代理路径。看到首字节等待变长，只能说明需要进一步定位请求处理阶段，不足以证明本机、代理服务或目标网站中的任何一方必然有问题。

检查本机负载与额外处理

打开系统任务管理工具，观察客户端、内核进程以及其他程序的 CPU、内存和磁盘占用。持续高负载可能来自详细日志、过大的规则处理量或其他应用竞争。排查时先把调试日志恢复为常规级别，暂停不必要任务，再复测。不要一次关闭所有系统安全功能；确有拦截证据时，应针对具体程序和提示处理。

多路复用、并发连接与传输参数并不是越大越快。它们会改变连接复用方式，也可能受到服务端实现限制。在不确定来源要求时，先使用配置默认值；要验证某个选项，保留原值并做单变量对照。若更改后出现卡顿或断流，应撤销，而不是继续叠加更多“优化”选项，让后续排查失去基线。

路由、地址族与网络切换

分流错误可能让本可直连的资源绕行，也可能让应走代理的连接不断失败后重试。查看目标实际命中的出站，再修正规则。IPv4 与 IPv6 路径差异、虚拟网络接口的 MTU 不匹配，也可能表现为小请求正常、大响应停滞；只有出现相符证据时才做相关测试，不能从“速度慢”直接跳到修改系统 MTU。

若更换网络后问题消失，保留同一配置继续观察，再检查原网络的无线质量、网关负载和访问限制。若多个网络都只在某一出站上慢，应把目标、时段与脱敏日志交给服务提供方。修复结果应体现为相同任务稳定完成，而不是某个测试数字变好；最后恢复临时关闭的功能，并清理为测试添加的特殊路由。

DNS 问题：核对解析来源与路由配合

DNS 把域名转换为地址，但客户端内并不只有一个解析入口。系统解析器、浏览器加密 DNS、代理协议携带的域名，以及内核为路由匹配发起的解析，可能同时存在。某个网页能打开，不能证明所有解析请求都按预期处理。排查前先写清目标：是修复解析失败、减少错误地址，还是限制某类请求的出口。

确认失败是否真的发生在解析阶段

查看日志是否出现解析超时、空结果或无法使用 DNS 服务器的记录。系统命令能解析域名，只说明系统这条路径可用，不代表代理内核使用同样的解析器。不要直接用 HTTPS 网站的裸 IP 打开结果判断 DNS，因为证书和服务器名称通常仍依赖原域名；裸 IP 访问失败并不能证明地址不可达。

显式 SOCKS 测试中，socks5h 通常把域名交给代理端处理，而普通 SOCKS 使用方式可能先在本地解析。两种方式表现不同，是区分解析路径的线索，但还要结合客户端出站日志。浏览器启用了自己的加密 DNS 时，系统解析测试与网页结果也可能不一致，应先记录该选项状态再做对照。

理解 domainStrategy 的作用边界

路由中的 domainStrategy 控制域名与 IP 规则匹配时是否需要解析。它不是 DNS 出口开关，也不能单独保证解析请求经过代理。以下示例是路由对象的合法片段，只用于理解字段；它没有定义入站、出站和 DNS 服务器，不能作为完整配置直接运行，更不应覆盖图形客户端生成的全部内容。

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

AsIs 通常按已有域名信息匹配，不为 IP 规则主动解析；IPIfNonMatch 在域名规则未匹配时尝试解析并继续匹配；IPOnDemand 则可能在遇到相关 IP 规则时发起解析。具体支持以所用内核为准。上例还依赖可用的地理数据和名为 direct 的出站，字段名称必须与实际配置一致。

因此，遇到 DNS 异常不能只把策略换成一个看似更积极的选项。先检查域名规则是否覆盖了目标、解析器是否可达，以及解析服务器自身连接走哪条出站。增加解析次数可能让等待更明显，也可能改变规则命中结果。每次修改后都要同时验证目标地址与实际出站，而不是仅观察网页是否偶然恢复。

处理解析服务器的依赖循环

使用基于 HTTPS 的 DNS 服务时，其域名也可能需要先解析；如果该解析依赖代理，而代理服务器地址又依赖同一个 DNS，就会形成启动依赖循环。解决思路是明确启动阶段的解析路径与访问规则，按内核支持方式设置引导解析，而不是随意把所有解析器改成同一地址。还要确认网络允许访问所选服务。

境内与境外域名分流解析需要让 DNS 选择、路由规则和目标访问出口保持一致。域名被交给不适合的解析器，可能得到无法使用或路径不理想的地址；解析请求被错误直连，也可能偏离预期。详细字段配合见DNS 分流解析配置，先理解依赖关系，再迁移到当前客户端。

缓存、泄漏检测与最终验证

修改解析设置后，浏览器、操作系统和内核可能仍保留旧缓存。先重建客户端连接并关闭旧网页，再按系统提供的方式刷新缓存；不要把删配置目录当成清缓存。内网域名还可能依赖单位或家庭网络提供的解析器，不能一概交给公共解析服务，否则公共网站恢复后，内网资源反而会失败。

检测页面展示的解析出口只是当前测试样本，不能证明所有应用都遵循相同路径，也不能只凭服务器所在地区判断泄漏。应结合浏览器 DNS 选项、客户端日志和不同应用对照；需要系统检查时可参阅DNS 泄漏检测与配置。修复后分别验证公共域名、内网域名及 IPv6 场景，保留能够解释的解析路径。

系统代理不生效：确认应用是否真正接入

系统代理是一组供应用读取的设置，不是系统所有连接的强制转发器。v2rayN 中启用自动配置，通常意味着把本机代理地址写入系统对应位置；内核是否正常监听、应用是否遵循设置、路由最后选择哪个出站，仍然是不同环节。因此“设置已开启”与“目标流量经过代理”之间，需要一次可观察的请求来确认。

先验证本地代理，再验证系统设置

按无法上网章节的显式代理命令测试。显式指定后成功，说明本地入站和该次出站基本可用；此时不要继续更换节点，应转查系统代理地址、端口及应用行为。检查主机是否为本机回环地址、端口是否与客户端当前设置一致，以及应用输入框要求的是 HTTP 代理还是 SOCKS 代理，协议不能混填。

如果修改过客户端端口，系统设置和应用独立设置也要更新。某些程序在启动时读取代理，改完后需要彻底退出并重新打开；只关闭一个窗口未必结束后台进程。测试时先使用没有独立代理扩展的浏览器配置，排除扩展覆盖。确认成功后，再逐个恢复扩展和单独设置，找出冲突来源。

按桌面平台核对设置来源

Windows 中，用户界面的代理设置不等于所有后台组件共享同一代理来源。浏览器正常而某个服务失败时，应查该程序说明，不要直接把其他代理子系统全局改写。macOS 要确认修改的是当前使用的网络服务；切换连接方式后旧设置可能不再适用。Linux 则要区分桌面设置与终端环境，两者常常独立。

终端中的 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 与 NO_PROXY 可能覆盖或补充应用行为，具体取决于工具实现。尤其要检查排除列表是否包含正在测试的域名。排查时用单次命令显式指定代理，比立即写入全局环境更容易回退；不要在尚未验证的情况下修改所有终端启动文件。

区分系统代理与虚拟网络接口接管

有些应用不遵循系统代理，或使用不在该代理模式覆盖范围内的连接方式。这时才需要研究客户端提供的虚拟网络接口接管，而不是把路由改成全局就认为问题解决。启用相关模式可能需要管理员权限、接口组件和正确路由；它也可能与其他 VPN、虚拟机网络及单位网络策略冲突，应先确认基础代理可用。

接管模式下需要避免代理出站又被送回自身，形成回环。客户端通常会生成相关排除与接口规则，但手工修改网关或路由可能破坏这些关系。若一启用便全部断网，先停用并恢复原连接，再看接口启动与路由日志。不要连续添加静态路由“试试看”，否则退出客户端后仍可能留下独立的网络问题。

局域网共享也是另一种场景。本机回环地址只指向本机，其他设备不能通过自己的回环地址访问这台电脑。确需共享时，要明确监听地址、设备实际地址和防火墙范围；不要为了让连接成功就把代理端口暴露到所有可访问网络。当前任务只是本机排错时，应保持最小监听范围，减少额外变量。

清理残留并恢复可解释状态

客户端异常退出后，系统可能仍指向已经停止的本地端口，表现为软件关闭后网络也不可用。先在系统设置里关闭失效代理，再启动客户端重新应用。若设置立即被改回，检查是否有另一款代理、浏览器扩展或受管理策略在持续写入。对于单位管理设备，应遵循管理要求，不要试图强行覆盖策略。

最终用一个遵循系统代理的应用、一个显式指定代理的命令和一个需要独立配置的程序分别验证。三者结果应能由各自的设置解释，而不是只看托盘图标。恢复流程可参阅v2rayN 首次安装与设置检查；保留当前有效端口记录，避免之后更换配置时把应用接入问题误判成节点失效。

客户端崩溃：分开处理界面、内核与配置

启动即退出、窗口卡死和连接后内核停止，涉及不同进程与不同日志。先确定界面是否仍在、托盘进程是否存在，以及错误是在打开软件、读取配置还是启动连接时发生。不要一上来删除数据目录或反复覆盖安装；这样可能丢失有效配置，也会消除能够说明问题的现场。先备份，再建立最小可复现条件。

核对安装包与运行环境

桌面平台优先选择 v2rayN，并从下载中心核对平台与处理器架构。Windows 桌面版与经典 WPF 版是不同界面入口，不能因为其中一个异常就混用数据文件；macOS 区分 Apple Silicon 与 Intel；Linux 则同时匹配架构和发行版包格式。包能解开不代表系统能够执行其中的程序。

若系统提示缺少运行组件，按当前安装说明补充所需环境，不要从随机弹窗下载所谓修复工具。macOS 出现来源或权限提示时，先核实文件来源并通过系统提供的安全设置处理，不要把全局关闭保护当成常规步骤。Linux 需要结合软件包管理器返回的依赖信息处理，不应把所有启动问题都归为文件权限。

使用解压运行方式时，应完整解压到当前用户可写的固定目录，不要直接在压缩包预览中启动。路径受到同步工具、受控文件夹或其他程序占用时，配置写入可能失败。先换到权限明确的本地目录测试，再检查安全软件的具体记录。存在隔离提示时应核对对象，不要关闭全部防护来绕过一个尚未解释的错误。

区分界面异常与内核退出

界面可操作但连接后立即停止，应先看内核日志中的第一条启动错误。常见方向包括端口被占用、字段不被当前内核支持、引用文件不存在，或地理数据加载失败。日志出现配置解析错误时，切换系统代理没有帮助，因为入站可能根本没有启动。应撤销最近修改的字段，再用此前可用的配置验证。

界面本身无法打开，则检查系统事件记录或客户端启动日志，观察是否与读取某个数据文件、窗口状态或写入目录有关。保留原目录，在不覆盖原数据的前提下使用独立测试目录启动最小环境。新的空环境能运行，只能说明问题更接近旧数据或设置，不能据此直接断言全部历史配置损坏。

安全地缩小配置问题

先关闭客户端并确认后台进程退出，再复制配置、订阅记录和必要日志到受控备份位置。测试环境只导入一条已验证配置，暂不导入复杂自定义路由和外部规则。若最小环境稳定，再分批恢复订阅、路由和其他设置，直到问题重新出现。通过这种逐步恢复，可以锁定触发项，而不是把整套设置重建一遍仍不知道原因。

内核切换要以配置支持为前提。Xray 与 V2Fly 属于不同的内核实现，不能假定所有字段完全通用；某种传输或安全选项在另一内核中可能需要不同处理。切换之后如果立即报不支持字段，应回到原内核，或按该内核的能力重新建立配置。不要把图形界面里的选项名称相同视为完全兼容的证据。

定位资源耗尽与迁移异常

运行一段时间才崩溃时，观察内存、磁盘空间与日志增长，而不是只检查启动参数。磁盘写满可能影响配置保存；持续调试日志也会放大磁盘压力。若与大量导入或特定规则有关，先用缩小后的集合复测，保留能复现问题的最小样本。日志中可能包含地址和用户标识，分享前必须逐项脱敏。

更新后首次出现异常，先保存旧数据备份与迁移错误记录。不同程序状态或数据格式之间不应直接覆盖；需要回退时，要使用与原环境配套的备份，避免旧程序读取已经迁移的数据。修复完成后再验证启动、导入、连接、退出及再次启动这一整轮操作，确认不仅能临时打开，而且能稳定保存设置并恢复使用。

移动端专项：VPN 权限、分应用与后台运行

Android 优先使用 v2rayNG；需要 V2Fly 内核场景时再评估 v2flyNG。两款客户端的配置与内核能力不能仅凭界面相似就视为相同。移动端除了远端连接，还多了系统 VPN 授权、分应用规则、后台限制和网络切换。先在前台保持屏幕点亮完成一次连接，再处理锁屏后断流，能减少同时出现的变量。

安装架构与 VPN 授权

安装失败先核对架构、系统要求、存储空间和现有应用冲突。主流较新的手机通常选择 arm64，不能确认架构时再考虑通用包；不同包并不代表不同账户权限。若系统提示签名冲突，不要直接卸载旧应用，应先导出必要配置并确认备份可用，因为卸载通常会移除应用私有数据。入口统一见Android 下载。

首次建立连接通常需要系统 VPN 授权。若拒绝过提示，回到客户端重新连接并确认授权流程；若设备受工作资料或组织策略管理，可能存在额外限制。系统通常只允许同一用户环境中的一个 VPN 服务保持活动，其他 VPN、部分本地过滤工具或加速工具可能占用这一位置，连接前应明确当前由谁接管。

系统状态栏出现 VPN 标识，只说明服务已建立，不证明远端代理握手成功。应同时查看客户端日志并发起一次网页请求。若开启了始终开启 VPN 或阻止未使用 VPN 的连接，客户端停止后可能无法直连，这是系统策略带来的结果；排查基础网络时需先确认该设置，避免把预期阻断误判为网络彻底故障。

分应用规则与局部失败

只有一个应用无法访问时，先查它是否被分应用规则纳入。不同界面的列表可能表示“仅代理所选”或“绕过所选”，同样的勾选动作含义可能相反。确认当前模式与说明，改动后重建连接，再彻底关闭目标应用重开。不要根据列表里有应用名称就认定它一定走代理，最终仍要结合访问结果和日志判断。

部分应用使用独立 DNS、长连接或特殊传输方式，可能与浏览器表现不同。先比较同一网络下其他应用是否正常，再检查相关出站对 UDP 等流量的支持。不要看到浏览器可用就直接清除目标应用全部数据，登录状态与本地文件可能因此丢失。优先重建连接、检查应用网络权限，再考虑有明确目的的缓存处理。

锁屏断流与后台限制

前台正常、锁屏后失效，优先检查系统电池优化、后台活动权限和厂商省电设置。根据实际需要允许客户端维持后台运行，再锁屏复测。不要一次性放开所有应用的限制；只调整相关客户端，并观察耗电与稳定性。部分设备还提供自动启动或后台任务管理，具体名称不同，但核心是避免 VPN 服务被非预期终止。

区分服务被停止与连接仍在但网络请求失败。前者通常伴随 VPN 标识消失或进程重新启动；后者需要查看重连、DNS 或远端超时日志。系统内存压力也可能回收进程，尤其是同时运行大量应用时。保留发生时段和系统状态，再用较少后台任务复测，比反复更换节点更容易判断是否属于设备资源问题。

网络切换后的恢复与交付信息

无线网络与移动数据切换后，原来的连接和解析缓存可能暂时失效。先等待客户端完成重建，再发起新请求；持续失败时断开并重连一次，查看是否获得新的网络路径。若只在某个无线网络失败，检查网页认证和该网络的访问限制；若只在移动数据失败，再结合地址族、DNS 与服务端可达性对照，不要直接复制桌面端所有设置。

遇到小页面正常、大响应停滞时，可以进一步研究路径与 MTU，但应先保留默认值并记录可复现条件。任意调小参数可能暂时掩盖问题，也可能增加额外开销。跨设备迁移配置时采用手动导入，逐项核对协议支持、路由、端口和平台差异；不要把桌面文件路径、系统代理方式或权限设置原样搬到手机。

最终问题记录应包含客户端名称、设备系统、所用网络、前台或锁屏状态、分应用模式与脱敏首条错误。涉及连接的继续查节点超时，涉及解析的查DNS 问题；需要重新建立操作基线时返回入门指南。修复后完成前台访问、锁屏恢复和网络切换三项验证，再恢复日常使用设置。