V2Ray 故障
排查手册

无法上网：先划分故障范围

客户端显示运行，只能说明界面或内核进入了某种工作状态，不能证明浏览器请求已经到达远端。先暂停 Tun 模式，关闭系统代理，再访问平时能够直接打开的站点。如果此时也失败，应先处理无线网络、网关、登录认证或系统网络设置；不要继续调整节点。若退出客户端后仍无法联网，检查系统是否残留指向本机的代理地址，恢复原设置后再测。

建立一次可重复的基线测试

记录当前客户端、选中服务器、路由模式、系统代理状态和本地监听端口。打开日志窗口后清空旧记录，再访问一个固定的 HTTPS 页面。浏览器缓存可能掩盖真实结果，可使用新的隐私窗口，但仍要确认扩展程序没有单独管理代理。每次只测试一个页面，记住测试时间。不要同时切换节点、开启 Tun、修改 DNS，否则恢复连接后也无法判断是哪项改变起了作用。

在 v2rayN 中，先确认服务器列表里已经选中要使用的条目，且内核启动没有立即报错。桌面版通常可从底部状态区或托盘菜单确认系统代理模式。将本地端口与应用填写的端口逐字比对，不能把远端服务器端口当作本地代理端口。启用混合监听时可以接收不同代理协议，但具体能力应以当前内核与设置为准，不能仅凭端口数字推断。

区分应用未接入与远端不可达

如果日志完全没有本次访问记录，先检查浏览器是否遵循系统代理、是否配置了自己的代理，以及当前路由是否把目标送往直连。若日志出现请求并紧接远端连接错误，重点转向下一章。日志中出现直连记录，不等于节点失效；它可能是绕过局域网或自定义规则的正常结果。验证时应选择明确会进入代理路径的目标，避免用本来就被排除的地址下结论。

可用下面的命令明确指定本地 HTTP 代理，绕开系统代理发现过程。示例中的 10808 只适用于本机实际启用了对应监听的情况；不一致时应按客户端设置修改。Windows 可在终端使用 curl.exe，macOS 与 Linux 使用 curl。目标选用公开示例站点，实际排查也可以替换为自己有权限访问的 HTTPS 地址。

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

若命令提示无法连接本机端口，问题在监听、端口占用或内核启动；若本地连接建立后远端超时，则需要核对服务器参数与链路。收到 HTTP 响应说明这一次请求经过了代理并获得响应，但不代表所有应用、所有目标都正常。浏览器仍失败时，回到扩展、独立代理、浏览器安全 DNS 与证书提示逐项对照。

恢复时保留最小配置

暂时使用一个已确认参数完整的服务器，保留默认路由思路，关闭额外的流量接管工具。不要删除整个配置目录来替代定位；订阅分组、路由和个人设置可能一起丢失。先备份，再逐项恢复更容易找出冲突。涉及证书警告时不要直接关闭证书验证，应检查设备时间、目标域名和证书对应关系，并确认网络中是否存在需要授权的检查代理。

节点超时：分开检查端口与握手

“超时”不是单一故障。它可能发生在服务器域名解析、建立传输连接、加密握手，或代理连接建立后的目标请求阶段。先展开测试结果和日志，确认超时指向哪个地址、发生在哪一步，再决定是否更换服务器。只有一个条目失败时，优先核对该条目的参数；同一网络下所有条目失败时，应先检查本地网络、系统时间以及是否存在其他代理程序接管流量。

不要把 TCPing 当成完整连接验证

TCPing 主要观察 TCP 端口建立连接的情况。它成功，不代表身份认证、TLS、传输路径或目标访问一定成功；对采用不同底层传输的配置，也不能直接套用 TCP 结果。v2rayN 的真连接测速会通过代理访问测试目标，更接近实际请求，但结果仍依赖测试地址是否可达。若测试失败而日常目标可用，应先检查测试地址和测试超时设置，不能仅凭一个结果删除节点。

针对 TCP 服务，可在 Windows 终端用下面的系统命令检查端口。这里的域名和端口只是语法示例，执行前要换成服务器条目里的实际值。结果用于判断端口层，不能据此推导协议参数正确，也不能用第三方网站的端口检测代替本地测试，因为对方所在网络与本机路径不同。

Test-NetConnection -ComputerName example.com -Port 443

按连接参数的关联关系核对

重新打开服务器编辑窗口，依次检查地址、端口、协议和身份字段。再核对传输类型，以及该传输所需的路径、主机名或服务名。WebSocket 的路径与请求主机、gRPC 的服务名、TLS 的服务器名称都可能影响握手；它们不能随意互换。导入完整分享链接通常比手工抄写更可靠，但仍需要确认链接未被聊天软件截断，参数转义也没有被二次处理。

TLS 报错应先检查系统日期和时区，再检查服务器名称是否与服务端配置对应。使用 REALITY 的条目还应核对公钥、短标识、服务器名称和客户端支持情况，不能把另一条服务器的参数拼接进来。若服务提供方更改了参数，应更新该订阅分组并重新选择条目；仅保留旧窗口中的手工副本，可能一直使用已经过期的连接信息。

用对照实验缩小网络范围

保持同一设备、同一条配置不变，只把网络从当前无线连接换为手机热点。若热点可用，原网络的解析、出口或访问策略更值得检查；若两边都失败，再使用同一网络测试另一条已确认可用的配置。对照必须控制变量，不能同时换设备、换节点、换内核。服务器偶发超时也可能来自远端限流或服务不可用，客户端设置无法修复远端停止监听的问题。

避免连续高并发地测试整份列表。大量同时握手可能触发服务器连接限制，也会挤占本地带宽，让健康条目一起显示失败。先单独测试一个，再少量比较。更完整的首次验证方法可参考真连接测速与代理生效验证；排查结论应写成“哪个阶段失败”，而不是笼统记为“节点坏了”。

订阅失败：区分获取与解析

订阅更新包含两个不同过程：客户端先请求订阅地址，再把返回内容解析为服务器条目。请求失败、返回空内容、内容格式不兼容，最终都可能表现为列表没有变化。先查看更新提示与日志，判断是否拿到了有效响应。原有节点仍能使用时，不要先删除分组；保留旧条目可以避免把一次短暂的更新失败变成完全失去可用配置。

确认导入入口与链接类型

v2rayN 使用“订阅分组”管理订阅地址，通常先进入订阅分组设置，添加备注与地址，再从订阅分组菜单更新。v2rayNG 则在侧边菜单的“订阅设置”添加地址，返回主界面后通过更新订阅操作获取内容。不同界面版本的文字位置可能略有变化，但填写地址和执行更新是两个动作，保存地址并不等于已经完成下载。找不到入口时先确认客户端名称。

订阅地址通常是一个 HTTPS 链接，而单条分享链接常带有协议前缀。两者用途不同：把单条分享链接填进订阅地址栏，客户端可能尝试把它当成网络地址请求，当然无法正常更新。复制时检查首尾空格、换行、中文标点以及链接是否完整。二维码也只是承载文本的形式，扫描成功不意味着其中的内容一定适合当前导入入口。

请求失败时检查访问路径

先确认设备时间正确，普通网页能够访问，再检查订阅是否过期、是否被服务端暂停。若出现授权失败或访问被拒绝，应向链接提供方核对权限；反复修改本地端口无法解决权限问题。浏览器能打开订阅地址，只能说明浏览器的访问路径可用，不能证明客户端更新订阅时使用了同一条路径。浏览器扩展和系统代理差异都可能造成两者结果不同。

v2rayN 的订阅更新菜单可能提供通过代理更新与不通过代理更新的选择，实际名称以当前界面为准。如果订阅服务必须通过现有代理才能访问，需要先选中可用服务器并启动连接，再选择相应更新方式。若当前没有可用代理，不要让客户端通过这条失效连接更新；可切换直连或使用服务方允许的其他网络。不要为了测试把私人订阅地址交给陌生转换服务。

返回成功却没有节点的处理顺序

网络请求成功后列表仍为空，先检查服务端返回的是否为登录页、错误说明页或跳转页面。HTTP 成功状态并不保证内容是订阅数据。常见内容包括多条分享链接、编码后的链接集合，或特定客户端专用的结构化配置；并非每一种格式都能互相导入。应在服务端选择明确面向目标客户端的订阅格式，而不是仅凭文件后缀猜测兼容性。

接着检查分组筛选与搜索框。节点可能已经导入，但被隐藏在另一个订阅分组，或被当前关键字过滤。更新后先清空搜索，切换到对应分组，再核对条目数量变化与错误提示。对于仅部分条目导入失败的情况，检查失败条目的协议、传输与内核支持情况；不能因为其他条目成功，就排除格式或参数问题。先修复一个条目，再批量更新。

更新订阅可能覆盖分组内的手工修改。需要长期保留的个人调整，应先记录并确认客户端的更新行为，再决定是否放在独立条目中。迁移设备时也要区分订阅地址、服务器列表与客户端完整备份，它们携带的信息并不相同。入口和格式的进一步说明见V2Ray 订阅链接导入与格式说明，首次导入可回到入门指南按主线操作。

速度慢：拆开吞吐、延迟与负载

网页打开慢、下载速度低和视频缓冲，并不一定来自同一个环节。网页首次打开更容易受解析与握手影响，大文件传输更受持续吞吐影响，交互应用则对往返延迟和丢包敏感。先写清“什么应用、什么目标、什么时间段慢”，再选择合适测试。不要拿某个页面的加载时间与另一条线路的大文件下载速度直接比较，也不要把连接测速结果当成带宽上限。

先排除本地网络与并发竞争

暂停系统更新、同步盘和其他大流量任务，确认没有后台下载占满出口。无线网络信号较弱时，可先靠近接入点或改用有线连接作对照。保持客户端配置不变，测试普通直连目标是否同样缓慢；若所有访问都受影响，优先检查本地链路。设备正在充电限温、处理器高负载或电源管理限制时，也可能降低持续传输能力，尤其是长时间运行后的移动设备。

测量时一次只保留一个任务，使用同一目标、同一文件与大致相同的测试时长。服务器测速往往使用较小请求，只能反映一部分响应特征；并行测试整份列表既消耗流量，也可能让带宽被测试任务本身占满。先测试少量候选，再用真实业务复核。注意应用显示的是每秒字节还是每秒比特，单位不同不能直接横向比较，短时峰值也不等于稳定速度。

区分节点负载与目标站点限制

固定网络和目标，只替换服务器。如果只有一条服务器明显慢，且不同目标都受影响，可能与该服务器负载、带宽或上游线路有关；如果所有服务器只对某个目标慢，应检查目标服务本身的限速、缓存与连接策略。远端服务资源紧张不能通过调高本地线程数量解决。高峰期与低峰期对照有帮助，但应记录相同条件，不要拿不同网络环境下的结果推断拥塞。

真连接测速较快而下载慢并不矛盾：短请求可以快速完成，持续流量却可能受到拥塞和限速影响。反过来，握手稍慢的连接也可能有较好的持续吞吐。需要关注的是目标任务是否改善，而不是让列表数字看起来更小。更细的分层方法可参考节点、线路与本地设置分层排查，先形成对照记录，再决定是否更换线路。

谨慎调整传输、Mux 与路由

Mux 会把多个逻辑请求复用到较少的底层连接，可能减少重复建连开销，但在某些链路与服务组合中，也会让请求共享同一连接的拥塞影响。并不是并发越高越快，更不能假定所有协议都适合相同的复用方式。若近期只改过 Mux，先恢复原值并对照。服务端要求固定传输参数时，客户端不能任意把 WebSocket 改成其他传输来追求速度。

路由也会制造“部分慢”的现象。页面主体、图片、登录接口可能使用不同域名，命中不同出站规则，最终呈现为页面框架打开但资源迟迟不显示。查看慢请求对应的日志和规则，确认它们是否走了预期路径。DNS 缓存与连接复用会影响复测，应在修改规则后重启受影响的连接，必要时关闭应用再打开；不要因为旧连接仍在工作，就误判新规则没有生效。

若速度恢复，要记录真正有效的变化，并撤回无关试验。保留最少的必要调整，往往比积累一串“优化参数”更稳定。长期表现差且已排除本地问题时，向服务提供方提交时间段、目标类型与对照条件，比只提交一句“网速慢”更便于定位。

DNS 问题：检查解析发生在哪里

DNS 负责把域名转换为地址，但代理环境中不只有一个解析位置。系统可以解析，浏览器可以使用独立的安全 DNS，客户端内核也可能按配置进行解析；使用 SOCKS 时，应用还可能选择把域名交给代理端。先确认失败的是服务器域名还是目标域名，以及请求采用哪条路径。把所有解析器同时换一遍会破坏线索，也可能引入新的依赖循环。

从系统解析与客户端日志开始

当日志显示服务器域名无法解析时，连接可能尚未到达远端，此时调整目标网站的路由通常没有用。先在系统终端检查该域名能否得到响应；Windows 可用 nslookup，macOS 与 Linux 也可使用系统可用的解析工具。下面只演示命令形式。系统结果正常而客户端仍失败时，需要检查内核的 DNS 配置与实际使用的上游，不能认为两者必然共享缓存。

nslookup example.com

返回多个地址属于常见情况，不应只因为地址与另一台设备不同就判为异常。内容分发服务会按网络位置和策略返回不同结果。解析成功也只说明得到了地址，不保证该地址可达；解析超时则需要区分上游无响应、请求路径错误与本地网络限制。若错误只发生在网络切换后，先让客户端重新建立连接，并检查旧接口的 DNS 设置是否仍残留。

用 SOCKS 请求比较本地与远端解析

在实际启用了 SOCKS 监听的前提下，下面两条命令可以形成对照。第一条通常由本机解析目标域名，第二条把域名交给代理端处理。端口应替换为本机设置中的值。若只有远端解析方式成功，说明本地目标域名解析值得重点检查，但仍需结合日志排除地址选择差异。该测试不用于证明所有 DNS 流量都经过了同一路径。

curl --socks5 127.0.0.1:10808 --connect-timeout 10 -I https://example.com/
curl --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 -I https://example.com/

浏览器的安全 DNS 可能绕过系统解析器，因此终端正常而浏览器异常时，要检查浏览器自己的设置。测试时可暂时恢复为系统解析并对照，确认后再决定最终方案。只清理浏览器缓存不一定清理系统与内核缓存，反过来也一样。应先结束旧连接，再按出现问题的层次处理缓存，避免把缓存行为误认为路由规则没有生效。

避免引导解析循环与规则误配

加密 DNS 上游使用域名时，建立到它的连接本身可能需要先解析该域名。如果解析又依赖尚未建立的代理，就可能形成循环。应按照内核支持的方式设置引导解析或明确上游连接路径，而不是不断增加同一个不可达的上游。企业内网域名则可能只能由本地网络的解析器回答，把这类域名全部交给公共解析器，可能导致办公服务无法访问。

域名规则和 IP 规则的匹配时机也不同。下面是 Xray 原生路由中的局域网地址直连规则片段，仅用于说明字段关系；它不是一份完整配置，也不应直接粘贴到客户端任意编辑框。direct 必须是实际存在的出站标签，规则通常按顺序匹配，且地理数据文件需要可用。使用图形路由编辑器时，应通过对应字段表达同样含义。

{
  "type": "field",
  "ip": ["geoip:private"],
  "outboundTag": "direct"
}

只在 IPv6 网络或双栈网络中失败时，还要比较返回的地址族与远端的实际可达性。不要直接把关闭 IPv6 当作永久方案，应先确认是地址选择、路由还是上游支持问题。涉及 Tun 的虚拟地址映射时，退出接管后可能需要重建应用连接。最终应同时验证普通域名、内网域名与实际业务，避免只修复一个测试站点却破坏其他访问。

系统代理不生效：确认流量入口

系统代理是一组供应用读取的网络设置，不是强制接管所有流量的开关。部分程序会遵循系统代理，部分程序使用独立设置，另一些程序根本不读取这些设置。因此浏览器可以访问而其他应用失败，并不能直接说明 v2rayN 没有启动。先用明确指定本地代理的请求确认监听可用，再检查目标应用如何获取代理设置，最后才考虑是否需要 Tun。

核对系统设置是否真正写入

在 v2rayN 的系统代理入口选择自动配置系统代理后，打开操作系统网络设置查看地址与端口是否一致。Windows 需要注意当前用户代理、自动配置脚本和部分系统组件采用的设置并非完全相同；macOS 的代理属于具体网络服务，切换无线与有线后要检查当前服务；Linux 桌面环境与终端程序的代理来源也可能不同。不能只看客户端菜单的勾选状态。

如果设置刚写入就被改回，检查另一款代理程序、浏览器扩展、设备管理策略或网络安全工具。排查期间只保留一个负责修改系统代理的程序，避免两个工具来回覆盖。不要通过反复点击开关掩盖冲突。退出客户端前可先清除系统代理，再确认网络恢复；异常关机后若设置残留，也应在系统中手动恢复，不能依赖已经停止的本地监听。

单独检查应用与终端环境

对支持独立代理的应用，填写本机回环地址和实际监听端口，协议选项必须匹配。HTTP 与 SOCKS 不是随便替换的标签；同一个数字端口只有在监听配置支持时才可能同时接收两者。终端工具还可能读取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 或排除变量，旧值会把请求送到已经停用的端口。检查时也要注意变量值可能包含私人信息。

若应用启用了自己的直连排除列表，访问局域网或特定域名时可能不经过代理，这是应用侧行为，不受客户端服务器选择控制。用同一目标分别进行显式代理请求与应用请求，对照日志是否出现连接。应用完全没有请求记录，应检查入口；请求已经出现但走了直连，应检查路由；请求进入代理后失败，再检查远端。这样可以避免把三个问题混在一起。

Tun 模式先解决接管，再解决分流

Tun 通过虚拟网络接口接收流量，适合需要更广范围接管的场景，但它会引入权限、系统路由与 DNS 等额外变量。先关闭其他 VPN 或重叠的虚拟网络工具，再按客户端提示提供必要权限。Windows 的相关操作可能需要管理员权限，其他桌面系统则应按界面提示授权。不要把整个客户端长期以更高权限运行当成所有故障的默认解决办法。

开启 Tun 后若连直连站点都无法打开，先关闭 Tun，确认普通本地代理仍然可用，再检查虚拟接口是否创建、默认路由是否异常、DNS 是否被接管。能接管并不代表规则正确，访问本地打印机或办公网失败时要检查私有地址与内网域名的绕过策略。不要随意删除系统路由，也不要直接照抄他人的整套网络配置；网络接口名称与地址范围往往不同。

排查完成后，应明确保留哪一种接入方式，并恢复为可解释的状态。系统代理与 Tun 可以在某些配置下共同使用，但故障定位阶段最好分别测试。关于“系统代理”“路由”“内核”的含义，可在术语表中对照；首次连接仍建议按入门指南先验证系统代理路径，再扩展到 Tun 场景。

启动与崩溃：分清界面和内核

启动失败至少有三种不同表现：主界面完全打不开、主界面正常但内核立即退出、使用过程中整个客户端关闭。先观察属于哪一种，再找对应证据。界面能打开不代表内核文件可执行，内核退出也不一定会让界面关闭。尽量从图形界面日志、系统事件记录或启动时出现的完整提示获取信息，不要只保留“打不开”的截图，也不要反复重装覆盖现场。

确认安装包与运行环境相符

桌面首选 v2rayN，并从下载页按系统和处理器架构选择入口。Windows 的 Desktop 与 WPF 是不同界面方案，运行依赖与故障表现可能不同，不能把一套文件混入另一套目录。macOS 应区分 Apple Silicon 与 Intel，Linux 应同时考虑处理器架构和软件包格式。安装器与压缩包的使用方式也不同，不要直接在压缩文件浏览窗口中运行程序。

首次启动出现运行环境提示时，按当前包的说明补齐所需组件，不要凭记忆安装一个看似相近的运行时。若系统版本不满足当前软件要求，安装再多组件也不一定有效。Windows 的目录权限、macOS 的系统安全提示、Linux 的图形会话与依赖库，都可能影响主界面。应阅读提示的具体原因，不要直接全局关闭系统保护或给所有文件开放写入权限。

主界面正常而内核退出

先看内核日志里最早出现的错误，后续大量连接失败往往只是连锁结果。配置语法错误、字段不被支持、缺少数据文件、本地端口被占用和文件执行权限不足，处理办法完全不同。若最近更换过内核，检查当前配置所需协议和传输是否受支持。v2rayN 可以管理不同内核，但某个内核支持的字段不代表另一个也支持，不能只修改内核名称而忽略配置兼容性。

本地端口冲突时，先确认是否已有另一份客户端或旧内核仍在运行。可以查看系统进程列表与端口占用信息，再通过正常退出关闭重复实例。不要看到某个进程名称就直接强制结束，其他应用可能也依赖它。改端口虽然可以绕开冲突，但系统代理、浏览器和独立应用里的地址都需要同步更新，否则会出现内核已经恢复、应用仍连接旧端口的假故障。

用备份后的最小配置隔离损坏

如果崩溃紧跟一次配置导入、订阅更新或路由修改，先备份现有数据，再使用独立的测试配置验证。安装形式允许时，可按软件说明使用新的用户配置位置；不要在没有备份的情况下直接删除原目录。测试只保留一个完整条目与基础设置。如果新配置正常，逐项恢复订阅、路由和界面偏好，可以判断是某个数据项损坏还是整体运行环境出了问题。

更新过程中若文件被安全软件隔离，应查看隔离记录，核对下载来源与软件包内容，不要直接对整个下载目录添加宽泛排除。磁盘空间不足、配置目录只读、同步盘文件锁定，也会让保存设置失败或启动时反复恢复旧值。可把数据迁移到符合客户端要求、当前用户有权限的本地位置，再测试写入是否正常。迁移前应完整退出客户端，避免两份实例同时修改数据。

对于偶发崩溃，还应记录是否发生在休眠恢复、网络切换或启用 Tun 后，并查看系统是否因资源压力终止进程。日志级别可在短时复现期间提高，定位后恢复，避免长期生成大量记录。首次运行的准备事项见Windows 与 macOS 初始设置说明。重装只能修复部分文件问题，不能自动解决旧配置和权限冲突。

安卓专项：授权、后台与分应用

Android 侧优先使用 v2rayNG，v2flyNG 可作为使用 V2Fly 内核的备选。两者与桌面系统代理的接入方式不同：常见的 VPN 模式依赖系统 VpnService 建立本地流量通道。状态栏出现 VPN 标记，主要说明系统通道存在，不代表远端服务器已经完成握手。先选定服务器，观察连接日志，再验证实际应用请求，不能仅根据通知栏图标判断连接成功。

连接请求授权与互斥关系

首次启动 VPN 模式时，系统会请求连接授权，需要在确认来源后允许。如果授权窗口没有出现或按钮无法操作，先检查是否有悬浮窗、屏幕滤镜或系统限制影响交互。工作资料、受管理设备和家长控制也可能限制 VPN 权限，应遵循设备管理策略，不能用修改客户端参数绕过。授权被撤回后，需要重新连接并完成系统确认，而不是只更新订阅。

同一用户环境下一般不能同时保持多个此类 VPN 服务。其他 VPN、采用 VPN 接口的防火墙或网络过滤工具，可能在启动时替换当前连接。排查时先正常退出其他占用服务的应用，再连接客户端。若系统启用了始终开启的 VPN 或“阻止不使用 VPN 的连接”，应检查它绑定的是哪个应用；旧应用被卸载或停用后，这类策略可能让设备持续无法联网。

锁屏断连先检查电源管理

前台正常、锁屏后断开，是后台管理线索，不应立即归因于服务器失效。查看客户端的电池使用设置，允许必要的后台运行，并按系统提供的选项取消过严的省电限制。部分设备还需要允许自启动或在最近任务中保留应用，但菜单位置因系统而异。不要承诺某一个开关能解决所有品牌的问题，应通过锁屏一段时间后检查日志与通知是否仍然存在来验证。

如果服务仍在但恢复屏幕后首次请求超时，可能是无线与移动网络切换后旧连接失效。先停止并重新建立连接，比较是否立即恢复，再观察系统是否在待机时关闭无线网络。数据节省、后台移动数据限制与低电量模式也应单独检查。一次只改一项，避免同时关闭所有节电能力；排查目标是给予必要运行条件，而不是让设备长期处于高耗电状态。

分应用代理检查选择语义

在 v2rayNG 设置中启用分应用代理后，要先确认当前列表表达的是“仅所选应用进入代理”，还是启用了绕过所选应用的逻辑。只看勾选标记容易把含义理解反。修改列表后通常需要重新建立 VPN 连接才能完整应用到新会话。系统组件、下载服务或应用内网页的请求来源也可能与表面看到的应用不同，应结合实际测试，不要随意勾选大量系统项目。

若浏览器可用而聊天或媒体应用失败，先在关闭分应用限制的状态下对照，再检查这些应用是否被排除。它们也可能使用不同传输或长连接，不能用浏览器结果证明所有协议都正常。涉及工作资料的应用时，还要注意用户空间边界；个人资料中的客户端不一定能接管另一资料空间的请求。按照系统支持的方式配置，避免把权限边界当成节点问题。

安装、更新与设备迁移

安装失败时先检查架构、可用空间和系统提示。支持相应架构的主流设备通常可选 arm64，无法确认时按下载页说明使用通用入口；不要同时安装来源不明、签名不一致的包覆盖现有应用。出现签名冲突时，先了解当前安装来源并备份订阅与设置，再决定迁移方式。直接卸载可能丢失本地配置，重新安装也不会自动恢复私人订阅地址。

更新或更换 v2rayNG、v2flyNG 后，需要分别检查 VPN 授权、电池策略、选中服务器与分应用列表。不同应用的数据不会因名称相近而自动共享，内核支持范围也要单独确认。更完整的系统设置说明见VpnService 授权、省电白名单与分应用代理。若本章条件全部正常，回到前面的超时和 DNS 章节，继续沿相同的连接层次定位，而不是重复安装。