V2Ray 全平台
安装配置手册

准备工作与配置边界

先区分客户端、内核与服务配置

v2rayN 是桌面图形客户端，负责管理订阅、生成配置并启动内核；v2rayNG 与 v2flyNG 用于 Android。内核负责实际连接、协议处理和路由执行。Project V 是相关开源生态的起点，V2Fly 与 Xray 属于不同的内核发展路线。客户端安装完成，并不意味着已经具备可连接的服务配置；仍需准备有使用授权的订阅地址或单条分享链接。

桌面端优先选择 v2rayN。安卓端通常从 v2rayNG 开始；需要 V2Fly 配置兼容时再考虑 v2flyNG。选择不是按名称判断功能多少，而是核对配置需要的协议、传输与安全设置是否被当前内核支持。例如 REALITY 配置需要相应支持，不能仅将内核名称改掉就认定兼容。具体差异可阅读Xray 与 V2Fly 内核选择对照。

下载前记录系统与网络条件

进入获取客户端，先选系统，再选处理器架构与包类型。系统架构和应用架构要分别确认：在兼容层里能运行某个程序，不代表它是当前设备最合适的安装包。桌面设备可在系统信息中查看处理器；安卓设备可查看设备规格，无法确认时选择下载页提供的通用包。不要凭设备外观或购买年份推断架构。

开始前记录现有代理、VPN、虚拟网卡和安全软件状态。若同时启用多个接管网络的工具，后续很难判断流量走向。先关闭其他代理客户端，保留原始网络环境，确认普通网络能够工作，并让系统自动同步时间。加密连接依赖正确时间，时钟偏差可能导致证书验证失败；这类错误不应通过关闭验证来掩盖。

整理订阅与备份

订阅地址是获取配置的入口，分享链接是某一条配置的描述，两者不能放错位置。订阅常以 HTTPS 地址出现，返回内容可能是编码后的配置集合；分享链接则带有协议前缀。客户端通常提供不同导入入口。复制地址时保留查询参数，检查首尾空格和换行，不将浏览器登录页地址当成订阅地址。格式细节见订阅链接与分享格式说明。

在大幅修改路由、DNS 或内核前，使用客户端支持的导出或备份功能保存现状。配置可能包含订阅参数、用户标识和服务地址，备份应放在个人可控的位置。请求协助时只保留错误类型、时间和必要的配置结构，遮盖身份字段。不要把完整订阅地址贴进公开讨论，也不要将含凭据的配置复制到在线转换页面。

建立可回退的验证顺序

首次配置按安装、导入、选中配置、启动内核、启用流量入口、验证访问的顺序推进。一次只改一类设置，确认结果后再处理下一项。先用系统代理验证基础连接，再决定是否需要 TUN；先用默认路由检查通信，再增加自定义分流。这样每个变化都有明确起点，出现异常时能够回到上一个可用状态，而不是同时猜测多个参数。

下文的本地端口数字只用于解释配置关系，不代表客户端固定默认值。应在当前设置页查到实际监听端口，再填写到应用中。订阅内容也不会自动决定所有本地设置：系统代理开关、权限、路由和 DNS 仍需单独确认。使用前了解所在网络与设备的管理要求，在个人获准使用的环境中完成配置。

Windows：v2rayN 安装与订阅

选择桌面版或经典 WPF 版

在Windows 下载区选择 v2rayN。桌面版采用跨平台界面，经典 WPF 版延续 Windows 界面路线。两者是界面与应用组织方式的选择，不是服务配置的两种协议。初次安装选择一种即可；若进行迁移，先备份原配置，再核对新界面的导入入口、监听端口与代理模式，不建议让两套程序同时接管系统代理。

运行安装程序时按提示选择可写入的位置。若使用解压形式，完整保留目录内容，不要只把主程序移到桌面。客户端需要访问配套文件和配置目录，缺少内核或文件被安全软件隔离时，可能出现界面能打开、连接却无法启动的情况。遇到运行环境提示，先阅读报错所要求的组件，再按系统与架构处理，避免反复安装不匹配的组件。

建立订阅分组并更新

打开 v2rayN 的订阅分组设置，新建分组，填写便于辨认的备注，将完整订阅链接粘贴到地址栏，确认分组已启用并保存。随后执行更新订阅。首次还没有可用代理时，先尝试“不通过代理”更新；已有可用配置且当前网络无法直接访问订阅来源时，再尝试“通过代理”更新。更新成功后检查分组是否出现配置，避免停留在空分组。

自动更新间隔只控制重新获取订阅的频率，不负责保持连接，也不改变服务有效期。过于频繁的更新可能触发来源的请求限制。过滤条件会影响显示结果，初次导入建议留空，确认完整内容能正常出现后再设置。若更新显示成功但列表为空，先核对当前分组和过滤条件，再确认来源返回的是订阅内容，而不是需要登录的网页。

选择配置与系统代理

在列表中选择需要使用的配置，设为活动项，确认内核正常启动。然后在系统代理菜单中选择设置系统代理。代理端口必须与客户端本地监听一致；如果此前其他工具修改过系统代理，先清除旧设置，再由 v2rayN 重新设置。浏览器通常会读取系统代理，但游戏、命令行和部分桌面软件未必读取，因此浏览器可用不能代表所有程序都已被接管。

路由模式与系统代理是两个层面。系统代理决定应用是否把请求送到客户端，路由决定客户端收到请求后选择直连还是代理。初次可选择绕过局域网的路由，避免本地设备访问被送往远端。之后根据使用目标调整。若只想测试某个应用，可在支持手动代理的应用中填写本地地址与实际端口，不必马上启用全局接管。

权限、休眠与退出后的恢复

普通系统代理通常不需要以管理员身份运行；TUN 涉及虚拟网卡和路由变更，按当前客户端提示提供必要权限。启用后若访问局域网设备异常，应先检查绕过局域网规则与路由表，而不是关闭防火墙。安全软件阻止内核启动时，检查拦截记录和文件位置，确认原因后再处理相关许可，不做全盘放行。

休眠恢复或从有线切换到无线网络后，原来的网络接口、网关和解析环境可能已经变化。先停用 TUN，再重新启用；仍有问题时退出客户端后重新打开。若程序异常退出导致浏览器断网，在 Windows 的代理设置中检查是否残留手动代理，移除不可达的本地地址，然后验证原始网络。网络恢复后再启动客户端，避免把残留代理误认为服务故障。

最后做两类验证：访问一项需要代理的目标，确认代理出口路径可用；访问局域网设备或预期直连的目标，确认分流没有破坏本地通信。查看同一时间段的日志，区分内核启动、域名解析与连接错误。测速只是辅助观察，不能替代真实应用访问；如果浏览器正常而特定程序异常，优先调查该程序的代理支持，再转到本页的 TUN 章节。

macOS：芯片选择与网络权限

确认芯片与安装位置

在系统的“关于本机”中确认芯片类型，再前往macOS 下载区选择 v2rayN。Apple Silicon 使用对应架构包，Intel 使用对应的 x64 包。即使兼容机制允许运行另一架构的程序，也应优先采用原生匹配的包，以减少内核启动和权限处理中的额外变量。不要把架构不匹配导致的启动问题当作订阅或网络故障。

打开磁盘映像后，将应用放到应用程序目录，再从固定位置启动。不要长期在挂载的安装映像里运行，也不要把包内部文件单独拖出来。固定路径有助于权限记录与升级管理保持一致。遇到系统安全提示时，先确认下载来源与当前文件，再按系统提供的安全设置流程处理；不使用关闭整机安全保护的方式绕过所有检查。

导入订阅并建立基础连接

打开 v2rayN，进入订阅分组设置，填写备注与完整地址，启用分组并保存。更新后选择一条配置作为活动项。桌面各平台的配置思路一致，但菜单位置和快捷操作可能不同，应按动作名称查找，不照搬其他系统的鼠标路径。更新失败时先检查来源能否直接访问，再决定是否借助已经可用的代理更新，避免依赖尚未建立的连接。

首次启动先观察内核是否成功运行，再启用系统代理。若日志显示程序不可执行、权限不足或缺少文件，应先处理本地启动问题。只有内核已经监听本地端口，系统代理才有实际接收请求的对象。将代理设置指向未启动的端口，会让应用持续等待或直接失败，外观上容易被误判为远端连接问题。

理解按网络服务保存的代理

macOS 的代理设置与网络服务相关。无线、有线及其他网络服务可能分别保存配置，因此切换网络后需要重新确认代理状态。查看系统网络设置中的当前服务，核对 HTTP、HTTPS 或 SOCKS 代理所使用的本地地址与端口。若客户端提示设置成功而浏览器未使用代理，先确认检查的是当前活动网络服务，而不是未连接的服务。

某些应用使用自己的网络栈或独立代理设置，不完全跟随系统代理。对这类程序，先查找应用内是否支持手动代理，按照客户端当前监听协议填写，不能把 SOCKS 端口填到仅支持 HTTP 代理的输入框。系统代理只影响主动遵循设置的应用；若确实需要接管其他流量，再考虑 TUN，而不是不断切换系统代理模式试图覆盖所有程序。

TUN 权限与其他网络工具

启用 TUN 可能需要提升权限或安装客户端要求的辅助组件，具体流程由当前构建决定。阅读提示后完成授权，再观察虚拟接口是否建立。不要套用其他系统的驱动安装方法，也不要为解决权限提示随意修改应用包内部权限。权限已允许但仍启动失败时，查看首个错误消息，区分辅助组件失败、端口占用和虚拟接口创建失败。

工作设备上可能已有网络过滤、企业 VPN 或设备管理策略。它们与 TUN 同时存在时，路由及 DNS 的归属会更复杂。若设备受管理，先遵循管理员要求；个人设备排查时可暂时停用其他网络接管工具，保留一套配置验证。不要同时调整多个 VPN 的优先级，因为结果即使恢复，也无法确认到底是哪一个变化起作用。

从睡眠恢复后，先检查当前网络服务是否已获得正常地址，再确认代理状态。若只在切换网络后失败，停用接管功能，在原始网络上完成一次访问测试，再重新开启。程序退出后仍无法联网，则检查活动服务是否保留了本地代理。迁移到新机器时可以导入订阅与路由，但应重新确认本地端口、系统授权及芯片匹配，不能把另一台机器的网络服务状态当作可直接复用的配置。

Linux：包类型、桌面代理与权限

按发行版与架构安装 v2rayN

前往Linux 下载区获取 v2rayN，依据发行版选择 deb 或 rpm，并确认是 x64 还是 arm64。包类型取决于系统的包管理体系，处理器架构则取决于设备，两项必须同时匹配。桌面界面能否正常显示还与当前图形环境和系统依赖有关，不能仅看到包扩展名正确就认定所有运行条件都已满足。

优先使用图形软件安装器打开下载文件，阅读依赖和安装结果，再从应用菜单启动。安装失败时先查看提示是依赖缺失、架构不符还是文件不可读，避免强制跳过依赖。若系统软件源尚未配置好，应先恢复包管理器的正常工作。卸载旧包、安装新包前保存客户端设置，但不要手动清空系统网络配置来处理普通的软件安装错误。

导入订阅并检查可写目录

以普通用户启动客户端，进入订阅分组设置，添加地址后更新，再选择活动配置。客户端配置目录应由当前用户可读写；曾用高权限启动图形程序，可能留下归属不匹配的文件，表现为设置无法保存或每次启动都恢复旧内容。遇到这种情况应核对具体目录及所有者，而不是递归修改整个个人目录或系统目录的权限。

内核无法启动时，日志通常比界面提示更具体。先确认配套内核文件存在且能执行，再看是否被安全策略限制，最后检查监听端口是否被占用。软件安装成功与内核运行成功是不同阶段。不要在看见连接失败后立即修改服务端地址；如果本地内核根本没有运行，改变远端配置不会修复本地执行权限问题。

桌面设置与应用设置不是同一层

Linux 没有对所有桌面环境都一致生效的系统代理接口。桌面网络设置可能被浏览器读取，却不一定被终端、容器或后台服务读取。启用 v2rayN 的系统代理后，应在实际使用的应用中验证。对于支持手动配置的程序，可以填写回环地址与客户端实际端口，并明确使用 HTTP 还是 SOCKS，而不是假设所有程序自动共享桌面设置。

终端里的代理环境变量通常只作用于当前进程及其子进程，不会替代桌面设置，也不会自动影响已经运行的程序。下面只演示临时变量的形式：先将端口改为客户端实际 HTTP 代理端口，再在同一终端运行需要代理且支持这些变量的工具。结束测试后删除变量。使用 SOCKS 时，还要确认工具是否支持把域名解析交给代理端。

export http_proxy="http://127.0.0.1:10809"
export https_proxy="http://127.0.0.1:10809"
export no_proxy="localhost,127.0.0.1,::1"

# 测试结束后，移除当前终端的临时设置
unset http_proxy https_proxy no_proxy

TUN、解析服务与容器边界

TUN 需要创建虚拟网络接口并调整路由，可能涉及相应网络管理权限。按当前客户端的授权流程操作，不将图形客户端长期以最高权限运行作为默认办法。启用后先检查基础网络，再验证预期代理目标。若进程能运行但虚拟接口未建立，应先调查权限；若接口存在但全部访问失败，则转向路由与 DNS，而不是反复重装应用。

不同发行版可能由不同组件管理 DNS，直接改写解析文件可能被网络服务立即覆盖。应通过客户端或当前网络管理工具配置，并记录原状态。容器、虚拟机和独立网络命名空间也未必继承宿主的代理与路由；宿主浏览器可用不能证明容器已走代理。配置这些环境时先明确其网关、解析器以及到宿主监听地址的可达性。

升级前保留可用配置并退出客户端，升级后重新核对内核路径、监听端口及权限提示。若桌面登录后启动失败而手动启动正常，检查是否启动得早于网络就绪，或启动环境与交互会话不同。按阶段验证安装、配置保存、内核启动、应用接入和目标访问，可以把 Linux 的环境差异拆成明确问题，减少无目的地修改系统设置。

Android：v2rayNG 与 v2flyNG 配置

选择内核与安装包

打开Android 下载区，首推 v2rayNG，使用 Xray 内核；v2flyNG 是 V2Fly 内核备选。确认服务配置要求后再选择。主流 arm64 设备可用对应包，无法确认架构时可选择通用包。不要仅依据系统版本判断处理器架构，也不要把两个客户端轮流安装当作协议兼容性的验证方法，先核对配置字段更有效。

通过系统安装器安装，若提示需要允许安装来源，只为当前使用的文件管理器或浏览器开启必要权限，安装后可按个人需求收回。安装器提示包不兼容时，核对架构、系统要求与已有应用；提示签名冲突时，先备份原应用配置，再判断是否需要更换安装来源。直接卸载可能删除订阅和规则，不应作为每次更新失败的首选步骤。

订阅管理与单条链接导入

在 v2rayNG 中打开订阅分组相关入口，新增分组，填入备注和完整订阅地址，保存后执行更新。若拿到的是单条分享链接，使用从剪贴板导入或扫描对应信息的入口，而不是将分享串填进订阅地址栏。v2flyNG 的界面路径可能不同，但同样要分清获取配置集合与导入单条配置。菜单文案变化时，依据入口功能判断。

更新后选择需要使用的配置，再点击连接按钮。若列表没有内容，核对分组是否启用、地址是否完整及过滤条件。安卓浏览器有时会复制分享页面标题或省略部分地址，建议检查完整文本。订阅带有用户相关参数，应仅保存在个人设备中；换机时使用受控的备份方法，不通过公开消息或截图传递完整地址。

系统 VPN 授权与应用范围

首次连接通常会出现系统 VPN 授权提示，这是客户端利用系统接口接管流量所需的许可。批准后再观察连接状态与日志。安卓端的这种接管方式不等于桌面上的“设置系统代理”；它可以让选定应用的流量进入客户端，再由路由选择直连或代理。状态栏出现连接标识只说明接口已建立，并不能证明每条远端配置都能访问。

按应用代理与路由分流也不是同一概念。按应用列表决定哪些应用进入接管范围，路由规则决定进入范围的请求走哪个出口。若采用仅代理选定应用的方式，漏选目标应用就不会进入代理；若采用绕过选定应用的方式，被勾选的对象含义相反。修改前先读清当前模式，再用一个目标应用测试，避免在列表很长时误判选择结果。

后台限制、切网与冲突

部分系统会限制后台运行，锁屏后断线可能与省电策略有关。先确认客户端是否被系统结束，再在电池设置中为其提供符合设备策略的后台运行许可。允许后台活动不代表所有连接永久保持；无线切换到移动网络时，旧连接仍可能需要重新建立。如果问题只出现在锁屏或切网后，应优先观察进程状态和网络切换，而不是先更改协议。

系统 VPN 接口可能被其他网络工具占用，开启另一应用后原连接被断开属于需要检查的冲突。排查时只保留一个接管工具，再观察结果。私人 DNS、网络过滤与按应用设置也可能影响解析或连接范围，应记录原设置再逐项测试。不要为了排查永久关闭所有系统网络保护；确认相关性后，选择范围明确且可恢复的调整。

验证时先用目标应用实际访问，再查看日志中的解析与连接结果。若客户端测试成功而某个应用失败，检查按应用范围、应用自身代理设置和协议需求；若所有应用都失败，则回到服务配置与 DNS。迁移到新手机后重新检查 VPN 授权、省电限制和应用列表，因为这些系统状态不会完整随订阅迁移。快速操作路径可结合订阅导入指南查阅。

路由、DNS 与域名匹配

分流先明确输入与出口

请求进入客户端后，路由按规则决定使用直连、代理或阻止出口。规则可能依据域名、目标地址、端口或协议匹配，优先级与顺序会影响结果。一般先放必须保护的局域网规则，再放具体目标规则，最后保留默认处理方式。两个规则同时可能匹配时，应按当前内核的匹配机制判断，而不是假设更长的域名一定自动优先。

域名规则能否生效，取决于内核是否知道目标域名。应用若先自行解析再仅提交地址，客户端可能只有 IP 信息。嗅探可在某些流量中提取目标名称，但不是对所有协议都有效，也不能替代 DNS 规划。配置时先看请求以什么形式到达，再决定使用域名或地址规则。否则规则文本写得正确，仍可能从未获得匹配所需的输入。

区分服务地址解析与目标解析

至少存在两类解析：建立代理连接前，需要解析代理服务的地址；访问目标时，可能还需解析目标域名。前者必须避免依赖尚未连接的代理，否则会形成启动闭环。后者要按预期直连或代理路径安排。系统解析器、应用内置解析和内核 DNS 也可能同时存在，因此只修改客户端的一项 DNS 设置，不一定能改变所有应用的查询路径。

远程 DNS 描述的是使用哪个解析服务，并不天然保证请求经过代理。还要检查到该解析器的流量如何路由，以及客户端是否接管了应用发出的查询。加密解析改善的是查询传输方式，不等同于出口策略。若路由将解析器地址直连，查询仍可能由本地网络出口发出；配置时应把解析器选择与解析器连接路径分别验证。

配置片段只用于理解规则结构

下面是 Xray/V2Fly 风格的局部路由结构，用于说明规则字段与出口关联。它不是完整运行配置；应合并到使用该结构的自定义配置中，并保证直连出口的标签确实为 direct。图形界面可能生成不同标签，不能直接假定一致。采用其他配置格式的内核应使用对应设置入口，不把这段结构硬塞进不兼容的文件。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

AsIs 表示路由阶段不因该策略主动把域名转换为地址，不代表后续连接永远不需要解析。geoip:private 的使用还依赖相应规则数据可用。若日志指出数据文件缺失，应解决资源加载，而不是删除所有分流规则。示例中的域名仅作结构演示，实际应用应按需要填写目标，避免用过宽的规则将大量流量意外直连。

FakeDNS 与泄漏检测的边界

FakeDNS 用虚拟地址维持域名映射，需要查询和后续连接都落在匹配的处理链路中。若应用绕过客户端解析，却把真实地址交给虚拟地址规则，或反过来拿到虚拟地址但连接没有被接管，访问就可能失败。启用前先确认 TUN 的 DNS 接管方式与内核支持，不将它当成适用于所有应用的一键选项。

检测解析路径时同时观察客户端日志、系统解析设置和测试应用。测试页面展示的解析出口是线索，不是对整台设备全部查询的证明。应覆盖系统解析、浏览器独立解析与 TUN 情况，并分别验证直连目标和代理目标。详细方法见DNS 泄漏检测与配置实操。出现异常先恢复可用解析方案，再逐项增加功能，避免通信中断后失去排查依据。

系统代理与 TUN 的选择

接管入口与出站路由分开看

系统代理向应用提供代理地址，由愿意遵循该设置的应用主动转交请求。TUN 创建虚拟网络接口，通过路由把符合范围的流量送入客户端。两者解决的是不同入口问题，不能仅用“哪个模式更快”概括。日常以浏览器为主时，先使用系统代理较容易观察；当程序不读取系统代理，或需要处理更广的流量类型时，再评估 TUN。

TUN 接管范围扩大，并不等于所有流量必须走远端代理。进入虚拟接口后仍由路由决定出口，局域网通信、指定目标和部分系统流量可以直连。反过来，选择全局代理路由也不能让完全未接入客户端的应用自动使用代理。排错时先问请求是否进入客户端，再问进入后选择什么出口，两个阶段不要混在一起。

桌面启用前的检查顺序

先在系统代理下完成基础连接，确认活动配置、内核和订阅都可用，再准备 TUN。记录现有网络接口、默认网关及其他 VPN 状态，退出可能冲突的工具。按客户端提示获得创建虚拟接口的权限，启用 TUN 后查看日志中的接口建立和路由结果。如果界面开关亮起但日志报错，应以启动结果为准，不根据开关外观判断接管成功。

自动路由、严格路由、DNS 接管等设置会影响范围与兼容性，具体含义应按当前使用的内核说明确认。严格路由可能减少绕行，也可能影响局域网、虚拟机或某些系统服务。首次不要同时打开所有高级项，应先采用客户端推荐的基础组合，再依据实际遗漏补充。每次变更后检查代理目标、直连目标和局域网访问，保留可回退状态。

防止服务连接进入自身

代理服务连接也会产生网络流量。TUN 必须正确处理这部分流量，避免将内核连接再次送回同一个入口，形成循环。客户端与内核通常提供排除接口、绑定出口或路由处理机制，用户应优先使用已有集成设置。若日志出现反复连接、资源占用增加却没有目标访问，应检查路由循环与其他接管工具的交互，而不是只换远端配置。

服务地址使用域名时还涉及启动解析。若解析请求被强制交给尚未建立的代理，就可能连服务地址都无法获取。为服务地址保留可达的启动解析路径，再让目标域名按预期策略解析。多个网络接口同时连接时，应检查实际默认出口；某些程序绑定旧接口，切网后需要重启接管功能才能重新选择有效路径。

UDP、局域网与应用兼容

系统代理、客户端本地入口和远端协议对 UDP 的支持并不完全相同，远端服务也可能有限制。启用 TUN 只是把流量送入内核，不会自动补齐整个链路的 UDP 能力。若网页正常而语音、游戏或其他应用失败，应确认应用使用的流量类型，再检查入口、内核、远端协议及服务端策略，不能仅凭 TCP 访问正常就排除传输问题。

局域网设备访问依赖地址路由，设备发现还可能涉及广播或组播，不能假设一个绕过局域网规则解决所有发现行为。先测试直接访问已知局域网地址，再判断是地址通信问题还是发现机制问题。虚拟机与容器的虚拟网段也应纳入规划，避免它们与 TUN 地址池重叠。网段冲突时应调整相应配置，而不是扩大规则到全部直连。

退出与切换时保留恢复路径

完成测试后，先停用 TUN，再清除不再需要的系统代理，最后退出客户端。两个入口可以在特定方案中并存，但初次排查应只保留一种，减少路径不确定性。更换网络、休眠恢复或升级后，重新确认虚拟接口与默认路由；如果停用后仍异常，检查系统是否残留代理和解析设置。原理与操作分支可继续阅读v2rayN TUN 模式详解。

配置常见问题与分层排查

先确定故障发生在哪一层

把问题分为应用安装、内核启动、订阅获取、服务连接、流量接入、路由与解析六个阶段。记录发生时间、当前网络和最近一次修改，再查看同一时间段的日志。先找最早出现的关键错误，不被随后重复的失败淹没。界面显示连接状态、系统出现虚拟接口或某项测试通过，都只能证明对应阶段，不能替代整个链路的验证。

如果关闭客户端后原始网络也不可用，先恢复系统代理、DNS 和正常接口，确认网络自身状态。若原始网络正常而内核不能启动，则查本地文件、权限和端口；若内核正常但所有配置都失败，则查时间、网络限制及共享参数；若只有一条配置失败，则重点核对这条配置。按影响范围缩小问题，比连续更换客户端更容易得到可解释的结果。

订阅更新失败或更新后为空

先检查地址是否完整，查询参数是否丢失，是否含有空格或被复制成页面标题。然后区分网络失败与内容失败：无法连接来源时检查当前网络和更新方式；能连接但解析失败时确认返回的是客户端支持的订阅格式。登录页面、错误页面与请求限制提示都可能被当作普通文本返回，因此“获取成功”不一定意味着配置内容有效。

不通过代理更新失败时，如果已有可用连接，可以改用通过代理更新；首次没有可用连接时，不应依赖这个选项。更新后为空则检查分组启用状态、过滤条件与来源内容。保留旧可用配置，不在尚未验证新内容前删除全部条目。更多情况可参阅故障排查 FAQ，将更新失败与连接失败作为两个问题分别处理。

配置导入成功但无法连接

对照服务提供的完整参数，检查地址、端口、用户标识、传输方式、安全设置及服务名称等字段。分享链接可能压缩显示信息，应在编辑页面查看实际值。某些字段名称相近但含义不同，不能把服务器地址直接当作所有安全字段的值。证书相关错误先检查系统时间与配置中的目标名称，不通过关闭验证来把问题暂时隐藏。

内核兼容性也要单独确认。客户端接受分享链接，不代表当前所选内核支持其中全部选项；导入时缺失字段或迁移过程中保留旧设置，都可能造成不匹配。先使用订阅原始配置建立基线，再考虑手动调整。若切换内核后失败，恢复先前可用内核并对照支持差异，不把随机组合参数当作正常调试流程。

浏览器可用而其他程序失败

首先判断失败程序是否读取系统代理。支持手动设置时，核对代理协议、回环地址和实际端口；不支持时，再考虑 TUN 或安卓按应用接管范围。若程序已经进入客户端，检查路由命中和 DNS。应用自带加密解析、缓存旧地址或使用不同流量类型，都可能让它表现不同。每次验证应重新发起连接，避免旧会话掩盖设置变化。

不要将本地监听改为全部网络接口来处理普通应用失败。程序在同一设备运行时，回环地址通常已经足够；远端设备访问本地代理属于另一个需求，需要访问控制与防火墙规划。监听端口占用则先找出正在使用该端口的程序，再停止冲突进程或改用可用端口，并同步应用设置。只改一侧端口会造成新的连接错误。

恢复可用状态后再提交问题

出现间歇故障时，记录是否与锁屏、休眠、切网、订阅更新或启用其他网络工具同步发生。用同一目标重复验证，只改一个变量。恢复方案优先是停用接管功能、恢复原始网络，再导入最近的可用备份。提交问题时提供系统与架构、客户端名称、内核类型、已尝试步骤和脱敏错误片段，不公开完整凭据。概念不清时可查名词解释，再回到对应章节操作。