章节目录
通用准备工作与配置边界
安装客户端之前，先把平台、处理器架构、订阅来源和接管范围确定下来。多数安装失败并非客户端本身异常，而是安装包架构选错、旧进程仍占用端口、系统时间偏差，或者订阅参数与服务端不一致。准备阶段把这些变量固定，后续四个平台的操作会更清晰。
客户端与平台对应关系
桌面端统一使用 v2rayN。它覆盖 Windows、macOS 与 Linux，提供订阅分组、服务器列表、系统代理、TUN、路由规则和日志查看等图形入口。Android 首选 v2rayNG，使用 Xray 内核；需要 v2fly 内核时可选择 v2flyNG。两款 Android 客户端的界面布局和配置导入方式接近，但内核能力、部分实验选项与配置兼容范围可能不同，不能把同一份高级配置机械地视为完全等价。
安装包架构必须和设备处理器匹配。Windows 常见设备选择 x64；macOS 需要先判断 Apple Silicon 或 Intel；Linux 除处理器架构外，还要根据发行版选择 deb 或 rpm；近年的 Android 主流手机通常使用 arm64，无法确认时再选择通用包。本站的安装包页面已经按平台和架构拆分入口，下载时不需要从文件名列表中自行猜测。
| 平台 | 首选客户端 | 安装包判断 | 主要接管方式 |
|---|---|---|---|
| Windows | v2rayN | x64 桌面版或经典 WPF 版 | 系统代理、TUN |
| macOS | v2rayN | Apple Silicon arm64 或 Intel x64 | 系统代理、TUN |
| Linux | v2rayN | deb / rpm 与 x64 / arm64 | 桌面代理、环境变量、TUN |
| Android | v2rayNG | arm64 或通用版 | 系统 VPN 接口 |
订阅、单节点与本地配置
订阅地址是一份可更新的远程节点清单。客户端保存地址后，会按订阅分组拉取服务器名称、协议、端口和传输参数。单节点链接适合临时导入或验证某一组参数；本地 JSON 配置适合精细路由、多个出站和复杂 DNS 策略。三种方式解决的问题不同。日常使用优先保留订阅分组，避免每次更新后重复手工录入；需要实验高级规则时，可以复制现有配置到独立分组，防止测试修改覆盖稳定配置。
订阅地址通常包含访问凭据，应按账号信息管理。不要把完整地址粘贴到公开日志、截图或在线转换页面。需要进行 V2Ray 订阅转换时，应先确认转换服务的来源和输出格式，并检查转换后是否保留 protocol、security、network、flow、SNI 与公钥等关键字段。转换只改变客户端可读取的表示形式，不会自动修复服务端与客户端之间的参数差异。
连接前的环境检查
首先校准系统日期、时间和时区。TLS 与 REALITY 握手依赖时间窗口，明显偏差可能表现为节点一直超时。其次退出旧客户端，确认本地代理端口没有被另一个进程占用。再次检查安全软件和系统防火墙是否允许客户端与内核建立本地监听和外部连接。最后准备一个可正常访问的订阅地址，并确认账号状态、流量和有效期。节点名称能显示，只说明订阅内容已被读取，不等于节点当前一定可连接。
连接验证应分成三层：内核是否成功启动、本地代理端口是否监听、应用流量是否进入代理。只看网页能否打开，很难定位问题属于哪一层。日志出现启动完成但浏览器没有流量，通常要检查系统代理或浏览器独立代理；本地端口没有出现，则先处理配置解析、端口冲突或内核文件权限；握手阶段失败，再回到服务器参数和本机时间。
更新与备份原则
更新客户端前先导出或备份订阅分组、自定义路由、DNS 规则和本地配置。桌面端还应记录当前系统代理模式与本地监听端口。跨较大界面代际更新时，旧配置通常可以迁移，但字段默认值可能变化，建议首次启动后逐页检查核心设置。Android 端更新前确认订阅地址仍可取得，避免只依赖应用内部已经展开的临时节点列表。
本手册后续章节都采用同一条验证顺序：安装完成后先启动客户端，再导入订阅并更新分组，选择一个节点启动内核，随后决定系统代理或 TUN，最后检查日志与实际流量。保持顺序固定，可以避免同时更改多个变量。若只需要十分钟完成首次配置，可转到v2rayN 使用指南；需要逐项理解设置含义，则继续阅读对应平台章节。
Windows：v2rayN 安装、订阅与系统接管
Windows 是 v2rayN 使用路径最完整的平台。安装时需要在桌面版与经典 WPF 版之间选择，连接后再根据应用范围决定系统代理或 TUN。两种界面实现不同，但订阅、节点、路由和内核日志的基本概念一致。
选择桌面版或经典 WPF 版
桌面版采用新一代跨平台界面，适合希望在不同桌面系统间保持相近操作结构的用户。经典 WPF 版沿用成熟的 Windows 界面组织，适合已经熟悉传统服务器列表、托盘菜单和设置入口的用户。两者不需要同时运行。若进行对比测试，应确保前一个客户端已经退出，并检查它是否恢复了系统代理，否则第二个客户端启动后可能接管同一组端口，造成日志与实际流量来源混淆。
从Windows 安装入口取得对应安装包后，按安装向导完成部署。首次启动如果出现网络访问或防火墙确认，应允许客户端在当前使用的网络类型中通信。安装目录和用户配置目录需要具备正常读写权限。企业管理设备可能限制代理设置、虚拟网卡或驱动安装，此类限制要由设备策略处理，反复重装客户端不能绕过系统级策略。
导入订阅并整理分组
进入订阅分组管理，新增一个名称清晰的分组，将订阅地址填入对应字段并保存。随后执行更新当前分组。更新成功后，服务器列表会出现节点；如果分组存在但列表为空，先打开日志查看 HTTP 状态、解析错误或格式提示。不要连续快速点击更新，因为部分订阅服务会限制短时间请求频率。更新前后节点数量发生变化属于服务端清单调整，客户端不会凭空创建节点。
服务器列表建议保留名称、地址、端口、协议、传输、安全层和订阅分组等关键列。选择节点时，不要只依赖名称中的地区或线路描述，应先做一次真实连接并观察握手日志。延迟测试只能说明测试方式对应的网络可达情况，不能覆盖目标应用的全部访问路径。确定稳定节点后，将其设为活动服务器，再启动系统代理或 TUN。
手工导入单节点时，可以从剪贴板读取标准分享链接，也可以在服务器编辑窗口逐项填写。编辑 REALITY 节点尤其要注意 serverName、fingerprint、publicKey、shortId 与 flow。若分享链接导入后仍无法连接，应把字段与服务端提供的信息逐项比较，而不是随机切换安全选项。
系统代理模式的使用范围
系统代理适合遵循 Windows 代理设置的浏览器和桌面应用。启用后，v2rayN 会把系统代理指向本机监听地址与端口，应用再通过客户端转发。通常应先保持“自动配置系统代理”或等效状态，然后打开浏览器验证。若某个程序忽略系统代理，需要在该程序内部指定 HTTP 或 SOCKS 地址，或者改用 TUN。
系统代理的路由模式决定哪些目标进入代理。全局模式便于短时间验证节点是否能工作，但不适合作为复杂分流的最终配置；规则模式会根据域名、IP、geosite 与 geoip 规则选择直连、代理或阻断。修改模式后应重新发起连接，已有长连接可能继续沿用旧路径。退出客户端前恢复系统代理是良好操作习惯，尤其是经常切换网络或休眠唤醒的设备。
TUN 模式与权限
TUN 通过虚拟网络接口接管更广泛的流量，适合不读取系统代理的应用、命令行工具和需要统一分流的场景。首次开启通常需要管理员权限，并可能触发虚拟网卡或网络组件安装。启用前退出其他同类网络工具，避免多个虚拟接口同时修改默认路由。开启后应检查 TUN 状态、DNS 监听和路由日志，确认流量确实进入当前内核。
TUN 并不等于所有连接自动可用。局域网访问、虚拟机网络、开发容器、远程桌面和企业内网可能依赖特定路由。若开启后本地设备不可访问，应将私有地址段设为直连，并检查严格路由、自动路由和 DNS 劫持设置。关闭 TUN 后网络没有立即恢复时，可先完全退出客户端，再禁用并重新启用当前网络适配器；不应在问题尚未定位时同时重置全部网络设置。
日志、托盘与启动行为
v2rayN 的主日志用于观察配置生成、内核启动、本地端口和错误信息。排查时先清空旧日志，再复现一次问题，避免把上一次节点的报错当成当前结果。常见关注点包括端口占用、配置字段无法解析、DNS 请求失败、连接超时和握手中断。若日志显示内核正常启动，下一步应检查系统代理和路由；若内核反复退出，则回到配置文件与权限。
托盘菜单通常承担快速切换系统代理、当前服务器和退出程序的功能。关闭主窗口不一定等于退出进程，因此更换版本或排查端口时要从托盘明确退出。设置开机启动前，先确认默认节点、订阅更新行为和接管模式符合预期。便携设备经常切换家庭、办公与移动热点，建议保留手动确认接管模式的步骤，避免登录系统后直接沿用不适合当前网络的路由。
macOS：芯片选择、权限与代理配置
macOS 版 v2rayN 与其他桌面版共享主要功能，但安装包必须与处理器架构一致，首次运行还会涉及应用确认、网络配置和 TUN 权限。先处理系统层许可，再判断节点与协议问题，可以减少无效重装。
确认处理器并完成安装
打开系统信息或“关于本机”查看芯片名称。显示 Apple 芯片时选择 arm64 安装包，显示 Intel 处理器时选择 x64 安装包。架构错误可能导致应用无法启动，或通过兼容转换运行但行为不稳定。从macOS 安装入口下载对应 DMG，打开后按窗口提示将应用放入“应用程序”目录，再从该目录启动。
首次运行时，系统可能要求确认应用来源或网络访问。按系统设置中的安全提示完成确认，不要反复复制多份应用到不同目录。多份副本会让配置位置、自动启动项和当前运行版本难以判断。若更新后仍看到旧界面，应从活动监视器确认旧进程已经结束，再从“应用程序”目录启动新副本。
订阅导入与服务器选择
进入订阅管理，新建分组并保存订阅地址，然后执行分组更新。节点出现后，先选择一个配置明确的服务器作为活动节点。若订阅更新失败，检查当前网络能否访问订阅地址、地址是否被复制完整，以及系统日期是否准确。订阅链接中如果包含特殊字符，直接完整粘贴，不要自行删改查询参数。
macOS 上的节点参数检查与 Windows 相同。VLESS 配置要关注用户标识、加密字段、传输层与 flow；REALITY 还需要核对 serverName、fingerprint、publicKey 和 shortId；WebSocket 或 gRPC 需要保持路径、主机名或 serviceName 一致。一个节点在另一台设备可用，只能说明服务端整体可达，当前设备上的导入结果仍可能遗漏字段。
系统代理与应用差异
启用系统代理后，v2rayN 会修改当前网络服务的代理配置。多数浏览器和遵循系统网络框架的应用会自动使用该设置。命令行程序、开发工具和部分跨平台应用可能读取自己的代理环境变量，或者完全绕开系统代理。判断是否接管时应同时查看客户端日志：打开目标应用并发起新请求，如果日志没有连接记录，说明流量尚未进入 v2rayN。
终端中的临时代理可以显式指向 v2rayN 的本地 HTTP 监听端口。端口以客户端设置页面实际显示值为准，下面示例使用常见本地地址，仅用于说明环境变量写法：
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809
export ALL_PROXY=socks5://127.0.0.1:10808
# 当前终端会话结束后不再保留
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY不要在未确认端口的情况下把示例长期写入 shell 配置。若客户端端口以后调整，旧环境变量会让终端持续连接失效端口。需要长期使用时，应把端口修改记录与 v2rayN 设置保持同步，并在关闭客户端时明确取消代理变量。
TUN、DNS 与系统授权
TUN 模式适合接管不遵循系统代理的应用。首次开启时，系统可能要求管理员授权或允许网络扩展。授权完成后，检查菜单栏网络状态和 v2rayN 日志，确认虚拟接口已经建立。若同时运行其他修改路由或 DNS 的工具，应先退出它们，只保留一个接管者。多个工具同时写入默认路由时，现象可能是网页偶尔可用、局域网断开或 DNS 请求循环。
DNS 设置需要与路由策略一起理解。域名先解析再匹配 IP，与直接按域名规则匹配，结果可能不同。若使用 FakeDNS，应确认目标应用和局域网服务适合这种映射方式。关于保留地址映射和 TUN 场景边界，可继续阅读FakeDNS 虚拟 DNS 映射原理详解。局域网打印、文件共享、开发设备发现异常时，优先将私有地址和本地域名设为直连，并暂时关闭高级 DNS 功能进行对照。
休眠、网络切换与退出恢复
笔记本从休眠恢复或切换无线网络后，原有连接、DNS 缓存和默认路由可能已经失效。此时先停止当前连接，再重新选择节点并启动；如果系统代理指向仍然正确但没有流量，重启内核通常比重新安装客户端更有效。网络从公司环境切换到家庭环境时，还应检查原先用于内网的直连规则是否仍符合当前需求。
退出 v2rayN 前应先关闭系统代理或 TUN，让系统恢复普通网络路径。若强制结束进程后网络异常，打开系统网络设置检查当前网络服务的 HTTP、HTTPS 与 SOCKS 代理是否仍指向本机端口。确认遗留项后再关闭，而不是删除整个网络服务。应用能够启动、内核能够运行、系统代理能够恢复，是 macOS 安装完成后的三个独立验收点。
Linux：软件包安装、桌面代理与 TUN
Linux 版 v2rayN 面向桌面环境。安装时需要同时判断发行版软件包体系和处理器架构，运行后还要区分桌面系统代理、终端环境变量与 TUN 三条流量入口。发行版之间的菜单名称不同，但排查逻辑保持一致。
选择 deb、rpm 与处理器架构
Debian、Ubuntu 及其常见派生系统通常使用 deb；Fedora、Rocky Linux、AlmaLinux 等使用 rpm。处理器为常见桌面 x86-64 时选择 x64，arm64 设备选择相应架构。可以通过以下命令确认架构和系统信息：
uname -m
cat /etc/os-releasex86_64对应 x64，aarch64通常对应 arm64。确认后从Linux 安装入口选择软件包。不要仅凭发行版桌面外观判断包格式，也不要把不同架构的软件包强制安装到当前系统。软件包管理器报告依赖问题时，应先刷新发行版的软件源元数据，再让包管理器处理依赖关系。
使用包管理器完成安装
在下载目录中，deb 可以交给 apt 安装，rpm 可以交给 dnf 安装。实际文件名以下载结果为准，下面命令演示从当前目录安装一个明确的软件包文件：
# Debian / Ubuntu 系
sudo apt update
sudo apt install ./v2rayN-linux-x64.deb
# Fedora / Rocky Linux 系
sudo dnf install ./v2rayN-linux-x64.rpm使用包管理器而不是只解压文件，可以让桌面入口、依赖和卸载记录保持一致。安装完成后从应用菜单启动 v2rayN。若终端提示找不到显示环境，说明当前会话可能不在图形桌面中；v2rayN 是图形客户端，不应把桌面启动方式直接当作无界面服务器服务。远程桌面环境还要确认当前用户有图形会话和用户级配置目录写入权限。
应用启动后立即退出时，可以从终端启动一次并读取标准错误，同时查看用户日志目录。常见原因包括图形库依赖缺失、安装包架构错误、配置目录权限异常或旧进程仍在运行。不要直接用管理员身份长期运行整个客户端来规避权限问题，这会让用户配置文件归属发生变化，并扩大 TUN 之外不必要的权限范围。
订阅管理与桌面系统代理
新建订阅分组、粘贴地址、保存并更新。节点列表生成后选择活动服务器，先启动内核但暂不启用 TUN，通过客户端日志确认本地 HTTP 与 SOCKS 监听已经建立。随后在 v2rayN 中设置系统代理。GNOME、KDE 和其他桌面环境对系统代理的存储方式不同，部分应用会读取桌面代理，部分应用只读取环境变量，因此不能用单个浏览器结果代表整个系统。
桌面代理启用后，可以在系统设置中检查 HTTP、HTTPS 和 SOCKS 是否指向本机。终端工具需要时，可按当前监听端口设置环境变量。图形程序从桌面菜单启动时不一定继承终端中的变量；从同一终端启动的程序通常会继承。排查时要记录应用到底从哪个会话启动，避免环境变量看似正确但实际进程没有读取。
TUN、能力授权与路由
Linux TUN 需要创建虚拟接口、写入路由并处理 DNS，相关操作需要系统权限。优先使用客户端提供的授权流程，不要随意给整个程序永久管理员权限。开启前检查系统是否已有其他 VPN 接口、容器网络、虚拟机桥接或策略路由。开发工作站的网络拓扑往往比普通桌面复杂，自动路由可能影响容器访问宿主机、局域网服务发现或远程维护连接。
开启 TUN 后，使用 ip address 与 ip route 查看接口和路由变化，并结合 v2rayN 日志判断流量是否到达内核：
ip address
ip route
ss -lntup | grep -E '10808|10809'最后一条命令中的端口只是常见示例，实际应替换为客户端当前监听端口。若 TUN 接口存在但无法解析域名，应检查 DNS 监听、系统解析器和发行版使用的网络管理服务。若 IP 连接正常而域名失败，问题集中在 DNS；若所有目标都没有日志，则检查默认路由是否进入虚拟接口；若只有局域网失败，应添加私有地址直连规则。
更新、卸载与配置目录
通过新软件包更新前先退出 v2rayN，并备份订阅、自定义路由和 DNS 设置。使用同一包管理器安装新包，通常会沿用用户配置；更新后首次启动要核对本地端口和接管模式。若旧进程没有退出，新程序可能因为配置锁或端口占用而无法正常启动。可以先通过系统监视器或进程列表确认，再决定是否结束旧进程。
卸载软件包与删除用户配置是两件事。包管理器移除应用时，用户目录中的配置可能保留，便于后续恢复。排错时不建议一开始就删除整个配置目录，因为这会同时丢失能够帮助定位问题的日志和规则。更稳妥的方法是导出配置，关闭程序，将现有配置目录改名，再启动一个干净环境做对照。若干净环境可用，再逐项迁回订阅和规则，便能找到触发异常的具体部分。
Android：v2rayNG 导入、连接与应用分流
Android 首选 v2rayNG，使用 Xray 内核；v2flyNG 作为 v2fly 内核备选。移动端通过系统 VPN 接口接管流量，不使用桌面系统代理。权限、电池策略、后台限制和应用分流，是移动端与桌面端最明显的差异。
选择 arm64 或通用安装包
近年的主流 Android 手机通常选择 arm64，无法确认设备架构或 arm64 包无法安装时再使用通用版。v2rayNG 与 v2flyNG 都提供相应入口，具体顺序和架构说明见Android 安装页面。同一设备上进行客户端切换时，先停止当前连接，避免系统 VPN 接口仍由另一个应用占用。
首次启动后，客户端会在连接时请求创建 VPN 连接。系统一次只能把当前流量交给一个此类连接，因此其他 VPN 类应用可能导致授权被覆盖或连接立即断开。若点击连接后没有出现状态图标，应查看系统授权是否完成，并确认没有被设备管理策略限制。
订阅与分享链接导入
打开订阅设置，新增分组名称和订阅地址，保存后执行更新。移动网络下更新失败时，可以切换到稳定的无线网络再次测试；如果两种网络都失败，则检查订阅地址、账号状态和日志。订阅更新成功后返回主列表，选择一个节点，再点击连接按钮。不要在订阅更新过程中频繁切换应用或清理后台，这可能中断下载和解析。
单节点可通过剪贴板中的标准分享链接导入，也可以扫描可信来源提供的二维码。导入后进入编辑页面核对服务器地址、端口、用户标识、传输、安全层和 SNI。二维码只是一种编码载体，不会替用户判断参数是否匹配。REALITY 节点还要确认 fingerprint、publicKey、shortId 与 flow；字段缺失时，客户端能够保存配置但握手仍会失败。
订阅更新通常会替换分组中的远程节点。需要长期保留的手工修改，应复制到独立分组，避免下一次更新覆盖。节点名称只用于识别，修改名称不会改变连接参数。若列表较长，可以按订阅分组管理，而不是把多个来源混在同一层级中。
路由模式与应用分流
连接前选择适合的路由模式。全局模式便于验证当前节点；规则模式根据域名和 IP 决定代理或直连；自定义配置适合需要精细 DNS、多个出站或特定规则顺序的用户。首次配置建议先用简单模式确认连接，再逐步增加规则。若一开始同时启用复杂 DNS、应用分流和多组路由，出现异常时很难判断是哪一层造成。
应用分流可以指定哪些应用进入 v2rayNG，或排除明确需要直连的应用。设置时要注意系统组件、浏览器和目标应用之间的调用关系。例如某个应用可能调用外部浏览器完成登录，若两者不在相同路径上，回调过程可能失败。修改应用列表后应断开并重新连接，让系统 VPN 接口按新规则建立。
局域网设备、投屏、打印和文件传输通常需要私有地址直连。发现连接开启后局域网功能失效，应先检查绕过局域网或私有地址规则，再观察 DNS 是否把本地域名交给远端解析。规则顺序同样重要：更具体的直连规则应位于会提前命中的宽泛代理规则之前。
电池优化与后台稳定性
部分设备会在熄屏、低电量或长时间后台时限制 v2rayNG。表现为连接图标仍存在但流量停止，重新打开应用后恢复。可在系统电池设置中允许客户端按实际需要运行，并确认后台数据没有被限制。不同厂商的菜单名称不同，核心目标是避免系统在连接期间冻结客户端或内核进程。
稳定性测试应至少覆盖前台浏览、熄屏后恢复、无线网络与移动网络切换。网络切换会改变本地地址、DNS 和默认路由，短暂重连属于正常恢复过程；若每次切换后都无法恢复，先断开再连接，并查看日志是否停在 DNS、握手还是系统 VPN 建立阶段。不要只通过状态栏图标判断连接质量，图标表示接口存在，不代表目标节点已经完成握手。
v2rayNG 与 v2flyNG 的切换边界
v2rayNG 适合使用 Xray 内核能力和相关协议配置，是 Android 的首选。v2flyNG 使用 v2fly 内核，可作为特定配置需求下的备选。切换客户端前先导出或保存订阅地址，不要假设两者会共享应用内部数据库。相同订阅在两款客户端中展开的基础节点通常相近，但高级配置字段、实验功能和默认行为可能不同。
对比时保持节点、网络和路由模式一致，每次只更换一个变量。若 v2rayNG 能连接而 v2flyNG 不能，应先检查配置是否使用了后者当前不处理的字段；反向情况则检查导入结果和默认设置。排查目标不是反复切换内核，而是确认订阅格式、协议参数和客户端能力之间是否匹配。
订阅、系统代理、TUN 与路由规则
四个平台的界面不同，但核心数据流一致：应用先把请求交给本地代理或虚拟接口，内核根据路由规则选择出站，再按节点协议建立连接。理解这一顺序后，系统代理、TUN、DNS 和订阅不再是彼此孤立的开关。
订阅更新到底改变什么
订阅更新主要改变服务器清单及其连接参数，不应自动改写所有本地偏好。客户端通常会把远程节点放入对应分组，同时保留本地路由、系统代理模式和部分界面设置。不同订阅格式对分组、标签和高级字段的表达能力不同，经过转换后可能出现字段丢失或命名变化。因此每次更换订阅格式后，应抽查至少一个节点的协议、安全层、传输与 flow，而不是只确认列表已经出现。
多个订阅来源应分组保存。分组不仅方便更新，也能避免同名节点难以追溯。删除订阅分组前先确认当前活动服务器是否属于该分组；更新后当前节点被移除时，客户端可能保持旧缓存，也可能要求重新选择。遇到连接突然失效，应先更新当前订阅并选择仍存在的节点，再处理更复杂的网络问题。
系统代理与 TUN 的选择
系统代理是应用主动读取代理地址后再连接本地端口，边界清晰、对系统路由影响较小，适合浏览器和标准桌面应用。TUN 从网络层接管流量，覆盖范围更广，适合不支持代理设置的程序和统一分流。二者不需要为了“更强”而同时叠加。多数情况下选择一个主要入口即可，叠加使用会增加回环和重复接管的判断成本。
| 项目 | 系统代理 | TUN |
|---|---|---|
| 接管范围 | 遵循系统或应用代理设置的流量 | 进入虚拟接口并匹配路由的流量 |
| 系统影响 | 主要修改代理配置 | 涉及虚拟接口、路由与 DNS |
| 适用场景 | 浏览器、常规桌面应用、单独配置的命令行工具 | 不读取代理的应用、统一分流、应用级接管 |
| 排查重点 | 本地端口、应用代理、系统代理残留 | 权限、默认路由、私有网段、DNS 与接口冲突 |
路由匹配顺序
路由规则一般按顺序匹配，命中后选择直连、代理或阻断出站。具体域名、特定网段和必须保留的局域网规则应放在宽泛规则之前。常见结构是：私有地址直连，明确域名集合按需要分流，其余流量进入默认出站。规则越多并不代表结果越准确，重复集合和交叉条件会让实际命中难以预测。
domainStrategy决定域名规则未直接命中时是否进一步解析 IP。IPIfNonMatch表示域名规则没有结果时再解析并尝试 IP 规则，兼顾域名匹配与 IP 数据库；完全依赖 IP 规则会增加 DNS 对结果的影响。下面是可合并到 Xray 根配置中的路由对象示例，出站标签需要与当前配置实际定义保持一致：
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": [
"geoip:private"
],
"outboundTag": "direct"
},
{
"type": "field",
"domain": [
"geosite:cn"
],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}示例中的最后一条是兜底规则，应位于具体规则之后。若配置还包含阻断广告、开发环境域名或特定服务直连，需要放在兜底规则前。关于 geosite 与 geoip 的组合、匹配顺序和三段式模板，可查阅路由规则分流实战。
DNS、FakeDNS 与泄漏路径
DNS 决定域名如何变成地址，也会影响域名规则与 IP 规则的先后关系。系统代理模式下，应用可能自己解析域名，也可能把域名交给代理；SOCKS 使用方式还会决定解析发生在本地还是远端。TUN 模式通常会集中处理 DNS，但仍要留意浏览器安全 DNS、应用内置解析和局域网名称服务。排查时先明确请求由谁解析，再讨论使用哪个 DNS 服务器。
FakeDNS 用保留地址建立域名映射，内核在后续连接中恢复原始域名。它能减少部分解析往返，并帮助 TUN 保留域名信息，但不适合所有应用。依赖真实 IP、局域网发现、某些点对点流程或自行校验解析结果的应用可能出现异常。启用前应保留一份普通 DNS 配置，出现问题时可以快速对照，而不是同时修改路由和节点。
REALITY 与传输参数核对
REALITY 配置常见于 VLESS 节点。客户端侧必须准确保存服务器地址、端口、用户标识、serverName、fingerprint、publicKey、shortId 和 flow。xtls-rprx-vision需要与服务端配置及节点协议保持一致。network 通常由服务端决定，不能看到连接失败就随意在 tcp、WebSocket 或 gRPC 之间切换。
握手失败时先核对字段，再检查系统时间和基础连通性。日志若显示连接服务器端口已经建立，但随后在安全握手阶段终止，说明本地代理与网络入口大体正常，重点应转向 SNI、公钥、shortId、指纹和 flow。若连服务器端口都无法到达，则优先检查地址、端口、当前网络和节点状态。分层判断比不断更换客户端设置更有效。
配置变更后的验证
每次修改订阅、路由或 DNS 后，先停止连接，再重新启动内核。清空日志并分别测试一个应直连的目标、一个应代理的目标和一个局域网目标。检查三者命中的出站标签是否符合预期。只测试单一网页无法证明分流规则完整，因为它可能包含多个域名、连接复用和缓存。
验证结束后记录当前客户端、订阅分组、活动节点、接管方式和自定义规则。桌面与 Android 使用同一订阅时，可以共享服务器参数，但系统代理、TUN 和应用分流需要按设备分别设置。把节点配置与设备接管配置分开管理，是跨平台保持稳定的关键。
配置常见问题与固定排查顺序
故障排查的核心是先确定失败层级，再处理对应变量。推荐顺序是：系统时间与网络、订阅与节点、内核启动、本地监听、流量接管、DNS、路由规则。顺序固定后，绝大多数问题不需要重装客户端。
第一步：确认基础网络、时间与订阅状态
先在关闭客户端接管的状态下确认当前网络能够正常连接常规站点，并校准日期、时间和时区。公司网络、公共无线网络和移动热点可能有不同的端口策略，同一节点在一个网络可用而另一个网络超时并不矛盾。随后检查订阅是否仍有效、账号是否到期、流量是否可用，并执行一次订阅更新。
如果更新订阅本身失败，问题发生在节点连接之前。查看日志中的 HTTP 状态、超时或解析信息，确认订阅地址完整且当前网络可访问。不要在这一阶段修改节点的协议字段，因为客户端尚未取得新的配置。节点列表能更新但全部连接失败，再进入下一步。
第二步：检查节点参数与服务器可达性
选择一个参数明确的节点，逐项核对地址、端口、协议、用户标识、安全层和传输。REALITY 继续检查 serverName、fingerprint、publicKey、shortId 与 flow。WebSocket 检查 path 与 host，gRPC 检查 serviceName。订阅转换后尤其要留意高级字段是否被保留。
日志中的超时只表示在限定时间内没有完成当前步骤，不等于原因唯一。连接服务器地址之前超时，可能是地址解析、端口不可达或当前网络限制；TCP 已建立后握手超时，重点检查安全层与服务端状态；连接很快被关闭，可能是参数不匹配或服务端主动拒绝。可按节点超时六步排查清单逐项对照。
第三步：确认内核启动和本地端口
清空日志，停止连接，再启动一次。首先寻找配置加载与内核启动结果，然后确认本地 HTTP、SOCKS 或 TUN 监听已经建立。若提示地址已被占用，退出其他客户端或修改冲突端口；关闭窗口不一定结束后台进程，应检查托盘、活动监视器、系统监视器或应用列表。
配置解析错误通常会明确指出字段类型、未知选项或 JSON 结构位置。自定义 JSON 出错时，先恢复到客户端生成的基础配置，再把自定义部分逐段合并。JSON 中不能加入注释，数组和对象结尾也不能保留多余逗号。内核能够持续运行后，才进入系统代理和流量接管排查。
第四步：判断应用流量是否进入客户端
启动节点后打开目标应用并发起一个全新请求，同时观察访问日志。完全没有记录，说明流量没有到达客户端。桌面端检查系统代理是否已启用、应用是否使用独立代理、终端是否设置了正确环境变量；Android 检查系统 VPN 授权与应用分流；TUN 场景检查虚拟接口和默认路由。
日志出现连接记录但目标行为异常，说明入口已建立，应继续检查出站、DNS 和路由。浏览器可能复用旧连接，测试前可以关闭相关标签页或重新启动浏览器。某些应用具有自己的 DNS 与代理设置，应分别检查，不能只依据系统设置推断。
第五步：拆分 DNS 与路由问题
域名失败而直接 IP 连接可用，通常需要检查 DNS。查看解析请求是否进入内核、使用了哪个服务器、是否被浏览器安全 DNS 绕开，以及 FakeDNS 是否适合当前应用。若 DNS 返回地址但连接走错出站，则检查 domainStrategy、规则顺序和 geosite、geoip 数据匹配。
只有部分站点失败时，记录失败域名及其命中规则，不要直接切换到全局模式长期使用。全局模式可以用于证明节点整体可工作，但最终仍应恢复规则模式并修正具体条件。局域网失败时优先确认私有地址直连，本地域名解析失败时检查系统搜索域和本地 DNS 是否被覆盖。
| 现象 | 优先检查 | 下一步 |
|---|---|---|
| 订阅无法更新 | 地址完整性、账号状态、当前网络、日志状态 | 更换网络对照，不修改节点字段 |
| 内核启动后立即退出 | 配置解析、端口占用、文件权限 | 恢复基础配置并重新启动 |
| 浏览器无日志 | 系统代理、应用独立代理、本地端口 | 新建连接并观察访问日志 |
| TUN 后局域网失效 | 私有网段、自动路由、DNS 与其他虚拟接口 | 添加直连规则并单独测试 |
| REALITY 握手失败 | 时间、SNI、公钥、shortId、指纹、flow | 逐字段与服务端配置比对 |
| 网络切换后停止传输 | 旧连接、默认路由、后台限制 | 停止内核并重新建立连接 |
平台特有恢复动作
Windows 在强制退出后，可检查系统代理是否仍指向本机失效端口，并确认旧进程已经结束；TUN 网络未恢复时，先退出客户端，再重新启用当前网络适配器。macOS 检查当前网络服务的代理项和虚拟网络授权，不要删除整个网络配置。Linux 查看虚拟接口、默认路由、DNS 服务和进程监听，远程设备先保证管理回程。Android 检查系统 VPN 是否仍由旧应用占用、电池策略是否冻结后台，以及网络切换后是否完成重连。
这些恢复动作只处理系统接管残留，不会修复节点参数。若恢复普通网络后客户端仍无法连接，应重新回到日志层级。反复重装会清除部分上下文，却不能改变订阅状态、服务端参数和当前网络条件，因此只在确认应用文件损坏或升级迁移异常后使用。
如何整理有效日志
提交或自行保存排查记录时，应包含平台、客户端名称、接管方式、协议类型、问题发生时间、操作步骤和相关错误行。订阅地址、用户标识、公钥之外的账号凭据及完整分享链接应隐藏。日志要从清空后的一次完整复现中截取，避免混入多个节点和多次启动记录。
有效描述应类似：“Windows 使用 v2rayN，系统代理模式；更新订阅成功，内核监听成功；浏览器请求能出现在日志中，但 REALITY 握手在选择活动节点后失败。”这类描述已经明确排除了订阅、内核和流量入口三层。仅写“无法使用”则无法判断从哪里开始检查。更多高频问答可进入疑难解答，其中按基础认知、安装配置、使用技巧和故障排查分类整理。
建立可回退的稳定配置
问题解决后，将当前订阅分组、活动节点、路由模式、DNS 策略、本地端口和平台权限记录下来。自定义配置另存一份基线，后续修改从副本开始。桌面端更新前备份配置，Android 保留订阅来源与关键节点参数。稳定配置的价值不在于永远不变，而在于每次实验后都能快速回到已验证状态。
完整验收应覆盖启动、订阅更新、节点握手、系统接管、直连规则、代理规则、局域网访问和网络切换。四个平台的按钮位置不同，判断逻辑始终相同：先确认数据来源，再确认内核，再确认流量入口，最后确认 DNS 与出站。按此顺序维护，配置规模增加后仍然可以定位到具体层级。