V2Ray 全平台安装配置大全

01 / PREPARATION

通用准备：先区分客户端、内核、订阅与节点

四个对象承担不同职责

开始安装前，先把界面程序、代理内核、订阅和节点分开理解。v2rayN、v2rayNG 与 v2flyNG 是负责配置管理和操作入口的客户端；Xray、V2Fly 等内核负责协议解析、传输建立、路由匹配与本地监听。订阅是一份可更新的服务器配置集合，节点则是集合中的单条出站配置。安装客户端并不会自动产生订阅，导入订阅也不等于已经选中可用节点。完整链路必须依次具备客户端、可启动的内核配置、当前节点和正确的本机代理入口。

桌面平台统一优先使用 v2rayN。Windows 可在桌面版与经典 WPF 版之间选择，macOS 与 Linux 使用对应架构的 v2rayN 安装包。Android 首选使用 Xray 内核的 v2rayNG，需要 V2Fly 内核时再选择 v2flyNG。三个客户端的实际安装入口集中在安装包页面，本手册不直接分发文件，也不固定写死版本号。

下载前确认系统与处理器架构

Windows 常见设备选择 x64。macOS 需要先确认处理器类型：系统信息中显示 Apple 芯片时选择 arm64，显示 Intel 时选择 x64。Linux 除架构外还要区分软件包体系，Debian、Ubuntu 及其派生发行版通常选择 deb，Fedora、Rocky Linux、openSUSE 等通常选择 rpm。Android 近年的主流设备一般使用 arm64；无法确认架构或安装时提示不兼容，再改用通用包。

保存订阅前检查来源与字段

订阅地址由服务提供方生成，通常包含访问凭据，应视为敏感配置保存。不要把地址贴到公开日志、截图或在线解析页面。导入前先确认地址没有被聊天软件截断，开头与结尾不存在空格，浏览器复制时没有混入换行。若提供方同时给出普通订阅、客户端专用订阅和单节点链接，优先选择明确标注兼容当前客户端的订阅格式；只有在订阅更新持续失败时，才用单节点链接验证客户端本身是否正常。

节点配置至少涉及服务器地址、端口、协议身份字段与传输参数。启用 TLS 或 REALITY 时，还可能包含服务器名称、指纹、公钥、短标识或路径。手工编辑时必须保持这些字段成组一致，不能只替换地址和端口。VMess、VLESS、Trojan 等协议名称描述的是认证与会话方式，WebSocket、gRPC、TCP 等描述传输承载，两类字段不能相互代替。

先建立最小可验证链路

首次配置不要同时开启 TUN、自定义 DNS、复杂路由和多个订阅。更稳妥的顺序是：安装客户端，导入一个订阅，更新服务器列表，选择一个节点，启动内核，再开启系统代理测试浏览器访问。确认这一条最小链路正常后，再添加分组、自动更新、TUN 和自定义规则。这样一旦出现问题，能够明确判断是哪一步引入了变量。

测试时保留客户端日志窗口。正常启动至少应看到本地 SOCKS 或 HTTP 监听已建立，没有端口占用、配置解析失败或权限拒绝。访问结果只能说明整条链路是否可用，不能单独证明某一层正确。若客户端显示已连接但网页打不开，应继续核对系统代理是否指向客户端实际监听端口，而不是反复切换节点。更完整的断点定位可参考代理显示已连接但网页打不开排查清单。

02 / WINDOWS

Windows：v2rayN 安装、订阅导入与系统接管

选择桌面版或经典 WPF 版

Windows 入口提供 v2rayN 桌面版和经典 WPF 版。桌面版采用跨平台界面，适合希望界面结构与 macOS、Linux 保持接近的用户；WPF 版沿用传统 Windows 操作方式，菜单位置与既有教程更接近。两者都负责管理订阅、节点、内核和路由，不需要同时安装。切换版本前应先导出自定义服务器与规则，并退出正在运行的旧客户端，避免两个实例争用同一个本地端口。

安装完成后从开始菜单启动 v2rayN。首次运行若出现网络访问权限提示，应允许当前实际使用的网络类型。公司或公共网络环境不应无条件放开额外网络范围；客户端的本地监听地址通常保持环回地址即可，不需要监听局域网。便携运行时不要把程序放在系统临时目录或会被同步软件持续锁定的目录，配置文件和日志需要稳定的写入权限。

导入订阅并选择当前服务器

打开订阅分组管理，新增分组并填写订阅地址。分组名称建议使用服务来源或用途，不要直接使用“分组一”之类难以辨认的名称。保存后执行更新订阅，主列表出现节点才表示解析完成。随后按名称、地区或协议筛选，选中一条服务器并设为活动服务器。仅仅在列表中单击高亮，不一定等于已切换当前出站，应观察状态区显示的当前服务器名称。

订阅更新会重新读取远端列表。自己添加的节点应放在独立分组，避免更新时被订阅内容覆盖。多个订阅并存时，可以为每个分组设置独立更新周期，但不建议设置过短间隔；启动后更新一次、需要时手动更新，通常更容易判断变更来源。节点数量较多时，可参考订阅分组与服务器过滤实践整理备注、关键词和排序。

从系统代理开始验证

系统代理适合先验证浏览器和遵循 Windows 代理设置的应用。启动内核后，在托盘菜单中选择设置系统代理，再访问目标站点。此模式通常把系统的 HTTP 与 HTTPS 代理指向 v2rayN 的本地监听端口，而内核根据当前路由规则决定直连、代理或阻断。若只有浏览器可用而某个程序不可用，通常是该程序忽略系统代理，并不代表节点已经失效。

需要检查端口时，可在终端查看监听状态。具体端口以客户端设置页面为准，不要假设所有安装都使用同一个值。

netstat -ano | findstr LISTENING
Get-NetTCPConnection -State Listen | Sort-Object LocalPort

如果日志报告端口已被占用，先在设置中确认 SOCKS、HTTP 和 API 端口没有互相重复，再根据进程编号查找占用程序。不要直接结束无法识别的系统进程；更安全的处理是退出旧版客户端、关闭重复启动项，或把 v2rayN 本地端口调整到未占用范围，然后重启内核。

TUN 模式与 Windows 特有问题

TUN 通过虚拟网络接口接管更多不读取系统代理设置的流量。启用前先退出其他同类网络工具，并确认 v2rayN 已具备创建虚拟接口所需权限。第一次开启时系统可能重新识别网络，短时间断开属于接口切换过程；如果持续没有网络，应立即关闭 TUN，确认系统代理模式仍可用，再检查虚拟接口、DNS 和路由规则，而不是同时重装客户端。

Windows 上常见的特有问题包括：安全软件暂时阻止内核子进程、休眠恢复后虚拟接口状态未同步、系统代理在客户端异常退出后残留，以及企业策略覆盖代理设置。正常退出客户端时应先关闭系统代理或 TUN。若程序已经退出但浏览器仍尝试连接本地代理，可在 Windows 代理设置中关闭手动代理，再重新启动客户端。休眠恢复后无法联网时，先重启内核；仍无效再关闭并重新启用 TUN，通常无需删除全部配置。

03 / MACOS

macOS：按芯片安装 v2rayN，并处理权限与代理残留

确认芯片并安装对应包

打开系统信息或“关于本机”，先确认处理器类型。Apple 芯片设备选择 arm64 安装包，Intel 设备选择 x64 安装包。架构选错时，常见结果是应用无法启动、启动后立即退出，或依赖兼容转换层运行。正确做法是回到macOS 下载入口重新选择对应包，不要通过反复修改应用权限掩盖架构问题。

安装时将 v2rayN 放入“应用程序”目录，再从该目录启动。首次运行涉及网络访问、通知或后台项目权限时，只授予客户端实际需要的项目。若系统提示无法确认应用来源，应先确认文件确实来自本站下载入口，再通过系统“隐私与安全性”页面查看被拦截的应用并执行允许操作。不要从不明转载页面补装所谓依赖。

导入订阅与管理配置目录

进入订阅设置，新增分组并粘贴完整订阅地址，保存后执行更新。更新成功但列表为空时，先检查当前视图是否启用了关键词过滤或仅显示某一分组，再查看日志中的订阅解析结果。若地址在浏览器中能够返回内容，却在客户端中持续失败，需要检查系统时间、代理循环与证书服务器名称，不应直接判定订阅失效。

手工节点和订阅节点应分组保存。准备切换安装包架构或重装客户端时，先使用客户端导出功能保存自定义节点与路由规则。配置目录不适合作为多人共享文件夹；同步工具可能在客户端写入时产生冲突副本，使 JSON 配置出现重复或截断。遇到启动后配置突然回退，应先退出客户端，再检查是否有多个配置副本同时被同步。

系统代理的作用范围

启用系统代理后，v2rayN 会调整当前网络服务的 Web 代理设置。浏览器和遵循系统网络配置的应用会连接到本地 HTTP 或 SOCKS 入口，但自行实现网络栈的应用可能忽略这些设置。切换无线网络、USB 网络或有线网络后，应确认新的网络服务也已应用代理设置，因为 macOS 会按网络服务分别保存部分参数。

可以使用系统命令查看当前网络服务，再检查代理状态。网络服务名称可能经过本地化，应以第一条命令输出为准。

networksetup -listallnetworkservices
scutil --proxy

如果客户端已经退出而网页无法打开，先在系统网络设置中关闭当前网络服务的 Web 代理与安全 Web 代理，再重新启动 v2rayN。不要在客户端运行时手工把系统代理端口改成另一组值，否则界面显示与系统实际配置会分离。需要自定义端口时，应在客户端中修改并重启内核，让系统代理设置随之更新。

TUN、DNS 与休眠恢复

macOS 的 TUN 模式需要创建虚拟网络接口并调整路由，首次开启可能要求系统授权。授权完成后先使用默认路由与 DNS 配置测试，不要立即叠加自定义域名规则。若关闭 TUN 后网络仍未恢复，依次检查虚拟接口是否消失、默认路由是否回到当前物理网络、系统 DNS 是否仍指向已经停止的本地端口。

合盖休眠、网络切换和热点切换会改变接口顺序。恢复后如果客户端显示运行但无法访问，先刷新订阅并无实际意义，应先重启内核，使监听端口、路由和 DNS 重新绑定当前网络。仅在系统代理正常、单节点测试可用的前提下，再重新打开 TUN。持续出现 TLS 连接错误时，还要确认系统时间自动同步，服务器名称与节点配置一致；相关判断方法见TLS 握手与证书报错排查。

macOS 防火墙或终端管理策略可能限制后台网络扩展。日志若明确出现权限拒绝，应按设备管理规则处理，而不是连续重装。受管理设备上的代理策略可能在登录时被统一覆盖，此时客户端设置本身没有错误，但系统代理无法持久生效。可用系统代理查询结果与客户端监听状态交叉确认，判断问题位于策略层还是内核层。

04 / LINUX

Linux：软件包安装、桌面代理、环境变量与 TUN

按发行版和架构选择软件包

Linux 版 v2rayN 同时提供 deb 与 rpm 软件包，并区分 x64、arm64。先运行架构查询命令：输出 x86_64 时选择 x64，输出 aarch64 或 arm64 时选择 arm64。Debian、Ubuntu 及其派生发行版通常使用 deb；Fedora、Rocky Linux 与采用 RPM 软件包管理的发行版使用 rpm。其他发行版不应强行解包安装，因为桌面入口、依赖关系和卸载记录可能无法正确维护。

uname -m
cat /etc/os-release

下载后在文件所在目录执行对应安装命令。命令中的文件名必须替换为下载页面显示的真实文件名。

sudo apt install ./v2rayN-package.deb
sudo dnf install ./v2rayN-package.rpm

apt install ./文件.deb 会同时处理仓库中可获得的依赖，比直接调用底层解包命令更适合普通安装。rpm 系发行版使用 dnf install 也能保留依赖解析。若依赖无法满足，先刷新发行版软件源并查看缺失库名称，不要从不同发行版混装基础库。安装完成后从桌面应用菜单启动，终端启动则应保留输出，便于捕获图形环境和权限错误。

订阅导入与桌面会话

v2rayN 的订阅操作与其他桌面平台一致：创建分组、填写订阅地址、更新服务器、选中活动节点、启动内核。Linux 上还要注意图形会话环境。以管理员身份启动图形客户端会让配置目录归属发生变化，后续普通用户运行可能无法写入配置；因此只在安装软件包和配置 TUN 权限时使用提权命令，不要长期用管理员身份运行 v2rayN。

桌面环境不同，系统代理入口也不同。GNOME、KDE 等通常都有网络代理设置，但是否被每个应用读取取决于应用的网络实现。开启 v2rayN 系统代理后，应分别测试浏览器和终端程序。浏览器正常而命令行工具直连，说明终端没有读取桌面代理，而不是内核出错。

终端程序的代理环境变量

只需让当前终端会话经过本地 HTTP 代理时，可以临时设置环境变量。端口必须与 v2rayN 的 HTTP 入站一致。命令结束后使用 unset 清除，避免包管理器或内网工具在不知情的情况下继续访问本地代理。

export http_proxy=http://127.0.0.1:本地HTTP端口
export https_proxy=http://127.0.0.1:本地HTTP端口
export no_proxy=localhost,127.0.0.1
unset http_proxy https_proxy no_proxy

这里的“本地HTTP端口”是说明文字，执行前必须换成客户端设置中显示的数字。不要把环境变量永久写入所有用户的全局配置，除非已经明确评估登录、更新、容器和后台任务的行为。SOCKS 代理不能直接作为所有程序的 HTTP 代理使用；程序明确支持 SOCKS 时，应按其参数格式填写 socks5://127.0.0.1:端口。

TUN 权限、路由和 DNS

Linux TUN 依赖系统的虚拟网络设备、路由能力和相应权限。启用失败时先确认设备存在，再从日志判断是权限不足、模块不可用还是路由添加失败。不要直接授予整个客户端不受限制的管理员权限。若发行版通过能力授权或服务组件完成 TUN，应使用客户端提供的安装流程，并在更新后检查权限是否仍有效。

ls -l /dev/net/tun
ip address
ip route
resolvectl status

开启 TUN 后无法解析域名，但直接访问已知地址仍有响应，问题通常位于 DNS 路径；两者都失败则优先检查默认路由、策略路由与防火墙。使用 systemd-resolved 的系统还要确认当前接口实际采用的 DNS，而不是只看 /etc/resolv.conf 的表面内容。NetworkManager 在断线重连后可能重写 DNS 和路由，因此网络切换后应重启内核并复查。

Linux 特有的另一类问题是桌面会话与后台进程分离。关闭窗口后客户端可能继续驻留托盘，也可能随桌面环境结束。远程会话退出前应主动停止系统代理或 TUN，避免本地监听消失后环境变量仍保留。日志中出现“address already in use”时，可用 ss -lntup 查找监听进程，再确认是否存在重复启动的 v2rayN 或旧内核实例。

05 / ANDROID

Android：v2rayNG、v2flyNG 安装与应用流量接管

选择客户端与安装包架构

Android 首选 v2rayNG，它使用 Xray 内核并覆盖常见协议与传输配置。需要 V2Fly 内核实现时，可选择 v2flyNG。两者可以分别安装，但日常只应保持一个客户端建立系统 VPN 接口，否则后启动的应用会替换前一个连接。安装包提供 arm64 和通用版，近年的主流设备优先选择 arm64；出现安装不兼容或无法确认架构时，再使用通用版。

从Android 下载入口取得安装包后，系统可能要求允许当前浏览器或文件管理器安装应用。完成安装后应关闭该来源的临时安装权限。升级时使用同一客户端对应的安装包覆盖安装，可保留现有配置；若系统提示签名不一致，不要卸载后盲目重装，应先确认下载来源和应用名称，必要时导出配置后再处理。

导入订阅与选择节点

打开 v2rayNG，进入订阅分组设置，新增订阅地址并保存，然后从菜单执行更新订阅。更新结束后返回主列表，点选一条节点，使其成为当前配置。列表左侧或状态区域的选中标记用于确认当前节点。若更新提示成功但没有新节点，检查是否进入了错误分组、订阅是否返回空内容，以及列表筛选是否隐藏了新增项目。

也可以从剪贴板导入单条链接，用于验证某个节点或排除订阅解析问题。剪贴板可能同时包含聊天文字和链接，导入前应只复制完整配置链接。二维码适合从另一台设备转移单条配置，但二维码本身包含访问参数，不应公开展示。大量节点仍应通过订阅分组维护，避免逐条更新服务器参数。

启动连接与应用分流

选择节点后点击连接按钮，系统首次建立 VPN 接口时会显示授权对话框。确认后，客户端在本机创建流量入口，并根据路由设置决定哪些连接进入代理出站。状态栏出现连接标记只代表接口已经建立，不代表远端握手一定成功；应继续查看客户端测试结果和日志。节点测试失败时，先切换同一订阅中的另一节点，判断是单节点问题还是所有配置都失败。

Android 的分应用代理可以指定哪些应用进入客户端，适合减少不需要代理的本地流量。配置时必须明确采用“仅代理已选应用”还是“绕过已选应用”，两种逻辑相反。修改列表后重新连接，使系统接口读取新规则。浏览器可访问而目标应用不可用时，应优先检查分应用列表、目标应用自身的 DNS 行为和后台联网限制。

后台限制、私人 DNS 与移动网络切换

系统的省电策略可能限制 v2rayNG 或 v2flyNG 后台运行，表现为锁屏一段时间后连接断开、切回应用才恢复。可在系统电池管理中允许客户端保持必要的后台活动，并确保数据节省模式没有阻止其联网。无需给客户端开放与网络功能无关的权限。清理后台工具若会强制停止 VPN 应用，也应将当前客户端排除在自动结束列表之外。

启用系统“私人 DNS”后，域名请求可能绕过客户端预期的 DNS 路径，或与节点配置产生解析差异。遇到域名无法访问但地址连接正常时，可暂时恢复自动 DNS 进行对照测试，再决定是保留系统设置还是由客户端统一处理。不要同时启用多个自定义 DNS 层，否则日志只能看到最终失败，难以确认请求在哪一层被改写。

无线网络与移动网络切换会改变本机出口。切换后连接看似仍在，但底层会话可能已经失效，应断开并重新连接。公共网络需要网页认证时，先暂停客户端并完成网络登录，再恢复连接。若只有某一种网络无法使用，应比较该网络的 DNS、IPv6 和端口限制，不要立即删除订阅。TLS 错误还应检查系统时间是否自动同步，以及节点中的服务器名称是否完整。

06 / SUBSCRIPTION · ROUTING

订阅、节点与路由分流：跨平台统一管理方法

订阅更新不是节点切换

订阅更新负责从指定地址重新取得节点集合，节点切换负责改变当前使用的出站，两者是独立操作。更新后原节点可能被删除、重命名或调整参数，因此客户端仍显示旧名称时，应回到服务器列表重新确认当前选中项。设置自动更新时，需要保留合理间隔并观察一次手动更新结果；频繁请求不会提高节点可用性，反而会让配置变化难以追踪。

多订阅环境建议按来源建立分组，再使用备注表达地区、线路或用途。不要仅靠节点原始名称判断协议与安全参数，因为名称只是显示文本。需要判断节点配置时，应打开详情查看协议、地址、端口、传输、安全层和服务器名称。订阅节点由提供方维护时，除非明确知道差异，不应逐条修改核心字段；下次更新可能覆盖本地修改。

建立可回退的配置基线

在加入复杂规则前，先保留一套能够工作的基础配置：单个订阅、一个已验证节点、默认路由和默认 DNS。每次只修改一类设置，例如先添加域名直连规则，验证后再加入地址规则。这样发生异常时，可以回退到上一个可用状态。客户端提供导出功能时，应在大规模调整分组和路由前导出配置，但导出文件含有节点访问参数，需要按敏感文件保存。

节点测试只能作为筛选工具。TCP 连通说明服务器端口能够建立连接，不能证明认证、TLS、传输路径和最终出站全部正常。真实判断仍要结合内核日志和一次完整访问。测试结果突然全部失败时，应先检查本机网络、系统时间、DNS 和订阅字段，而不是同时删除全部节点。

理解路由匹配顺序

路由规则通常按顺序匹配，先命中的规则决定直连、代理或阻断。范围较大的规则放在前面，可能覆盖后面的精确规则。例如先写一条覆盖所有域名的代理规则，后面的某个域名直连规则就没有机会执行。更容易维护的顺序是：明确的局域网和本机目标、需要单独处理的精确域名、分类规则、最后的默认出站。

下面是内核路由结构的简化示例，展示字段层级与匹配方式。实际出站标签必须与客户端生成的配置一致，不能直接假设名称。

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

geoip:private 用于匹配常见私有地址范围，避免局域网设备被送往远端。示例域名只用于说明规则格式。客户端图形界面可能把这些字段包装为预设规则，启用前仍应确认预设的匹配顺序与默认出站。地址规则和域名规则并非完全等价：应用先解析域名后再连接地址时，内核能看到哪一层信息，取决于接管模式和 DNS 流程。

分流失效时检查可见信息

系统代理模式下，支持 HTTP 代理的应用通常会把域名交给代理入口，域名规则较容易生效；部分应用会先在本机解析，再连接地址，此时可能只命中 IP 规则。TUN 模式能够接管更广，但还需要 DNS 嗅探和路由配置配合。分流结果与预期相反时，先在日志中确认目标实际匹配了哪条规则，再调整顺序，不要仅凭网站显示内容推断出口。

需要让局域网打印机、路由器管理页或开发服务保持直连时，应保留私有地址直连，并检查客户端是否允许本地网络访问。若系统代理只绑定环回地址，本机应用仍可使用，但局域网其他设备不能把它当作代理入口。除非明确需要共享，不要开启局域网监听。共享监听还涉及防火墙、访问控制和网络边界，不属于普通单机配置。

07 / PROXY · TUN · DNS

系统代理、TUN 与 DNS：三条链路如何配合

系统代理只接管主动使用代理的应用

系统代理本质上是把操作系统中的 HTTP、HTTPS 或 SOCKS 代理设置指向客户端本地监听端口。浏览器和遵循系统设置的程序会主动连接该端口，客户端再把请求交给当前节点。它的优势是路径清晰、权限要求低、出现问题时容易恢复；限制是部分程序不读取系统代理，UDP 流量和自定义网络栈也可能不经过该入口。

排查系统代理时必须同时核对三个值：系统设置中的代理地址、代理端口，以及客户端实际监听地址。常见错误是客户端更改了本地端口，系统仍保留旧值；或客户端退出后，系统继续连接已经不存在的本地端口。正常关闭前先停止系统代理，可以减少残留。系统代理可用而单个应用不可用，应检查应用自己的代理选项，不要直接改成全局路由。

TUN 接管的是网络接口与路由

TUN 模式创建虚拟网络接口，通过系统路由把更多流量送入客户端。它适合不支持系统代理的应用、需要统一分流的桌面环境，以及部分 UDP 场景。因为它处于更底层，接口权限、默认路由、DNS、防火墙和其他虚拟网络工具都会影响结果。启用前应先证明同一节点在系统代理模式下可用，否则同时排查远端节点和本地接口会增加判断成本。

开启 TUN 后，系统通常同时存在物理接口、环回接口和虚拟接口。默认路由或策略路由决定流量进入哪一个路径。若启用后立刻全网中断，优先关闭 TUN恢复基础网络，再查看日志中的接口创建和路由添加结果。不要在断网状态下连续修改多个 DNS 与 MTU 参数，因为恢复后无法知道哪项修改真正有效。

DNS 决定域名如何进入路由判断

DNS 不只是把域名转换为地址，它还影响域名规则能否被准确匹配。系统代理模式下，应用可能把域名交给本地代理，也可能先自行解析；TUN 模式下，客户端可以通过接管 DNS 保留域名与连接之间的关联。若解析请求绕过客户端，路由层可能只看到目标地址，原本按域名设置的规则就不会按预期执行。

常见 DNS 异常可分为三类：请求没有到达预期解析器、解析结果正确但连接被错误分流、解析器可达但返回结果不适合当前网络。排查时先用系统工具确认域名是否得到结果，再查看客户端日志是否记录了 DNS 请求与路由命中。不要只通过清空浏览器缓存判断，因为操作系统、客户端和浏览器可能分别维护缓存。

全局代理与规则代理的边界

全局代理通常表示可接管的流量统一走当前代理出站，适合短时验证节点：如果全局模式可用而规则模式不可用，问题多半在路由规则、DNS 或匹配顺序。它不适合作为所有环境下的默认答案，因为局域网、系统更新和本地服务可能需要直连。验证结束后应恢复经过检查的规则模式。

规则代理通过域名、地址、端口、网络类型或进程条件选择出口。规则越多，维护成本越高。只保留能够说明用途的规则，并为自定义项写清备注。删除规则前先确认是否有其他项依赖其出站标签。客户端更新或订阅更新通常不应覆盖独立保存的路由配置，但导入整套配置时可能替换当前设置，因此导入前需要先导出可回退副本。

若需要确认请求实际经过哪个入口，可先观察内核访问日志，再对照应用代理设置。日志中没有任何连接记录，问题位于应用到本地入口之间；有入站记录但没有远端连接，检查路由和出站配置；已经发起远端连接但握手失败，则检查节点参数、系统时间和网络可达性。这种分层判断比不断切换模式更快。

08 / TROUBLESHOOTING

配置常见问题：按本机、内核、订阅与远端逐层定位

先记录现象，再缩小故障层级

排查前先记录四项事实：当前平台和客户端、使用系统代理还是 TUN、问题是否影响所有节点、日志中第一条明确错误。不要只记录“无法使用”，因为启动失败、域名解析失败、远端握手失败和单个应用不走代理对应完全不同的处理路径。每次修改一项设置并重新测试，避免多个变化相互掩盖。

最短检查路径是：确认普通网络可用；确认客户端进程与内核进程都在运行；确认本地监听端口存在；确认当前节点已选中；确认系统代理或 TUN 已生效；最后检查远端握手与路由命中。若所有节点同时失败，优先看本机网络、时间、DNS、订阅和客户端配置。只有一条节点失败，则优先比较该节点与可用节点的地址、端口、传输和安全参数。

内核启动后立即退出

内核启动失败通常会在日志开头给出原因。端口占用表示本地监听无法绑定；配置解析错误表示生成的 JSON 字段、逗号或类型不符合要求；缺少必填参数常见于手工编辑节点时遗漏安全层字段；权限拒绝多见于 TUN 接口或受保护目录。应从第一条错误开始处理，后续错误可能只是前一项失败的连锁结果。

端口占用时退出重复客户端或修改监听端口。配置错误时回退最近一次手工修改，或新建一条最小节点进行对照。不要把整段日志删除后只保留最后一行，因为配置文件路径和具体字段通常出现在前文。可结合从日志定位内核启动失败逐行判断错误类别。

显示已连接但网页打不开

“已连接”可能只表示客户端状态被切换为运行，并不能证明浏览器已经接入本地代理。先检查系统代理地址与端口，再确认浏览器没有覆盖系统设置。TUN 模式下检查虚拟接口和默认路由。日志完全没有浏览器请求时，断点位于应用与本地入口之间；日志有请求但显示 DNS 失败，应检查解析链路；有远端拨号但超时，则继续判断地址、端口和网络可达性。

若全局模式可用而规则模式不可用，恢复默认路由规则或检查自定义规则顺序。若地址可以连接但域名失败，暂停额外的私人 DNS、浏览器安全 DNS或系统自定义解析进行对照。若只有局域网目标失效，补充私有地址直连，而不是关闭全部路由。完整逐项清单可查看连接后无法访问网页的断点检查。

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

先确认订阅地址完整，没有空格、换行或过期参数。再检查当前网络能否访问订阅服务、系统时间是否正确、客户端是否错误地通过尚未启动的本地代理更新订阅。多个分组时确认更新操作作用于正确分组，并关闭列表过滤查看原始结果。返回内容存在但解析失败，应查看订阅格式是否与当前客户端兼容。

更新后节点减少可能是远端订阅内容发生变化，不一定是客户端删除数据。自定义节点应放在独立分组，避免与远端条目混合。需要验证客户端解析能力时，可以导入一条明确兼容的单节点配置；单节点可用而订阅失败，问题集中在订阅获取或格式。单节点同样失败，则回到内核日志继续排查。

TLS、服务器名称与系统时间

TLS 相关错误需要对照具体提示。证书尚未生效或已经过期的提示，首先检查系统日期、时间与时区；服务器名称不匹配时，检查节点中的 serverName 或 SNI 是否与服务配置一致；握手提前关闭还可能来自传输路径、端口或服务端状态。不要把“跳过证书验证”作为常规修复，它只会隐藏身份验证问题，不能修复错误的地址、服务器名称或时间。

REALITY 配置还需要公钥、短标识、服务器名称与指纹等字段相互匹配。复制节点时漏掉任意一项都可能导致握手失败。订阅管理的节点应优先重新更新完整配置，而不是根据别的节点猜测字段。更多分类说明见TLS 握手、SNI 与时间检查。

恢复到可验证状态

多次调整后无法确认问题来源时，应执行受控回退，而不是删除所有数据。先导出需要保留的手工节点与规则；关闭 TUN、自定义 DNS和额外路由；恢复系统代理模式；只启用一个订阅和一个节点；重启客户端并观察从启动到第一次请求的完整日志。最小状态可用后，再逐项恢复设置，每恢复一项就测试一次。

客户端更新前也应使用同样原则：记录当前工作模式，退出正在运行的内核，保存自定义配置，再安装对应平台与架构的软件包。更新后先验证基础链路，不要立即修改全部设置。若界面能够启动但旧配置异常，检查配置迁移日志和文件权限；Linux 特别注意配置目录归属，Windows 检查重复进程，macOS 检查网络服务代理残留，Android 检查系统 VPN 授权与后台限制。