v2rayN 故障排查大全

诊断层级 › 应用入口 › 本地监听 › 出站连接

无法上网：先拆开“已连接”状态

主窗口选中服务器、内核运行、系统代理开启，是三个不同状态。节点显示为活动项，只说明后续请求准备使用它，不代表远端握手成功。排查时先区分“所有应用都打不开”“只有浏览器失败”和“只有部分域名失败”。同时记录所用客户端、操作系统、代理模式与首次出现问题的时间，后续比较才有基准。

确认直连与代理的故障边界

先在 v2rayN 托盘菜单选择“系统代理 → 清除系统代理”，并暂时关闭 TUN 模式。访问平时可以直连的网站，确认设备本身有网络。酒店、校园或公共无线网络可能需要先完成认证；若清除代理后仍全部失败，应先处理网络接入、网关或系统 DNS，不要继续改节点参数。测试完成后重新选择“自动配置系统代理”。

接着退出其他代理程序和浏览器代理扩展，只保留 v2rayN。多个程序轮流写入系统代理时，界面状态可能与实际设置不一致。若故障只出现在某个浏览器，使用新建的临时浏览器配置复测，避免已有扩展、缓存和安全策略干扰。不要先删除原有配置，保留能复现问题的环境更有利于找出原因。

检查本地混合监听端口

进入“设置 → 参数设置 → Core:基础设置”，核对“本地混合监听端口”。下列命令按端口为 10808 编写，若实际值不同，必须同步修改。显式指定代理可以绕开系统代理入口，判断客户端本地监听与出站是否可用。命令在 Windows PowerShell 中使用 curl.exe，避免与其他同名命令混淆。

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

返回 HTTP 响应头，说明这一次请求完成了代理链路，不代表全部网站都可用。若立即提示无法连接本地地址，检查内核是否启动、端口是否被占用。若等待后超时，再看远端连接与 DNS。若出现证书错误，先核对系统时间与目标证书，不要直接关闭证书验证。目标站本身异常时，换另一个已知可用的测试地址交叉确认。

用日志区分入口、路由与握手

打开主窗口日志区域，清空旧显示后只发起一次请求，观察相同时间点的信息。完全没有对应记录时，请求可能没有进入客户端，也可能访问日志未启用；结合显式代理测试判断，不能单凭“日志空白”下结论。出现本地接入记录后，继续看目标域名、出站标签和错误类型，确认请求是否被规则送到了预期出口。

临时把“日志等级”调为 info 有助于观察启动与错误上下文；访问日志是否输出还取决于所用内核与日志配置。复现后恢复 warning，避免长期产生大量记录。分享日志前删除订阅地址、服务器地址、用户标识和认证内容，只保留错误文本、目标类型与发生顺序。

按验证结果修复，避免同时重装

显式代理成功而浏览器失败，优先跳到系统代理不生效；本地端口正常但所有远端连接超时，转到节点超时；只有域名访问失败，检查DNS 与路由解析。若只有某个网站失败，先比较该网站在不同节点和直连条件下的结果，不要把目标网站的访问策略误判为整个客户端故障。

修复后回到原来的浏览器与网络环境复测，确认不是仅在临时环境中成功。需要更短的逐项清单，可对照显示已连接却打不开网页排查手记。保留最终生效的修改，撤回诊断期间额外添加的规则，避免下一次故障被临时设置掩盖。

诊断层级 › 服务器地址 › 传输端口 › 协议握手

节点超时：区分 TCP 可达与协议可用

V2Ray 延迟测试并不只有一种含义。Tcping 主要反映到服务器指定端口的连接情况，真连接测试通常借助所选代理配置请求测试地址。前者成功不代表认证、TLS 或传输层配置正确；后者失败也可能是测试地址不可访问。先记下测试方式和完整错误，避免用两个不同指标比较同一个节点。

从地址解析与端口连通开始

打开节点编辑窗口，检查服务器地址是否包含意外空格，端口是否与服务端信息一致。地址栏通常只填写主机名或 IP，不应把完整网页地址连同路径一起粘贴进去。域名不能解析时，应先确认当前网络的解析状态；端口拒绝连接与等待超时含义不同，前者往往表示目标可达但该端口没有接受连接，后者涉及路径、防火墙或远端响应。

在 Windows 可使用 Test-NetConnection 检查服务器端口，但命令中的地址必须换成实际服务器，且结果只能用于连通性判断。不要拿网站的网页端口代替节点端口。若同一节点在移动热点可用、家庭网络不可用，优先比较两条网络的 DNS、IPv6、出口策略与安全软件规则，而不是立即修改协议字段。

检查 TLS、传输与认证字段

TCP 能建立而握手失败时，对照提供方给出的原始参数检查用户标识、密码、传输方式、TLS 开关、服务器名称与路径。WebSocket 的路径和 Host 不等于服务器地址；gRPC 的服务名称也不是任意备注。字段为空是否正确取决于服务端配置，不能照其他节点的设置补齐。修改一个字段后复测一次，失败就恢复原值。

使用 REALITY 的节点还需要匹配服务端给出的公钥、短标识与服务器名称。不要自行生成新值替换订阅中的字段，也不要因为名称看起来像网站就改成服务器 IP。协议参数存在对应关系，单独“优化”一个字段可能破坏整组配置。若订阅导入后字段缺失，应确认客户端与所选内核能识别该配置，再联系提供方核对。

遇到证书有效期、主机名不匹配或握手验证错误，先校准系统日期、时间和时区，再检查证书名称是否与服务器名称对应。公司网络的 HTTPS 检查也可能影响连接。不要把“允许不安全连接”作为通用修复，它会改变验证边界，而且无法解决端口不通、错误密码或传输路径不匹配。

用交叉测试缩小故障范围

固定同一个测试地址，先比较同一订阅中的两个节点，再比较不同网络下的同一个节点。只有一个节点失败，倾向于节点参数或服务端问题；所有节点同时失败，先看本地网络、内核启动和订阅是否过期。若只有某个协议类型失败，检查所选内核支持情况与该类传输的公共字段，避免把整个订阅一并删除。

识别测试方式的边界

真连接测试地址应保持稳定，修改测试地址后不要直接与之前的结果排名。部分站点会限制自动请求、重定向或拒绝特定出口，此时测试失败不等于代理完全不可用。用浏览器完成一次实际网页访问，并查看同一时间的日志，能补上自动测试没有覆盖的验证环节。

如果仍然超时，提交问题时应包含协议类型、传输方式、是否启用 TLS、同节点换网络的结果与脱敏错误。不要把完整分享链接公开。首次选节点与验证顺序见首次连接、真连接测速与代理验证；客户端下载与平台选择统一在下载页完成。

诊断层级 › 订阅请求 › 响应内容 › 节点解析

订阅更新失败：先看下载，再看解析

订阅更新包含两个过程：取回订阅内容，以及把内容解析为客户端认识的节点。网络超时、认证失败和内容格式不兼容，需要不同处理。先打开“订阅分组设置”确认更新的是哪个分组，再查看本次更新日志。不要连续导入同一个地址制造多个重复分组，否则难以区分旧节点与本次更新结果。

检查地址是否完整、权限是否有效

编辑订阅分组，核对地址开头、末尾和查询参数。聊天软件可能把长链接截断，复制时也可能混入换行或中文标点。带认证参数的订阅地址本身就是访问凭据，不要贴到公共网页、在线转换器或截图中。若提供方已经重置地址，旧地址即使能够打开，也未必继续返回有效节点。

订阅过期、流量额度耗尽或账户权限变化，可能使接口返回说明页而不是节点列表。遇到 HTTP 认证错误或禁止访问，应先到提供方账户页面核对状态。不要把认证错误当作客户端缺少某项设置，也不要尝试通过修改地址中的标识绕过权限。只有地址和账户状态明确有效，才进入下一步网络诊断。

区分直连更新与代理更新

v2rayN 的“订阅分组”菜单通常提供更新订阅与通过代理更新的入口，具体文字会随界面变化。直连更新失败但已有节点仍能使用时，可以尝试通过当前可用代理更新。反过来，当前节点已失效时，代理更新也会失败；此时先切换到仍可用的节点，或测试直连更新，不能把更新请求绑在同一个故障出口上反复重试。

如果直连和代理均失败，观察错误发生阶段。域名解析失败优先检查 DNS，连接超时检查网络路径，TLS 错误检查时间和证书环境。浏览器能打开订阅地址不一定证明客户端可以取回内容：浏览器可能使用不同代理、登录状态或安全验证流程。比较时要确认两者走的是同一网络入口。

下载成功却没有节点的处理顺序

更新日志显示请求成功但节点数量没有变化，应检查返回内容是否为网页、错误说明或不兼容格式。服务器返回成功状态码，也可能只返回登录页面。标准分享链接、编码后的节点列表和其他客户端专用配置不是同一种内容；不能仅凭扩展名或地址中出现“订阅”两个字，就认为格式一定适配 v2rayN。

若只有部分节点导入失败，比较失败节点的协议、传输方式与公共字段。老客户端可能无法识别新增参数；此时先备份配置，再从v2rayN 下载入口选择适合系统的安装包更新。不要手动删除无法理解的字段以求导入成功，缺少关键认证或传输参数的节点，即使出现在列表里也无法连接。

节点“没有更新”还可能是筛选造成的。检查当前分组、关键字过滤和列表排序，确认没有把新节点隐藏。查看订阅分组中是否设置了筛选条件，再比较更新前后的备注与服务器地址。备注变化不等于新增服务器，重复节点也不意味着更新失败，应以日志和实际内容为准。

保留旧配置，建立可回退更新流程

更新前导出当前可用配置，并记录分组设置。备份文件包含敏感节点信息，应保存在受控位置。怀疑某个订阅格式有问题时，可先建一个临时分组单独测试，成功后再决定是否替换原分组；失败则删除临时分组即可，不必清空所有服务器。对批量删除、去重和覆盖操作，先确认作用范围。

排查结束后，再考虑是否开启自动更新。若每次启动立即更新都会卡住，先暂时停用自动任务，验证手动更新能稳定完成。自动重试不能解决无效地址或不兼容内容，反而会覆盖最初的错误线索。记录“哪个更新入口、哪个网络、哪个分组”成功，比笼统记录“重启后好了”更容易复用。

诊断层级 › 基线比较 › 出口负载 › 传输路径

速度慢：分开看延迟、吞吐与应用响应

网页打开慢、下载速度低和视频缓冲频繁，不一定是同一种问题。连接延迟主要影响建立请求的等待，吞吐反映持续传输能力，丢包和重传则会让表现忽快忽慢。低延迟节点未必适合大文件传输。先描述慢在首次打开、持续下载还是运行一段时间之后，再选择对应的比较方法。

建立固定条件的测试基线

先暂停云盘同步、系统更新和其他下载，保持测试设备、无线位置、目标地址与时间窗口尽量一致。不要一边批量测速一边判断浏览器速度，多个并发请求会争抢带宽。用同一个实际任务比较两个节点，并重复几次，观察是否持续出现差异；单次峰值可能只是缓存或短时空闲，不能作为长期表现依据。

随后在清除系统代理、关闭 TUN 的条件下测试基础网络。若直连任务也明显变慢，先排查无线信号、路由器负载和宽带占用。能够使用网线时做一次有线对照；移动热点只能作为另一条网络的参考，不代表它与原网络具有同样带宽。基线不稳定时，继续调整代理参数很容易得到相互矛盾的结果。

比较节点负载与目标站策略

同一时间只有某个节点慢，可能与出口负载、线路质量或该出口到目标站的路径有关。切换节点后固定访问同一目标，确认改善是否可以重复。若只有一个下载站慢，其他站点正常，还应考虑目标站限速、登录等级、连接数限制和内容分发策略。换出口能改变目标站路径，但不能保证解除服务端自身的限制。

不要把节点所在地名称直接当作物理线路质量。备注只是标签，实际路径还受提供方部署与网络互联影响。高峰期慢、非高峰期恢复，通常比修改本地监听端口更值得关注。将不同时段的实际任务结果和连接错误记录下来，向提供方描述持续性问题，比提交一个孤立的延迟数字更有帮助。

检查分流、UDP 与 TUN 的影响

先确认慢的请求实际走了哪个出站。下载任务可能被域名规则直连，浏览器也可能通过自己的代理扩展走另一个出口。检查“路由设置”中的当前预设及自定义规则，必要时用一个范围明确的临时规则做对照，验证后立即撤回。不要为了测速把全部私网流量送入代理，这会影响局域网服务与本地设备访问。

部分应用使用 UDP 或 QUIC。若节点不支持相应流量，可能出现等待后回退，表现为开始很慢而后续正常。“开启 UDP”只允许本地相关处理，不会让远端自动具备 UDP 支持。先用普通 HTTPS 请求建立基线，再比较应用自身的协议行为。改变浏览器协议选项时，应记录原值并在测试后恢复。

TUN 模式还涉及虚拟网卡、路由接管和系统权限。只有 TUN 下慢时，先关闭 TUN，使用显式代理完成相同任务。若显式代理正常，重点检查 TUN 路由、DNS 接管及其他虚拟网卡冲突。MTU 不匹配可能影响特定路径，但不要直接照抄网上数值；应先有大包传输异常、小请求正常等证据，再做单变量调整。

减少无效优化，验证长期表现

连接复用、传输参数和内核选择并不是越多越快。服务端不匹配时，额外开启功能可能增加兼容性问题。保留订阅提供的默认传输设置，先处理可见的丢包、出口负载和路由错误。若切换内核后变快，也要确认实际使用的是同一个节点和规则，避免把不同路径的差异归因于内核本身。

最终用日常应用连续观察，而不是只看测速页。记录响应慢发生在哪个阶段、是否伴随连接错误、换节点或换网络能否恢复。涉及路由命中的问题，可进一步阅读geosite 与 geoip 分流配置。性能排查的目标是找到稳定瓶颈，不是通过反复切换设置碰到一次较快结果。

诊断层级 › 系统解析 › 内核 DNS › 路由解析

DNS 问题：确认由哪一层解析域名

同一个域名可能经过系统解析、浏览器安全 DNS、内核 DNS 或代理服务端解析。修改系统 DNS 后没有变化，并不代表设置没有保存，可能是请求根本没有使用它。先记录应用、代理入口和节点类型，再观察日志中的解析错误。只有明确解析发生的位置，才能判断该修改系统设置还是内核配置。

区分域名错误与连接错误

日志中的域名不存在、解析超时和连接目标超时，需要分开处理。解析成功只表示获得地址，不保证地址正确或可以建立连接。也不要把“IP 可以访问、域名不行”作为唯一证据：HTTPS 直接访问 IP 可能因证书名称、服务器名称指示和站点虚拟主机而失败，这类失败不等于 DNS 本身有问题。

可在系统终端运行 nslookup example.com，查看系统解析是否返回结果。但这个工具通常不经过浏览器的安全 DNS，也不自动沿用 v2rayN 的内核 DNS。它适合验证系统层，不适合单独证明代理请求的解析链路。比较时记录所用解析器，避免拿两条不同链路的结果直接下结论。

理解 domainStrategy 的作用范围

routing.domainStrategy 控制路由匹配时如何使用域名与解析后的 IP。AsIs 倾向于保留域名参与规则判断；IPIfNonMatch 会在域名规则未匹配时尝试解析后继续匹配 IP 规则。这个字段不是“所有 DNS 请求都走代理”的总开关，也不会替代应用层或系统层的 DNS 设置。

下面是 Xray/V2Ray 风格的局部配置，用来说明字段关系，不是完整客户端配置。应合并到对应内核的配置体系，并确认已有直连出站标签确实为 direct。v2rayN 的图形路由编辑会生成配置，不宜直接修改运行时临时文件，否则下次启动可能被覆盖。规则库也必须包含所引用的数据。

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

检查解析服务器是否自身可达

配置 DoH 时，需要同时考虑解析服务器地址、证书验证和到服务器的网络路径。DoH 使用加密传输，不自动决定请求走直连还是代理。若解析服务器的域名本身需要解析，而它的访问路径又依赖尚未成功建立的代理，可能形成启动依赖。应结合所用内核支持的引导解析与路由方式设计，不能只更换一个 URL。

先恢复到已知可用的 DNS 设置，确认基础解析，再逐项加入分流。不同内核的 DNS 字段并不完全相同，不要把某个内核的片段直接粘进另一个内核。界面中的“DNS 设置”与“TUN 模式设置”可能分别管理不同环节，应核对当前实际使用的核心和接管范围，再决定配置入口。

如果只在启用 IPv6 后出现部分站点超时，检查本地是否具有可用的 IPv6 路由，而不仅是网卡上是否显示 IPv6 地址。某些网络能返回 IPv6 记录却无法完成连接。可以暂时用受控设置比较仅 IPv4 的结果，但不要把关闭 IPv6 当作所有 DNS 故障的默认方案，修复后应重新评估原有需求。

清理缓存并验证解析路径

完成修改后关闭相关应用再重开，必要时在 Windows 使用 ipconfig /flushdns 清理系统解析缓存。该命令不会同时清除浏览器缓存、内核缓存和服务端缓存。复测前保持同一目标域名，观察错误是否由解析失败变成连接失败；阶段变化说明排查取得进展，不应简单归类为“仍然没用”。

在线 DNS 检测展示的是检测方法能够观察到的解析出口，不是全部流量路径证明。浏览器安全 DNS、缓存和代理模式都会影响结果。详细分流见DNS 与 DoH 设置手记，路径验证见DNS 泄漏检测与防泄漏设置。先确定预期解析出口，再判断检测结果是否偏离预期。

诊断层级 › 应用代理 › 系统入口 › TUN 接管

系统代理不生效：检查应用是否读取设置

“自动配置系统代理”主要把本地代理入口写入操作系统设置，不代表每个应用都会使用该入口。有些应用使用独立代理，有些只读取环境变量，有些直接建立套接字连接。排查重点不是反复点击开启，而是确定目标应用采用哪种入口，以及该入口是否指向当前正在监听的地址与端口。

对照系统设置与实际监听

在 v2rayN 主窗口底部或托盘菜单选择“系统代理 → 自动配置系统代理”，随后打开 Windows“设置 → 网络和 Internet → 代理”，核对地址与端口。地址一般指向本机回环地址，端口必须与“本地混合监听端口”一致。若设置随即被改回，检查其他代理软件、管理工具或组织策略是否正在接管。

可用以下命令查看常用端口的监听情况。没有输出时，先确认实际端口是否不同，再检查内核进程；有输出也不表示监听者必然是 v2rayN，还要通过进程编号识别程序。不要为了排查随意终止系统进程。若端口被其他应用占用，可以改用空闲端口，但系统设置和手动配置的应用也必须同步修改。

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

不需要为了本机应用而开启“允许来自局域网的连接”。该项改变的是监听可达范围，不会让忽略系统代理的程序开始读取设置。只有其他设备确实要连接这台电脑时，才同时评估监听地址、防火墙和访问范围。诊断完成后恢复原先的最小监听范围，避免把临时排错设置长期保留。

排除浏览器与命令行的独立入口

浏览器代理扩展、企业策略或浏览器自身设置，可能覆盖系统代理。先停用扩展并重开浏览器，再与显式代理请求对照。命令行工具则可能读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY 等环境变量，旧终端会保留启动时的环境。修改变量后应开启新终端，不要只在原窗口重复请求。

Windows 的用户代理与 WinHTTP 代理不是完全相同的设置来源。netsh winhttp show proxy 可以查看后者，但它显示直连，并不能证明普通浏览器没有使用用户代理。不要随意运行全局重置命令处理所有应用；先识别目标程序读取哪套设置，再查该程序的官方代理选项，避免影响系统服务或组织配置。

区分 PAC、分流规则与应用绕过

如果使用 PAC，脚本会决定哪些请求发送到代理入口；内核路由则在请求进入客户端后决定使用哪个出站。这是两层不同的分流。网站没有出现在代理日志中，可能在 PAC 阶段已直连，也可能应用没有使用系统代理。为了缩小范围，可临时改用明确的手动本地代理入口测试，再检查内核规则，而不是同时修改两层。

当请求已经进入内核却走错出口，查看“路由设置”的规则顺序。更具体的规则应放在可能提前命中的宽泛规则之前，并保留局域网访问需求。域名匹配还受流量探测和 DNS 策略影响，不应只看最终 IP 猜测命中规则。复测时使用同一网址与同一浏览器，避免重定向产生的其他域名干扰判断。

需要 TUN 时再检查接管条件

目标应用不支持代理入口时，可评估 TUN 模式。启用前先确认普通系统代理链路已经可用，再按系统要求授予虚拟网卡和路由管理权限。TUN 不是远端节点故障的修复开关；如果显式代理都失败，先解决节点连接。启用后检查其他虚拟专网、虚拟机网卡和安全软件是否同时修改路由，避免重复接管。

macOS 与 Linux 的桌面代理入口不同，应用是否遵循桌面设置也存在差异。不要照搬 Windows 的系统路径。需要重新建立基础配置时，回到教程中的系统代理步骤；排查结束后退出多余代理工具，确认重开应用与重启客户端后设置仍然一致。

诊断层级 › 图形界面 › 内核进程 › 运行环境

客户端崩溃：分开处理界面退出与内核退出

窗口打不开、窗口闪退、内核反复重启和连接后退出，是四种不同故障。先记录最后一次正常运行与最近改动：是否更新过客户端、移动过目录、导入过自定义配置，或启用过 TUN。不要立刻删除整个目录，配置、日志和运行文件同时被清空后，往往只剩下无法复现的现象。

先确认系统、架构与安装位置

从下载页按平台和处理器选择安装包。Windows 的桌面版与经典 WPF 版界面体系不同，不能据此认为配置目录可以任意覆盖；macOS 需要区分 Apple Silicon 与 Intel；Linux 需要匹配发行版包格式和处理器架构。选错包时应重新选择，不要通过改文件名或混入其他架构的文件尝试启动。

若使用解压目录运行，应先完整解压，避免在压缩包预览中直接打开。确认目录可写、磁盘有空间，且路径不是权限受限的临时位置。便携配置与安装配置的保存位置可能不同，不要凭经验把备份覆盖到程序目录。先通过客户端导出功能或实际数据目录建立备份，再进行迁移和更新。

用最小配置区分数据问题

备份后，在独立目录或独立用户数据环境中启动相同平台的客户端，不导入旧配置，先观察空配置能否稳定打开。不要让两个实例同时争用同一个端口。若新环境正常，逐项导入订阅、路由和 DNS 设置，每导入一类就重启并检查，能定位是数据损坏还是某个自定义功能触发。

若空配置也闪退，应检查系统错误记录与运行环境提示。Windows 可在事件查看器的应用程序日志中查看故障模块；macOS 可查看系统提供的崩溃报告；Linux 可从终端启动图形程序，观察启动错误。记录错误文本而不是只截最后一个窗口。运行依赖的要求以对应安装包说明为准，不要从不明页面补装随机组件。

内核退出时先读首个错误

图形界面正常但内核无法持续运行，优先查看启动日志中的第一个明确错误。监听端口冲突、配置字段不合法、缺少规则数据和权限不足，都可能导致后续出现一串连接失败。处理首个错误后重新启动，再判断剩余问题。不要把最后出现的“连接被拒绝”当成根因，因为它可能只是内核已经退出的结果。

如果使用自定义配置，确认语法合法、出站标签存在、规则引用的数据可用。不同内核的字段不能混用，切换内核后还应检查相关自定义片段。自动生成的运行配置可能被下次启动重建，修复应回到图形设置或自定义配置源。若错误只在新增路由之后发生，先撤销这一项，而不是一起更换客户端与节点。

更新、回退与安全软件处理

更新后才出现问题，应先保存错误与旧配置，再在隔离环境比较更新前后的行为。不要把旧的全部程序文件覆盖到新目录，混合运行文件可能形成新的兼容性问题。若需要回退，应使用此前保留且来源明确的完整安装包，并单独保存当前数据，避免新旧配置格式互相覆盖。

安全软件拦截时，先查看具体记录、文件路径与触发时间，再判断是否与启动失败对应。不要把关闭全部防护作为常规步骤，也不要对整个磁盘添加排除。工作或学校设备受管理策略限制时，应由管理员确认允许范围。修复后清除遗留系统代理、重开客户端并完成一次真实连接，确认图形界面与内核都能稳定运行。

诊断层级 › VPN 授权 › 应用分流 › 后台与网络切换

安卓专项：连接权限、分应用与后台断连

Android 优先使用 v2rayNG，v2flyNG 作为采用 V2Fly 内核的备选。桌面的“系统代理”思路不能直接照搬到安卓：客户端通常通过系统 VPN 接口接管流量，再由配置决定出站。VPN 标志出现只说明系统通道已经建立，远端节点仍可能认证失败或超时，必须结合实际访问与日志判断。

首次启动与 VPN 授权

导入节点后选中目标服务器，启动连接时确认系统弹出的 VPN 授权。若授权窗口没有出现或被其他界面遮挡，先回到前台重试，并检查是否存在另一个正在运行的 VPN 应用。Android 通常由一个应用占用当前用户的 VPN 通道，两个客户端来回启动可能互相替换，造成看似随机的断连。

从Android 下载入口选择与设备架构匹配的安装包。多数较新的设备使用 arm64，架构不确定时可查看系统信息或选择通用包。若安装失败，先区分系统版本限制、安装权限、签名冲突和空间不足，不要只重复下载。覆盖安装遇到签名冲突时，先导出配置，再评估卸载重装对数据的影响。

检查分应用代理与路由模式

浏览器可以访问而某个应用不行时，先查看客户端设置中的分应用代理。确认当前使用的是“仅代理选中应用”还是“绕过选中应用”的逻辑，二者方向相反。系统应用、工作资料中的应用与普通用户应用也可能处于不同环境，不应仅凭列表中名字相似就认为已经包含目标应用。修改后重新启动连接再测试。

如果所有应用都失败，先暂时取消额外的分应用筛选，保留一个已知可用节点和基础路由进行验证。不要同时调整远程 DNS、流量探测、IPv6 与分流列表。某个应用使用 UDP 时，还要确认节点与内核的实际支持情况；VPN 通道能接管流量，不等于远端一定能够转发该应用所需的全部协议。

部分应用自行缓存连接或解析结果，修改分流后可能继续沿用旧连接。停止目标应用再重新打开，必要时先断开客户端后重连。直接清除应用数据会影响登录和本地资料，不应作为第一步。先用浏览器和另一个普通应用交叉验证，再决定问题是否只存在于单个应用内部。

屏幕关闭后断连与网络切换

亮屏可用、锁屏一段时间后失效，优先查看系统电池优化、后台运行限制和厂商任务管理设置。按设备系统提供的路径允许客户端持续运行，并保留连接通知。不要一次性放开所有应用的后台权限，只针对实际需要维持通道的客户端设置。系统更新后这些权限可能变化，复发时应重新核对。

系统“始终开启 VPN”与“阻止未使用 VPN 的连接”会改变断线时的联网表现。后者开启后，客户端退出或重连期间可能暂时完全断网，这是该设置的预期边界。先明确是否需要这种行为；排查基础网络时，可以临时关闭对应限制，但应记录原值，测试结束后按实际需求恢复。

从 Wi-Fi 切到移动网络后失效，先断开再重新连接，观察能否恢复。网络切换会改变地址、DNS 和既有连接状态，原连接未必能够继续使用。若只在某种网络失败，用同一节点分别测试，并检查该网络是否需要网页认证、是否具有异常 IPv6 路径。不要把所有切网失败都归因于后台被清理。

移动端 DNS 与故障证据

Android 的私人 DNS、浏览器安全 DNS和客户端 DNS 设置可能共同影响解析。发现域名异常时先记录这些设置，而不是同时关闭全部选项。日志显示解析超时，应结合当前网络和客户端的远程 DNS 路径检查；只有特定浏览器异常，则先比较浏览器自己的解析行为。详细原理可回到DNS 章节逐层核对。

向他人描述安卓故障时，记录设备系统、客户端名称、网络类型、锁屏与切网条件，以及 VPN 是否仍保持。附上脱敏后的首次错误，并说明同节点在桌面 v2rayN 上是否可用。跨设备比较只用于缩小范围，不代表配置一定完全相同。恢复后再进行一次锁屏、唤醒和网络切换测试，确认修复覆盖真正触发故障的场景。