01 / PREPARATION
通用准备：平台、架构与配置来源
先区分客户端、内核与订阅
完整的 V2Ray 使用链路由三个部分组成：图形客户端负责界面、系统代理开关、日志和配置管理；内核负责解析协议、建立出站连接并执行路由；订阅或分享链接提供节点参数。v2rayN 是 Windows、macOS、Linux 上的桌面客户端，能够统一管理订阅、路由和系统代理。Android 上常用 v2rayNG 或 v2flyNG，前者采用 Xray 内核方向，后者采用 V2Fly 内核方向。两者界面流程相近，但可识别的协议扩展和高级参数并不完全相同。
客户端本身不会自动生成可用节点。安装完成后仍需导入有效订阅地址、单节点分享链接，或手工录入服务器参数。订阅地址通常返回一组节点，便于统一更新；以 vmess://、vless:// 开头的分享链接通常只代表一个节点。两类内容不要混填：订阅地址应添加到“订阅分组”或“订阅设置”，单节点链接应通过剪贴板导入、扫描二维码或手工添加。具体差异可继续阅读分享链接与订阅地址说明。
确认处理器架构和安装包类型
下载前先确认设备架构。Windows 与多数 Linux 桌面电脑通常使用 x64；采用 Apple 芯片的 Mac 使用 arm64，较早的 Intel Mac 使用 x64；近年的主流 Android 设备通常使用 arm64。架构选错时，常见结果是安装程序拒绝运行、系统提示应用不兼容，或程序启动后立即退出。无法判断 Android 架构时可选通用包，但通用包体积通常更大，已明确设备为 arm64 时直接选择 arm64 包更合适。
| 平台 | 首选客户端 | 常见架构 | 安装包方向 |
|---|---|---|---|
| Windows | v2rayN | x64 | 桌面版或经典 WPF 版 |
| macOS | v2rayN | arm64 / x64 | 对应芯片的 DMG |
| Linux | v2rayN | x64 / arm64 | deb 或 rpm |
| Android | v2rayNG | arm64 / 通用 | 对应架构的安装包 |
记录配置边界
开始配置前建议记录四项信息：订阅名称、当前选中的节点、代理模式、是否启用 TUN。后续出现无法联网时，可以判断问题发生在订阅解析、节点连接、系统代理还是透明接管层。首次安装不要同时修改路由、DNS、端口和内核参数。先使用默认设置完成一次可验证的连接，再逐项启用分流和 TUN；一次改变多个变量会让日志难以对应具体原因。
还要确认系统时间与时区正确。部分协议的握手过程依赖时间窗口，设备时间相差过大时，表面现象可能只是连接超时。随后检查本地是否已有其他代理工具占用监听端口。常见本地端口包括 SOCKS、HTTP 和混合代理端口，不同客户端默认值可能变化，因此应以客户端设置页实际显示为准，不要照抄其他设备的端口。若计划让浏览器或开发工具单独使用代理，需要记录客户端当前监听地址和端口。
理解配置保存与敏感信息
订阅地址和节点链接可能包含访问参数，应按账号凭据处理。不要把完整地址粘贴到公开日志、截图或公开讨论中。排错时通常只需要保留协议类型、传输方式、TLS 状态、服务器端口和错误信息，可隐藏服务器地址、用户标识与订阅参数。更换设备时优先在新设备重新添加订阅，而不是直接复制整个客户端数据目录，因为不同平台的路径、权限和系统代理状态并不兼容。
准备阶段的完成标准不是“程序已经打开”，而是客户端与平台匹配、订阅来源明确、系统时间正常、端口没有明显冲突，并且知道当前将使用系统代理还是 TUN。完成这些检查后再进入对应平台章节，可显著减少安装完成却无法判断故障位置的情况。
02 / WINDOWS
Windows：v2rayN 安装、系统代理与 TUN
桌面版与经典 WPF 版的选择
Windows 平台首选 v2rayN。下载中心同时提供桌面版与经典 WPF 版：桌面版采用新一代跨平台界面，适合新安装和需要与 macOS、Linux 保持操作习惯一致的用户；经典 WPF 版沿用成熟的 Windows 界面结构，适合已经熟悉旧版菜单位置或需要传统桌面交互的环境。两者都能完成订阅管理、节点选择、系统代理和路由配置，不需要同时安装。若旧版配置仍在使用，先导出或记录订阅，再安装准备采用的版本。
进入Windows 下载入口后选择 x64 安装包。安装前关闭正在运行的旧客户端，避免配置文件被占用。若使用安装程序，按向导选择当前用户或系统允许的位置；若下载的是可直接运行的发行形式，应解压到具备写入权限的固定目录，不要长期放在临时目录。客户端需要保存订阅、日志与本地配置，目录只读会导致设置看似成功但重启后丢失。
首次启动与订阅导入
首次启动后先打开订阅设置，新建一个易识别的分组名称，再粘贴订阅地址并执行更新。更新完成后回到节点列表，确认至少有一条配置被解析出来。若列表为空，不要立即开启系统代理，应先查看订阅更新结果：返回内容为空、地址失效、网络请求失败和订阅格式不兼容，都会造成“添加成功但没有节点”。如果拿到的是单节点分享链接，应复制完整链接，再使用“从剪贴板导入”一类入口，而不是放进订阅地址栏。
选择节点后，可先使用客户端提供的连接测试或直接建立一次连接。测试结果只用于判断目标是否能够握手，不代表所有网站都会使用该节点。真正验证时应开启系统代理，再访问一个明确使用系统代理的浏览器页面。部分已经运行的应用会缓存代理状态，切换系统代理后仍沿用旧连接；遇到这种情况，应完全退出该应用后重新打开。
系统代理模式的工作范围
系统代理主要影响遵循 Windows 代理设置的应用。选择“自动配置系统代理”或含义相同的模式后，v2rayN 会把系统代理指向本地监听端口。关闭客户端前应先恢复系统代理，否则系统可能保留指向本地端口的设置，表现为客户端退出后浏览器无法访问网络。正常退出流程通常会自动处理，但强制结束进程、系统异常关机或权限拦截时仍可能残留。
可在 Windows 的网络与 Internet 代理设置中检查代理开关。若手动代理仍指向 127.0.0.1，而 v2rayN 已停止运行，应关闭该开关后再测试直连。系统代理不是对所有程序的强制接管：部分游戏、命令行程序、虚拟机和自带网络栈的软件可能忽略它。这类场景需要在应用内指定 HTTP 或 SOCKS 代理，或者评估使用 TUN。
TUN 模式与权限
TUN 会创建虚拟网络接口，让更多不读取系统代理的流量进入客户端。启用时通常需要管理员权限，首次创建接口可能触发系统确认。先退出其他会创建虚拟网卡的网络工具，再以正常方式启动 v2rayN并开启 TUN。不要同时开启多个透明接管工具，否则路由表和 DNS 可能互相覆盖。TUN 启动后应先测试普通网页，再测试原本不遵循系统代理的应用；若所有网络同时中断，优先关闭 TUN恢复基础网络。
开机启动、日志与常见阻断
需要开机运行时，可启用 v2rayN 的开机启动选项，但不要把“程序自启动”和“自动开启系统代理”混为一项。前者只保证客户端进程启动，后者决定启动后是否修改系统代理。共享电脑或经常切换网络的设备，更适合只启动客户端并手动确认节点后再开启代理。笔记本从休眠恢复后若节点失效，可先切换一次节点或重启内核，不必立即重装客户端。
启动失败或闪退时，先确认安装目录可写、旧进程已退出、本地端口未被占用，再检查系统运行环境与安全策略。日志中出现“address already in use”通常表示监听端口冲突；出现配置解析错误则应检查最近导入的节点或自定义路由。不要删除全部配置作为第一步，可先备份配置目录，然后移走最近新增的配置并重启。更完整的启动故障分支可参考客户端打不开或闪退排查。
Windows 章节的完成标准是：订阅可以更新、节点能够被选中、系统代理开启后浏览器走预期链路、关闭系统代理后直连恢复。只有需要覆盖不遵循系统代理的程序时才继续启用 TUN。每次调整后保留一段对应日志，有助于区分节点不可用、代理残留、端口冲突与虚拟网卡问题。
03 / MACOS
macOS：芯片选择、权限放行与代理接管
确认芯片并安装 v2rayN
macOS 使用 v2rayN 桌面版。下载前打开系统信息或“关于本机”，查看处理器或芯片字段：显示 Apple 芯片时选择 arm64 DMG，显示 Intel 处理器时选择 x64 DMG。安装包架构与芯片不匹配时，可能无法打开，也可能依赖兼容转换层运行，增加排错变量。进入macOS 下载入口后按芯片选择文件，打开 DMG，再把应用移动到“应用程序”目录。
首次启动若被系统阻止，不要反复双击。先在“隐私与安全性”设置中查看最近被拦截的应用记录，确认名称与刚安装的 v2rayN 一致后执行允许打开。也可以在“应用程序”中对应用使用右键打开，使系统显示一次明确确认。完成放行后，后续通常可正常从启动台或应用程序目录启动。具体界面路径可能随系统小版本调整，可参考macOS 首次打开与网络权限处理。
订阅导入与菜单栏状态
客户端启动后先确认主窗口或菜单栏图标已出现。添加订阅时建立分组、粘贴地址、保存并更新，然后在节点列表中选择一条配置。若复制地址后无法粘贴，检查剪贴板内容是否包含前后空格、换行或聊天软件添加的说明文字。订阅地址必须是一段连续内容。单节点链接则使用剪贴板导入入口，导入后检查协议、端口、传输方式和 TLS 等字段是否完整。
macOS 应用关闭窗口不一定代表进程退出。点击窗口关闭按钮后，v2rayN 可能仍驻留在菜单栏并继续维持代理。排错或准备重启时，应从菜单栏执行退出，随后在活动监视器确认相关进程已经结束。若只是关闭窗口却继续安装另一份应用，可能出现两个实例同时争用本地端口。
系统代理与网络服务
开启系统代理后，客户端会调整当前网络服务的代理配置。macOS 可以同时存在 Wi-Fi、有线网卡和其他网络服务，切换网络时应确认当前活动服务已应用代理。若 Wi-Fi 下正常、接入有线网络后失效，先重新切换一次系统代理，不要直接判断节点故障。浏览器和多数桌面应用会读取系统代理，但命令行工具是否遵循设置取决于工具自身；需要时可在当前终端会话中设置代理环境变量。
export HTTP_PROXY="http://127.0.0.1:本地HTTP端口"
export HTTPS_PROXY="http://127.0.0.1:本地HTTP端口"
export ALL_PROXY="socks5://127.0.0.1:本地SOCKS端口"
# 当前终端恢复直连
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY上例中的端口应替换为 v2rayN 设置页实际显示的监听端口。环境变量只影响从当前终端启动且读取这些变量的程序，不会替代系统代理，也不会自动覆盖其他终端窗口。排查命令行访问时，先执行 env 查看是否残留旧代理变量；客户端端口已经变化而终端仍指向旧端口，是常见的“浏览器正常但命令行失败”原因。
TUN、网络扩展与授权
启用 TUN 时，系统可能要求输入本机管理员凭据，或确认添加网络扩展。授权应在系统弹窗和设置页内完成。若拒绝授权，客户端仍可能正常运行系统代理，但 TUN 无法建立。开启后可以在系统网络设置中看到新增的网络接口或相关状态。此时不要手动删除接口；应先在 v2rayN 中关闭 TUN并退出客户端，再处理遗留项。
公司网络、访客 Wi-Fi 和需要网页认证的热点应先完成网络登录，再开启 TUN。否则认证页面可能被代理或 DNS 接管阻断。切换网络后若显示已连接但没有数据，按“关闭 TUN—确认直连恢复—重新更新订阅—重新启用”的顺序处理。这样可以避免在基础网络尚未建立时反复修改节点。
休眠恢复与代理残留
Mac 从休眠恢复、Wi-Fi 漫游或切换热点后，原有连接可能已经失效。先观察客户端日志是否重新建立出站，再测试访问。若系统代理仍开启但本地内核没有恢复，应用会持续把流量发往没有监听的端口。可先关闭系统代理，确认直连网络正常，再重启客户端并重新开启。强制退出后出现全局无法联网时，也应在当前网络服务的代理详情中检查 HTTP、HTTPS 与 SOCKS 项是否仍被勾选。
需要登录后自动运行时，可使用客户端提供的启动选项或系统登录项管理，但应避免重复添加。系统登录项和客户端内部自启动同时配置，可能导致短时间内启动两个进程。稳定配置应只保留一种启动入口，并明确是否自动修改系统代理。macOS 章节的验收顺序是：应用通过系统权限检查、订阅更新成功、菜单栏状态明确、系统代理可开可关、切换网络后能够恢复；TUN 则作为独立层验证，不与首次安装同时处理。
04 / LINUX
Linux：deb、rpm、桌面代理与自启动
选择发行版包格式
Linux 桌面平台使用 v2rayN。Debian、Ubuntu 及其常见衍生系统选择 deb；Fedora、Rocky Linux、openSUSE 等采用 rpm 包管理体系的环境选择 rpm。处理器为常见桌面 x64 时选择 x64 包，arm64 设备则使用对应 arm64 包。包格式与架构必须同时匹配，仅凭桌面环境名称不能判断包类型。可在终端执行以下命令确认架构与发行版信息：
uname -m
cat /etc/os-releasex86_64 通常对应 x64，aarch64 通常对应 arm64。发行版信息中的 ID 与 ID_LIKE 可辅助判断包管理体系。进入Linux 下载入口后选择相应文件。不要把软件包当作压缩文件直接解开运行，使用系统包管理器安装可以同时登记桌面入口、依赖与卸载信息。
安装 deb 或 rpm
将终端切换到下载目录后，可使用系统包管理器安装。文件名由当前下载内容决定，输入命令时可以键入前几个字符后按 Tab 补全，避免手工拼写。以下命令中的文件名仅表示已经下载到当前目录的包：
# Debian / Ubuntu 系
sudo apt install ./v2rayN-downloaded-package.deb
# Fedora 系
sudo dnf install ./v2rayN-downloaded-package.rpm使用 apt install ./文件.deb 或 dnf install ./文件.rpm，比直接调用底层解包命令更容易处理依赖。安装完成后从桌面应用列表启动 v2rayN。若找不到入口，可先在终端输入应用启动命令，观察是否有缺失库、显示服务或权限错误，再刷新桌面应用数据库。不要为了修复一个缺失依赖而批量安装来源不明的运行库，应根据包管理器给出的具体包名处理。
桌面代理与环境变量
GNOME、KDE 等桌面环境都有网络代理设置，但设置位置和自动应用范围不同。v2rayN 的系统代理功能会尽量对接桌面代理配置，验证时先查看桌面系统设置中的代理模式是否已经变化，再用浏览器测试。只在终端导出 HTTP_PROXY 并不等于整个桌面已开启代理；反过来，桌面代理已启用，也不保证所有命令行工具会读取它。
# 仅对当前 shell 会话设置
export http_proxy="http://127.0.0.1:本地HTTP端口"
export https_proxy="http://127.0.0.1:本地HTTP端口"
export all_proxy="socks5://127.0.0.1:本地SOCKS端口"
# 清理当前会话
unset http_proxy https_proxy all_proxy本地监听默认只绑定回环地址时，只有本机程序可以连接。若要让同一局域网中的其他设备使用该端口，需要显式允许局域网连接、调整监听地址并配置防火墙。这会扩大服务暴露范围，不属于首次安装的必要步骤。没有明确需求时保留回环监听即可。
TUN、能力授权与路由
Linux 上的 TUN 需要系统提供 /dev/net/tun，并需要创建接口、修改路由和处理 DNS 所需的权限。桌面客户端可能通过授权对话框申请权限，也可能依赖已安装的权限管理组件。启用失败时先检查 TUN 设备是否存在，再查看日志中的“permission denied”“operation not permitted”或路由添加失败信息。不要直接长期以 root 身份运行整个图形客户端，这会让用户目录下的配置文件归属发生变化，之后普通用户可能无法保存设置。
虚拟机、容器桌面和受限企业环境可能禁用 TUN。此时系统代理仍然可用，应先保留可工作的系统代理方案。若 TUN 开启后只有域名访问失败而直接连接地址正常，重点检查 DNS；若所有流量立即中断，则检查默认路由、策略路由和其他虚拟网络软件是否冲突。关闭 TUN 后应确认虚拟接口和附加路由已被清理，再继续下一轮测试。
登录自启动与桌面会话
图形客户端应在用户桌面会话建立后启动。可优先使用 v2rayN 内置自启动设置；若桌面环境未正确处理，可使用用户级 systemd 服务，但服务必须等待图形会话和网络就绪，并使用当前用户身份。完整操作可参考Linux 安装与开机自启动设置。配置自启动后要实际注销并重新登录测试，不要只运行一次服务命令就判断成功。
自启动失败时，查看用户级日志而不是系统级服务列表。常见原因包括程序路径在更新后变化、显示环境变量不可用、桌面密钥环尚未解锁，以及网络尚未取得地址。对于经常移动办公的设备，建议客户端自动启动但不要立即强制开启 TUN，让网络认证和桌面会话先完成，再由用户确认当前网络环境。
卸载、升级与配置保留
升级时使用与当前发行版和架构一致的新包覆盖安装即可。安装前先正常退出客户端，避免内核进程和配置文件仍被占用。包管理器卸载通常不会自动删除用户主目录中的全部配置，因此重装后旧订阅可能继续出现。若排错目标是建立一份全新配置，应先备份用户配置目录，再把旧目录改名，不要直接删除。这样可以随时恢复订阅和路由规则。
Linux 章节的完成标准包括：系统包管理器能识别 v2rayN、桌面入口可以启动、订阅与节点保存在当前用户目录、桌面代理可恢复直连、TUN 关闭后路由表正常。若问题只发生在终端工具，优先检查环境变量；若只发生在图形应用，检查桌面代理；若整个系统同时受影响，再检查 TUN、DNS 与路由。
05 / ANDROID
Android：v2rayNG、v2flyNG 与系统 VPN 接管
客户端与架构选择
Android 首选 v2rayNG，需要使用 V2Fly 内核方向时可选择 v2flyNG。两款客户端都提供 arm64 与通用包。2015 年后的主流手机通常采用 arm64，但仍应以设备信息为准；明确为 arm64 时选择 arm64 包，无法确认时选择通用包。不要同时让两款客户端保持连接，因为系统同一时间通常只允许一个此类 VPN 会话处于活动状态。
从Android 下载入口取得安装包后，系统可能要求允许当前浏览器或文件管理器安装应用。授权只需对实际用于打开安装包的应用开启。安装结束后可关闭这项来源权限。若系统提示无法安装，先检查已有同名应用是否来自不同签名来源、存储空间是否充足，以及下载文件是否完整到达设备；不要反复点击安装覆盖错误信息。
导入订阅与单节点链接
打开 v2rayNG 或 v2flyNG 后，订阅地址应添加到订阅分组，再执行更新。更新完成后从配置列表选择节点。单节点分享链接可复制到剪贴板，再使用从剪贴板导入功能；二维码则使用客户端扫描入口，并按系统要求授予相机权限。导入后如果列表出现重复项，通常是多次执行了剪贴板导入，或同一订阅在多个分组中重复添加，应保留来源清晰的一份。
移动端剪贴板可能在复制时截断长链接。导入失败时先把内容粘贴到本地文本编辑器，确认开头协议、末尾参数和中间字符连续。不要在即时通信窗口中手工编辑编码后的分享链接，一个字符变化就可能导致解析失败。订阅更新后节点没有变化时，先确认当前查看的是对应订阅分组，再查看更新提示，避免把“服务器端内容未变化”误判为客户端故障。
首次连接与系统确认
选择节点后点击连接，Android 会显示创建 VPN 连接的系统确认框。只有完成该确认，状态栏才会出现连接标识。客户端界面显示已选择节点，不等于系统流量已经进入代理。首次验证可先保持默认路由与 DNS，连接后打开浏览器测试；若浏览器正常，再测试其他应用。出现连接标识但所有应用均无法访问时，应先断开连接，确认移动数据或 Wi-Fi 本身可用。
从 Wi-Fi 切换到移动网络时，既有连接可能需要重新建立。系统省电策略也可能在锁屏后限制后台进程，使连接状态图标仍在但内核已停止传输。可在系统的电池设置中允许客户端必要的后台运行，并避免一键清理工具强制结束进程。不同设备厂商的设置名称不同，核心目标是允许客户端在连接期间维持前台服务和网络活动。
分应用代理与绕过规则
Android 客户端通常提供分应用代理，可选择仅让指定应用进入代理，或让选中的应用绕过代理。两种逻辑方向相反，配置前先确认当前模式。首次使用建议保持全局应用范围，验证基础连接后再做筛选。若启用“仅代理已选应用”，但忘记勾选浏览器，测试会表现为节点完全没有作用；若采用“绕过已选应用”，则被勾选的应用会直接连接。
系统组件、下载管理器和应用内嵌网页可能由不同进程发起请求。只选择主应用并不一定覆盖它调用的全部系统服务。遇到登录页能打开但下载失败时，可以临时关闭分应用限制进行对照。确认问题来自应用筛选后，再逐步添加相关组件，而不是立即修改节点协议和 DNS。
按需连接、始终开启与局域网访问
系统设置中的始终开启 VPN 会在网络恢复后尝试维持客户端连接，适合配置稳定且长期使用同一客户端的设备。启用“阻止未通过 VPN 的连接”会提高接管范围，但节点不可用或客户端未启动时，设备可能完全无法联网。首次安装阶段不建议同时打开这两个系统选项，应先确认订阅更新、节点切换和断开恢复都正常。
访问打印机、投屏设备、路由器管理页或其他局域网服务时，可能需要启用绕过局域网规则。典型私有地址包括 10.0.0.0/8、172.16.0.0/12 与 192.168.0.0/16。如果开启代理后只能访问互联网却找不到局域网设备，应检查路由是否把私有地址也送入远端出站。不要把整个未知地址段随意设为直连，应以实际局域网范围为准。
日志、耗电与后台故障
移动端排错时先查看客户端日志的时间点是否与刚才的操作一致。连接超时、DNS 解析失败、配置解析失败和系统主动停止服务属于不同分支。若应用从后台返回后立即断开，重点检查电池优化；若切换节点后仍显示旧节点，先断开再重新连接；若只有某个应用失败，检查分应用设置和该应用是否使用私有 DNS或特殊网络栈。
持续连接会维持前台服务并产生正常的网络与电量消耗。耗电明显异常时，先排除节点频繁重连、信号弱导致的网络切换和日志级别过高。不要把日志长期设为最详细级别，完成排错后恢复常规级别。Android 章节的完成标准是：系统连接确认已通过、浏览器能够验证、断开后直连恢复、网络切换后可重新建立连接，分应用规则与后台策略均符合实际使用范围。
06 / SUBSCRIPTION AND ROUTING
订阅管理、节点选择与路由分流
订阅更新的完整链路
订阅更新不是简单的“下载一个列表”。客户端先请求订阅地址，读取返回内容，再按支持的格式解析节点，最后写入指定分组。故障可能发生在任何一步：请求阶段受网络或地址状态影响，解析阶段受格式和内核能力影响，写入阶段则可能受到配置目录权限或分组设置影响。更新后应同时检查提示信息、分组名称和节点数量变化，不要只看按钮是否点击成功。
同一个订阅不应在多个分组重复添加。重复订阅会生成名称相近的节点，后续难以判断当前选择来自哪次更新。建议按用途或来源建立稳定分组，名称中不必记录版本和日期；更新时间由客户端状态或日志提供。删除订阅前先确认是否勾选“同时删除该订阅下节点”，避免留下失去来源的旧配置。订阅地址变更时，优先编辑原分组并更新，而不是新建多个临时分组。
节点参数与兼容边界
节点能否导入取决于客户端和内核是否识别其协议、传输层及附加参数。VMess、VLESS 等协议只描述连接的一部分，实际配置还可能包含 TCP、WebSocket、gRPC、TLS、REALITY、服务名、路径和服务器名称等字段。导入成功但连接失败时，应检查关键字段是否在复制或订阅转换过程中丢失。不同客户端之间迁移时，最好重新导入原始订阅，不要把某一客户端生成的内部配置文件直接交给另一平台。
节点名称只是便于识别的标签，不能代表实际线路质量。测试时应选择一个节点建立真实连接，并结合日志判断。单次延迟测试失败可能来自目标不响应探测、当前网络丢包或协议未完成握手；单次显示较低延迟也不代表持续传输稳定。排错目标是确认“能否建立连接、能否完成域名解析、请求是否进入正确出站”，而不是追求某个固定数字。
路由规则的匹配逻辑
路由规则通常按域名、地址、端口、网络类型或进程信息匹配，再把流量送到代理、直连或阻断出站。规则顺序很重要：更具体的条件应放在通用规则之前，最终再设置默认出站。若一条广泛规则提前匹配，后面的精确规则就不会生效。修改前记录当前路由模式，完成后分别测试一个应直连的目标和一个应使用代理的目标，确认两个方向都符合预期。
域名规则与地址规则处理的是不同阶段。应用先请求域名，DNS 返回地址后，内核可能继续依据解析结果匹配地址规则。启用域名嗅探时，内核还可能从流量中恢复目标域名，用于进一步分流。嗅探不是越多越好：某些非标准协议、加密连接或局域网服务可能不适合被改写。首次配置保持客户端预设，再针对明确问题调整。
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": [
"geoip:private"
],
"outboundTag": "direct"
},
{
"type": "field",
"domain": [
"domain:example.com"
],
"outboundTag": "proxy"
}
]
}
}以上示例展示规则结构：私有地址进入直连出站，指定示例域名进入代理出站。实际使用时，outboundTag 必须与当前配置中已有的出站标签一致；若客户端使用不同标签名称，直接复制会导致规则找不到目标出站。图形客户端通常会提供预设路由界面，优先在界面中修改，只有明确理解生成结果时再编辑底层 JSON。
系统代理、PAC 与全局路由
系统代理负责把遵循系统设置的应用送到本地端口，路由规则则在流量进入内核后决定走哪个出站。这两个层次不要混淆。应用没有进入本地代理时，内核路由写得再完整也不会生效；应用已经进入代理但被规则送往直连时，则表现为“客户端开启了但目标仍直连”。PAC 或自动配置脚本还会在系统代理层先做一次选择，排错时应确认到底是 PAC 没有选中，还是内核路由选择了直连。
需要简单稳定的方案时，可让系统代理把浏览器流量统一送入客户端，再由内核路由决定直连和代理。需要接管更多应用时再使用 TUN。不要同时启用多个来源的 PAC、自定义浏览器代理扩展和系统代理，这会产生多层决策，导致同一域名在不同应用中走向不同。保留单一入口，日志才能准确反映请求。
订阅更新后的安全变更流程
更新订阅可能删除旧节点、增加新节点或改变名称。更新前正在使用的节点若被移除，客户端可能切换到其他配置，也可能保留失效引用。更新后应确认当前选中项仍存在，再重新连接。自定义路由若按节点标签指向特定出站，还要检查标签是否随更新改变。分组内节点较多时，使用清晰的订阅分组和固定路由出站比依赖展示名称更稳定。
推荐的变更顺序是：记录当前节点和路由模式，更新订阅，确认解析结果，选择节点，先在默认路由下测试，再恢复自定义规则。若更新后立即失败，可切回更新前仍保留的节点进行对照。订阅与路由问题还可在术语表中查阅协议、出站、分流和 DNS 等概念，避免把界面标签当成同一层配置。
07 / TUN AND DNS
TUN、DNS 与系统网络边界
何时需要 TUN
TUN 的作用是通过虚拟网络接口接收系统流量，覆盖不读取系统代理的程序。浏览器、常规桌面应用已经能通过系统代理正常工作时，不必为了“配置更完整”而强制开启 TUN。游戏启动器、部分命令行工具、独立网络栈应用或需要统一接管的场景，才是评估 TUN 的主要理由。TUN 增加了路由、DNS、权限和虚拟接口四个变量，功能范围更广，排错链路也更长。
启用前应关闭其他会修改默认路由或创建虚拟网卡的工具，并记录系统代理状态。多数情况下，TUN 与系统代理不需要重复承担同一批流量；具体是否同时开启取决于客户端实现。若不确定，先按照客户端预设使用。启用后立刻验证三类目标：普通域名、局域网地址、一个不遵循系统代理的程序。任何一类异常都应单独记录，不要只用“能否打开网页”概括结果。
严格路由与流量回环
TUN 需要避免把客户端自身发往服务器的连接再次送回 TUN，否则会形成回环。图形客户端通常会自动排除内核进程、服务器地址或特定接口。手工修改路由时，必须保留这类排除规则。典型回环现象是启用 TUN 后日志快速重复连接、流量计数异常增长，但任何请求都无法完成。此时先关闭 TUN，不要继续切换节点；恢复网络后再检查排除路由。
严格路由用于减少流量绕过，但可能影响虚拟机、容器、局域网发现和企业内部网络。启用后若局域网设备消失，应检查私有地址是否直连、组播和广播是否被接管，以及实际活动接口的优先级。Windows 的虚拟网卡、macOS 的网络扩展、Linux 的策略路由实现不同，不能把一个平台导出的路由表直接套到另一个平台。
DNS 请求经过哪些层次
访问域名时，应用可能使用系统 DNS、浏览器内置解析、加密 DNS 或客户端接管的 DNS。客户端日志没有出现域名请求，并不一定表示应用没有联网，可能是应用自行完成了解析。相反，能解析出地址也不代表出站连接一定成功。排错要分成两步：先确认域名是否得到合理地址，再确认到该地址的连接由哪个出站处理。
开启 TUN 后，客户端可能接管系统 DNS 并把请求转发到配置的服务器。若出现所有域名失败但直接使用地址仍可访问，重点检查 DNS 监听端口、上游可达性和端口冲突。若仅部分域名解析异常，检查分流 DNS、缓存和域名规则。修改 DNS 后应重启相关连接或清理系统缓存，否则旧结果仍可能被应用继续使用。
| 现象 | 优先检查 | 对照方法 |
|---|---|---|
| 域名全部失败 | DNS 监听、上游 DNS、端口占用 | 关闭 TUN 后验证系统解析 |
| 只有局域网域名失败 | 本地 DNS、私有域名规则 | 直接访问局域网地址 |
| 解析成功但连接超时 | 节点、出站、路由规则 | 查看连接阶段日志 |
| 切换节点后仍用旧结果 | 系统与应用 DNS 缓存 | 重启应用并重新连接 |
Fake DNS 与域名映射
部分 TUN 配置会使用 Fake DNS：先向应用返回一段内部映射地址，再由客户端在收到连接时恢复原始域名。这种方式有利于保留域名信息并执行路由，但要求映射地址段、路由和客户端状态保持一致。如果客户端退出后映射仍被系统或应用缓存，访问可能暂时失败。遇到此类现象，应关闭 TUN、恢复系统 DNS并清理相关缓存，再重新连接。
Fake DNS 不适合随意与其他本地 DNS 服务叠加。若系统中已有广告过滤 DNS、本地开发解析或容器 DNS，应先画清请求链路：谁监听本地端口、谁是上游、哪个组件负责域名规则。两个服务争用同一端口会直接启动失败，循环互相转发则会表现为持续超时。稳定方案应只有一个明确的系统入口，再由该入口转发到后续服务。
局域网、热点与虚拟环境
开启 TUN 后访问 NAS、打印机、路由器管理页失败，通常与私有地址路由或本地 DNS 有关。先直接访问设备地址；地址可达但主机名不可达时，处理本地 DNS；地址也不可达时，检查私有网段是否被错误送入代理。设备开启热点共享时，其他设备的流量是否进入 TUN 取决于系统转发与客户端能力，不能根据本机连接状态推断。
虚拟机和容器往往拥有独立网桥、DNS 与路由。宿主机系统代理通常不会自动进入虚拟环境，TUN 也可能因为接口优先级只覆盖部分流量。排错时分别在宿主机与虚拟环境中查看默认路由和 DNS，不要把容器内部连接失败归因于节点。若只需让开发工具使用代理，在工具或环境中显式设置本地代理地址往往比扩大 TUN 接管范围更容易维护。
稳定的启停顺序
启用顺序建议为：确认基础网络可用，启动客户端，更新订阅并选择节点，验证系统代理，再开启 TUN。关闭时先停 TUN，确认虚拟接口和附加路由清理，再恢复系统代理，最后退出客户端。系统异常重启后若网络不通，应按相反方向检查遗留状态：系统代理是否仍指向本地、虚拟接口是否存在、DNS 是否仍指向已停止的监听端口。
本章的验收标准是：TUN 开关前后网络状态可预测，局域网范围明确，DNS 入口只有一个，客户端退出后系统能够恢复。只要系统代理已经覆盖实际应用，就可以保留更简单的配置；更广的接管范围不等于更适合当前设备。
08 / TROUBLESHOOTING
配置常见问题与分层排错
先建立故障分层
有效排错需要先判断问题位于哪一层。第一层是设备基础网络，关闭客户端后应能正常直连；第二层是订阅与配置，客户端应能解析出节点；第三层是内核连接，日志应显示出站建立或明确错误；第四层是系统接管，应用流量必须进入本地代理或 TUN；第五层是路由与 DNS，请求应被送到预期出站。跳过前面的层次直接修改高级参数，通常会让现象更复杂。
每次只改变一个变量，并记录改变前后的结果。例如节点无法连接时，先在同一网络下切换一个节点；如果全部失败，再检查订阅与网络；只有一个失败时，问题更可能位于该节点配置。浏览器失败但客户端测试成功时，检查系统代理；系统代理正常而某个独立应用失败时，再检查应用代理或 TUN。这样的对照比反复重装更有信息量。
订阅更新失败
订阅更新失败时先确认地址完整、没有前后空格，且被添加到订阅设置而非单节点导入入口。随后查看更新提示是网络请求失败、返回为空还是解析失败。请求失败可以在基础网络恢复后重试；返回为空需要确认订阅来源状态；解析失败则检查客户端是否支持返回格式。不要把订阅地址改写成分享链接，也不要手工删除其中看似多余的查询参数。
更新成功却没有新增节点时，检查当前查看的分组、过滤条件和重复处理规则。有些订阅更新会覆盖原分组而不是追加；服务器端节点没有变化时，列表自然保持原状。若旧节点仍可用而新节点缺失，可以新建临时分组对照更新结果，但确认后应合并或删除临时分组，避免长期重复。
节点已选但无法连接
先核对系统时间、当前网络与节点参数。日志中的超时通常表示连接未完成，可能是地址不可达、网络丢包或服务器未响应；连接被拒绝通常表示目标地址可达但对应端口没有接受连接；配置解析错误则说明参数结构有问题。TLS、服务器名称、传输路径和服务名等字段必须与节点来源一致，不应凭经验改成常见值。
同一节点在一个平台可用、另一个平台失败时，比较两端的协议字段和内核能力，不要只比较节点名称。重新从原始订阅导入通常比复制客户端内部 JSON 更可靠。若 v2rayNG 能导入某项扩展，而 v2flyNG 无法识别，应依据内核方向选择兼容客户端，不要把缺失字段留空后强行连接。
客户端显示连接但应用没有变化
这通常是系统接管层问题。桌面平台检查系统代理是否已经指向客户端当前监听端口，Android 检查系统 VPN 确认是否完成。随后确认应用是否读取系统代理，是否在连接前已经建立长期连接。完全退出应用后重新打开可以排除连接缓存。浏览器中若额外配置了代理扩展，也应暂时停用，避免它覆盖系统设置。
命令行程序需要检查代理环境变量，游戏和独立网络栈应用可能需要 TUN。不要因为一个应用忽略系统代理就判断节点不可用。选择一个明确遵循系统代理的浏览器作为基础样本，确认基础样本正常后，再扩大接管范围。
关闭客户端后无法联网
最常见原因是系统代理仍指向已经停止的本地端口。Windows 和 macOS 在系统网络设置中关闭手动代理或自动代理配置；Linux 检查桌面代理和终端环境变量；Android 检查系统连接状态和始终开启设置。若曾启用 TUN，还要确认虚拟接口、默认路由和 DNS 已恢复。完成后先验证直连，再重启客户端。
强制结束进程比正常退出更容易留下状态。长期使用时应从客户端菜单关闭系统代理和 TUN，再执行退出。若系统每次重启后都复现，检查是否存在重复自启动项，或另一个网络工具在登录时写入代理。不要同时让多个程序管理同一系统代理开关。
端口占用与内核启动失败
日志出现端口已被使用时，先退出其他代理客户端并确认 v2rayN、v2rayNG 或 v2flyNG 没有重复实例。也可能是上次异常退出留下的内核进程仍在运行。结束确认无用的旧进程后重新启动。若必须修改监听端口，应同时更新浏览器、终端环境变量和其他依赖该端口的工具，避免客户端已换端口而应用仍连接旧值。
# Linux 查看指定端口的监听进程
ss -lntp
# Windows PowerShell 查看 TCP 监听
Get-NetTCPConnection -State Listen
# macOS 查看 TCP 监听
lsof -nP -iTCP -sTCP:LISTEN不要结束无法确认用途的系统进程。命令结果用于找到端口与进程的对应关系，再决定是关闭旧客户端还是调整新客户端端口。监听地址为 127.0.0.1 表示仅本机访问，监听所有接口则还需检查局域网访问设置与防火墙。
TUN 开启后全网中断
立即关闭 TUN并确认基础网络恢复，然后按权限、虚拟接口、路由、DNS 的顺序检查。权限不足通常在创建接口时就报错；路由冲突会在接口创建后导致流量走向错误；DNS 问题则更常表现为域名失败。若同时运行虚拟机、容器网络或其他虚拟网卡工具，先暂时停用其中一个做对照。
Android 还要检查系统是否保留了另一个 VPN 配置，桌面平台则检查是否有多个客户端同时自动启动。恢复测试时不要一次性重新打开全部功能：先节点连接，再系统代理，最后 TUN。每一层通过后再继续，才能确定故障由哪一步引入。
日志整理与进一步查阅
提交问题前记录操作系统、客户端名称、安装包架构、使用系统代理还是 TUN、问题发生时间和最近一次改动。日志只截取故障前后相关段落，并隐藏订阅地址、用户标识、服务器地址等敏感内容。描述应使用可复现步骤，例如“更新订阅成功，选择节点后系统代理开启，浏览器请求超时；关闭系统代理后直连恢复”，比“无法使用”更便于定位。
如果仍无法判断，可前往常见问题按基础认知、安装配置、使用技巧和故障排查分类继续查阅。新手也可阅读V2Ray 新手十问十答，确认内核、订阅和代理模式的基本关系。排错结束后，应撤销临时日志级别、测试端口和临时路由，保留一份已验证的稳定配置。
整套配置的最终验收应覆盖四个状态：客户端启动后订阅可更新，节点连接后目标应用按预期进入代理，关闭系统代理或 TUN 后直连恢复，设备重启或切换网络后能够重新建立连接。达到这四项，说明安装、配置、系统接管和恢复路径都已经闭合。