V2Ray 全平台安装配置大全

通用准备工作与配置边界

安装前先确认设备架构、订阅类型、代理目标与当前网络状态。准备阶段处理得越明确，后续出现连接失败时越容易把问题限定在单一环节。

先区分客户端、内核与订阅

v2rayN、v2rayNG 和 v2flyNG 是图形客户端，负责保存服务器信息、生成运行配置、启动内核并控制系统代理。Xray 与 V2Fly 属于实际处理连接、传输和路由的内核家族。订阅则是一组由服务端提供的服务器配置，常见内容包括地址、端口、用户标识、协议、传输方式、TLS 参数和服务器名称。三者不是同一层级：客户端提供操作界面，内核执行配置，订阅提供可用连接参数。

桌面设备优先选择 v2rayN。它在 Windows、macOS 与 Linux 上保持相近的订阅分组、服务器列表和路由设置结构，跨设备迁移时更容易核对。Android 设备通常选择使用 Xray 内核的 v2rayNG；需要匹配 V2Fly 内核行为时再使用 v2flyNG。不要仅凭协议名称判断客户端能否连接，还要确认传输层、TLS、安全参数和服务端配置是否完整对应。

确认处理器架构与安装包类型

Windows 常见桌面设备使用 x64 包。macOS 需要根据芯片选择 Apple Silicon 或 Intel 安装包。Android 主流设备通常适用 arm64，无法确认架构或设备兼容性较复杂时可使用通用包。Linux 除处理器架构外，还要区分软件包体系：Debian、Ubuntu 及其衍生发行版使用 deb，Fedora、Rocky Linux、openSUSE 等环境通常使用 rpm。安装包类型选错时，常见结果是安装器拒绝执行、提示架构不匹配，或者程序启动后立即退出。

保存原始信息并建立基线

导入前保留订阅地址的原始文本，不要在聊天转发、笔记同步或二维码截图中长期暴露。订阅地址通常具备读取整组节点的权限，泄露后可能被他人使用。首次配置只导入一个订阅分组，选择一个确认可用的服务器，以默认路由和默认 DNS 建立基线。基线连接成功后，再逐项开启自定义路由、TUN、FakeDNS、Mux 或分应用代理。一次修改多个参数会让错误来源相互叠加，无法判断究竟是哪一项导致异常。

开始前还应关闭同类代理客户端，确认系统时间、时区和网络本身正常。TLS 握手依赖准确时间，明显偏差会表现为证书错误或连接建立后立即断开。公司网络、访客网络和公共热点可能限制特定端口或 UDP，因此应先用浏览器直接访问普通网站，确认 DNS 和基础网络可用。若设备上配置过手动代理，记录原值后再交给客户端管理，避免退出客户端时残留旧地址。

建立可重复的操作顺序

1. 选择对应安装包按平台、处理器架构和软件包体系选择，不用文件名相近的其他构建代替。
2. 导入一个订阅分组填写名称和订阅地址，更新后确认服务器条目正常生成。
3. 选择活动服务器先做真实连接测试，再决定是否批量测速或调整排序。
4. 启用一种接管方式系统代理与 TUN 先选一种验证，避免同时改变网络路径。
5. 记录有效配置保存路由模式、DNS 方案和客户端设置，便于升级或迁移后复原。

准备阶段的目标不是提前调完所有选项，而是建立一条可重复、可回退的配置链。后续任何平台出现问题，都按“安装是否完整、订阅是否解析、服务器是否可用、内核是否启动、流量是否进入客户端、DNS 是否匹配”六层顺序检查。这样可以避免把节点故障误判为安装故障，也不会在系统代理残留时反复修改订阅。

Windows 安装、系统代理与 TUN

Windows 端使用 v2rayN。桌面版采用跨平台界面，经典 WPF 版适合偏好传统 Windows 交互的用户；两者的订阅、服务器和路由概念一致。

下载与安装选择

进入Windows 下载区后，根据使用习惯选择桌面版或经典 WPF 版。新安装通常从桌面版开始；需要传统托盘操作、已有 WPF 配置目录或依赖既有操作流程时，可继续选择经典版。安装前退出正在运行的旧客户端，避免安装器无法替换被占用的文件。安装完成后从开始菜单启动，首次运行应先确认主窗口可以打开、托盘区域出现客户端入口，并且核心类型能够正常显示。

若系统弹出网络访问权限提示，应根据实际网络环境允许客户端通信。该提示关系到入站监听和局域网功能，不等同于启用系统代理。受管理设备可能禁止普通用户安装网络组件或创建服务，遇到权限提示时应使用设备管理员允许的安装方式，而不是反复解压到不同目录。便携式使用还要避免把程序放在会自动清理、只读或路径过长的位置。

导入订阅并选择活动服务器

打开订阅分组管理，新增一个分组名称并粘贴订阅地址。保存后执行更新，主列表应出现协议、别名和服务器信息。若列表为空，先检查地址是否完整、是否夹带空格，以及浏览器打开该地址时服务端是否返回有效内容。更新成功后选择一个服务器，将其设为活动服务器。测速只能反映特定测试方式下的响应，不代表所有业务流量都适合该节点，因此首次验证应以实际网页请求和目标应用连接为准。

订阅更新会根据服务端内容增加、修改或移除条目。手工修改订阅生成的服务器参数，下一次更新时可能被覆盖。需要保留个性化设置时，优先把改动放在客户端路由、DNS 或独立的手工服务器分组中。删除订阅前先确认其中没有唯一可用配置；重新添加同一地址可能生成新的分组标识，原有排序和选中状态不一定保留。

系统代理的三种使用状态

Windows 系统代理主要影响遵循系统代理设置的浏览器和桌面程序。常见状态包括清除系统代理、设置系统代理和不改变系统代理。日常使用通常选择“设置系统代理”，退出时再执行“清除系统代理”。“不改变”适用于手工配置浏览器代理、只让特定程序连接本地端口，或由其他网络工具统一管理系统代理的场景。切换后可打开 Windows 代理设置，核对地址是否指向本机回环地址，端口是否与 v2rayN 当前监听一致。

若客户端退出后浏览器无法联网，优先检查系统代理是否残留。可以重新启动 v2rayN 后执行清除，也可以在系统设置中关闭手动代理。不要直接把本地监听端口改成订阅里的远端服务器端口；前者是应用连接 v2rayN 的入口，后者是内核连接服务端的目标，两者作用完全不同。

ipconfig /flushdns
netsh winhttp show proxy
Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess

以上命令分别用于刷新 Windows DNS 缓存、查看 WinHTTP 代理状态和检查本机监听端口。浏览器系统代理与 WinHTTP 代理并非同一套设置，因此 netsh winhttp show proxy 显示直连时，浏览器仍可能正在使用系统代理。排错时要同时检查 Windows 设置、客户端状态和目标程序自身的代理选项。

TUN 模式与平台特有问题

TUN 会创建虚拟网络接口，让不读取系统代理的程序也能进入客户端。启用前先用系统代理完成一次稳定连接，再检查 v2rayN 的 TUN 组件和权限是否就绪。首次启用可能触发管理员权限请求或网络接口安装。成功后系统路由表会出现对应接口，客户端停止时应恢复原有路径。休眠、网络切换和异常退出可能造成虚拟接口仍存在但内核未运行，此时表现为所有应用都无法联网。

游戏、虚拟机、容器软件和企业网络客户端可能同时修改路由或 DNS。出现冲突时，先关闭 TUN 并恢复系统代理验证，再决定通过路由规则排除目标网段，或调整虚拟网卡优先级。局域网打印机、网络存储和远程桌面地址通常应保持直连。不要把私有地址段全部送入远端，否则会出现局域网设备不可达、域账号验证变慢或本地开发服务失联。

Windows 更新或网络驱动变更后，如果 TUN 突然失效，可重启系统并检查虚拟接口是否正常加载。安全软件可能限制新创建的监听端口或网络接口，应根据进程路径和本地监听用途配置明确规则。日志中若显示核心已经启动，但浏览器没有任何请求记录，问题通常位于系统代理或应用代理层；若请求进入客户端后连接远端失败，则继续检查服务器参数、DNS、TLS 与当前网络限制。

macOS 安装、芯片选择与网络权限

macOS 端使用 v2rayN 桌面版。安装重点是选择正确芯片构建、完成首次打开授权，并理解系统代理与网络扩展权限的边界。

判断芯片并完成安装

在系统的“关于本机”信息中查看芯片或处理器。显示 Apple 芯片名称时选择 Apple Silicon 安装包；显示 Intel 处理器时选择 Intel 安装包。进入macOS 下载区获取对应 DMG，打开磁盘映像后将应用拖入“应用程序”目录，再从应用程序目录启动。不要长期直接从已挂载的磁盘映像运行，否则升级、权限保存和自动启动行为可能不稳定。

首次打开时，系统会确认应用来源和网络访问权限。按系统提示完成授权后再导入配置。若双击没有反应，先在“隐私与安全性”中查看是否存在被阻止的打开请求，并确认安装包架构与设备一致。Apple Silicon 设备误装 Intel 构建时可能依赖兼容转换层，虽然部分环境可以运行，但不应作为默认选择；原生构建在启动、资源占用和网络组件兼容方面更直接。

订阅导入与菜单栏状态

v2rayN 的订阅流程与 Windows 端一致：创建订阅分组、填写地址、执行更新、选择活动服务器。主窗口关闭后，程序可能仍在菜单栏运行，因此判断客户端是否退出时要查看菜单栏状态，而不是只看窗口。更新订阅后若服务器列表没有变化，先检查当前选择的分组，再查看更新日志。多个分组使用相同名称时容易误选，建议用用途或服务来源建立短而明确的分组名。

服务器选择完成后先启动内核，确认日志没有配置解析错误。随后启用系统代理。macOS 会按网络服务保存代理配置，不同的无线网络、有线网络或其他网络服务可能具有独立状态。切换网络后若浏览器突然直连，应检查当前活动网络服务是否仍由客户端设置代理。反过来，客户端退出后无法访问网页，则检查系统网络设置中的 HTTP、HTTPS 与 SOCKS 代理是否留下旧地址。

系统代理、终端与独立代理程序

系统代理主要覆盖遵循 macOS 网络代理设置的应用。终端命令、开发工具和部分跨平台程序可能读取环境变量，也可能完全忽略系统设置。需要让某个命令行程序使用本地代理时，应仅在当前终端会话中设置对应变量，并把端口替换为 v2rayN 实际监听值。任务完成后关闭终端会话即可清除，避免把代理变量永久写入全局启动脚本。

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端口
env | grep -i proxy

这里的“本地HTTP端口”和“本地SOCKS端口”应从客户端设置中读取，不能直接照抄其他设备的数值。若程序只支持 HTTP 代理，就不要给它填写 SOCKS 地址。部分命令行工具对大写和小写环境变量处理不同，排错时应查看该工具文档，并使用 env | grep -i proxy 确认当前会话到底存在什么变量。

TUN、DNS 与休眠恢复

TUN 模式需要更高层级的网络权限。首次开启时，系统可能要求确认网络扩展、输入设备密码或允许后台项目。授权只解决组件加载问题，不代表路由一定正确。启用后应依次验证普通网页、局域网地址、终端请求和目标应用。若仅局域网失效，应检查私有地址直连规则；若所有域名失败但直接访问已知地址正常，重点检查 DNS；若休眠恢复后完全断网，应先停止 TUN、退出客户端，再重新启动。

macOS 的网络服务顺序、私有中继类网络功能、企业配置描述文件和其他虚拟网络程序都可能改变流量路径。排查时保持一次只运行一个负责接管默认路由的程序。无线网络从家庭网络切换到公共网络后，服务端可达性、UDP 能力和 DNS 返回可能变化，不能仅根据切换前的状态判断客户端故障。先关闭接管恢复直连，再重启内核，最后重新启用代理，是最稳妥的恢复顺序。

升级与配置迁移

升级前退出菜单栏中的 v2rayN，并记录当前订阅分组、路由模式、核心类型和本地端口。覆盖应用通常不会主动修改配置，但从旧目录直接复制全部运行文件可能带入失效缓存或过期组件。更稳妥的方法是保留订阅地址和明确的自定义规则，在新程序中确认基础功能后再迁移。若新旧构建无法共用配置结构，应优先重新导入订阅，而不是手工修改内部数据库。

迁移完成后检查开机启动和后台项目列表，避免旧程序与新程序同时启动。菜单栏出现两个相似入口时，应退出全部实例，再从“应用程序”目录启动目标版本。日志目录和临时配置中可能包含服务器信息，对外提供诊断材料前要删除订阅地址、用户标识、域名和端口。只保留错误类型、发生阶段和必要的内核提示，通常已经足够定位问题。

Linux 安装、桌面集成与权限

Linux 端使用 v2rayN 桌面版。安装前同时确认发行版软件包体系、处理器架构、桌面会话和图形依赖，避免把界面问题误判为内核问题。

deb、rpm 与处理器架构

Debian、Ubuntu、Linux Mint 等环境通常选择 deb；Fedora、Rocky Linux 及使用 RPM 软件管理体系的发行版选择 rpm。设备架构可通过 uname -m 查看：常见的 x86_64 对应 x64，aarch64 对应 arm64。进入Linux 下载区时要同时匹配这两个条件。只匹配包格式而忽略架构，安装器会直接拒绝；只匹配架构而选错包体系，则缺少对应的软件管理元数据。

uname -m
cat /etc/os-release
echo "$XDG_CURRENT_DESKTOP"
echo "$XDG_SESSION_TYPE"

/etc/os-release 用于识别发行版与基础体系，XDG_CURRENT_DESKTOP 和 XDG_SESSION_TYPE 用于判断桌面环境及当前是 X11 还是 Wayland。v2rayN 的代理内核并不依赖某一种桌面协议，但托盘图标、窗口缩放、开机启动和系统代理写入可能受到桌面环境影响。服务器版或最小化系统若没有完整图形会话，不适合把图形客户端当作系统服务部署。

使用系统软件管理器安装

deb 包可通过图形软件安装器打开，也可使用系统包管理命令安装；rpm 包同理。命令行安装的价值在于能够明确显示缺失依赖，而不是绕过发行版软件管理。安装文件名应以实际下载结果为准，不要把示例文本直接当作路径。

sudo apt install ./下载得到的v2rayN软件包.deb
sudo dnf install ./下载得到的v2rayN软件包.rpm

安装完成后从桌面应用列表启动。若窗口无法出现，先在终端执行应用入口观察错误输出，再检查图形运行库、显示服务器环境变量和用户目录写入权限。不要直接以 root 身份长期运行图形客户端。root 启动会在管理员主目录创建另一套配置，还可能导致普通用户无法读取后来生成的文件。只有安装软件包、配置 TUN 或修改系统级网络设置时才需要按提示提升权限。

订阅、系统代理与桌面环境差异

订阅导入仍遵循新增分组、更新内容、选择服务器、启动内核的顺序。内核启动后先查看本地 HTTP 与 SOCKS 监听端口，再决定如何把应用流量送入客户端。GNOME、KDE Plasma 和其他桌面环境对系统代理的存储位置不同，v2rayN 能否自动写入取决于当前桌面集成。若自动设置后浏览器没有进入代理，可在桌面网络设置中手工核对回环地址与端口，但不要同时保留旧客户端的代理值。

终端程序通常读取 http_proxy、https_proxy 或 all_proxy 环境变量。图形程序可能遵循桌面代理，也可能使用自身设置。systemd 管理的后台服务不会自动继承登录终端中的环境变量，需要在服务自身配置中明确声明。排错时先确定目标程序属于浏览器、终端进程、桌面应用还是系统服务，再检查对应入口，不能只看桌面代理开关。

TUN、路由表与本地服务

Linux TUN 需要内核支持、设备节点和创建网络接口的权限。启用前可检查 /dev/net/tun 是否存在。容器、虚拟机、网络命名空间和防火墙管理器都可能添加策略路由或数据包标记。若 v2rayN 显示 TUN 已启动但流量没有进入内核，应检查默认路由、策略路由、DNS 指向以及防火墙是否允许虚拟接口转发。不要在不理解现有规则的情况下整体清空防火墙，这会影响系统服务和容器网络。

ip address
ip route
ip rule
ss -lntup
resolvectl status

ip route 用于确认默认路由与私有网段路径，ip rule 用于查看策略路由，ss 用于确认本地代理端口是否监听，resolvectl status 可查看采用 systemd-resolved 的系统当前 DNS。若发行版使用其他解析器，应检查对应的网络管理服务，而不是直接反复覆盖 /etc/resolv.conf。该文件在不少发行版中由 NetworkManager 或解析服务动态生成，手工改动可能在重连网络后消失。

托盘、开机启动与升级

部分桌面环境默认不显示传统托盘图标，关闭窗口后很难确认客户端是否仍在运行。首次使用应测试窗口关闭行为，并通过进程列表确认退出方式。设置开机启动时，只保留一个桌面自启动入口，避免用户级自启动文件与桌面设置重复。重复实例可能争用同一本地端口，表现为第二个实例启动失败、订阅更新正常但代理监听不存在。

升级前退出所有实例，使用发行版软件管理器安装新包。若依赖冲突，先读取软件管理器给出的具体包名和版本约束，不要盲目删除桌面运行库。配置迁移应围绕订阅、路由和 DNS 设置进行，缓存与运行时生成文件不必整体复制。升级后按“界面启动、内核启动、本地监听、系统代理、TUN”顺序逐层验证，可以准确识别变化发生在哪一层。

Android 安装、后台运行与分应用代理

Android 端首选 v2rayNG，默认使用 Xray 内核；需要 V2Fly 内核行为时选择 v2flyNG。两者的导入、连接和分应用代理思路接近。

选择 arm64 或通用安装包

近年的主流 Android 手机和平板通常使用 arm64，可优先选择对应安装包。设备架构无法确认、系统较旧或安装时提示不兼容，可改用通用包。通用包包含更多架构代码，文件通常更大，但兼容范围更宽。进入Android 下载区时，先选客户端，再选架构：通常使用 v2rayNG；只有明确需要 V2Fly 内核时再安装 v2flyNG。

安装前确认系统允许当前浏览器或文件管理器打开下载得到的安装包。该授权通常按来源应用单独管理，安装完成后可以关闭对应来源的安装权限。覆盖升级应保持应用标识一致；若系统提示签名不匹配，不要强行覆盖，先备份订阅地址和自定义设置，再确认当前已安装应用与新包来源是否一致。卸载会清除应用私有配置，因此不要在未保存订阅信息前直接卸载排错。

导入订阅与二维码

复制订阅地址后，在订阅分组中新增配置并执行更新。二维码适合导入单个服务器或服务端提供的订阅信息，但扫描前仍要确认二维码来源。相册识别需要存储或照片读取权限，摄像头扫描需要相机权限；只在使用该功能时授权即可。导入后检查服务器条目是否包含地址、端口、协议和传输信息，名称出现乱码通常不影响连接，但全部条目为空则说明订阅没有被正确解析。

选择服务器后点击连接按钮，系统会显示网络连接授权对话框。确认后状态栏出现系统网络标识，表示应用获得了流量入口，不代表远端连接一定成功。此时应查看 v2rayNG 日志并打开实际网页验证。若点击连接后立即恢复断开状态，重点检查配置解析、端口占用和系统是否限制应用启动；若保持连接但网页无法打开，再检查服务器可达性、DNS 和路由模式。

后台保活与电池策略

Android 厂商的省电策略可能在熄屏后限制 v2rayNG，表现为锁屏一段时间后连接中断、通知仍在但没有流量，或切回应用后重新连接。应在系统电池设置中允许客户端后台运行，并将其加入受保护应用或后台白名单。具体菜单名称因设备而异，判断标准是允许后台活动、关闭自动冻结，并避免系统清理工具结束客户端进程。

后台保活并不意味着应关闭所有省电能力。先观察问题是否只在锁屏、切换移动网络或长时间待机后出现，再针对 v2rayNG 调整。若耗电明显增加，应检查是否启用了不必要的全局代理、频繁订阅更新、持续测速或高开销的 Mux 配置。可参考v2rayNG 后台保活与耗电排查，按系统限制、分应用代理和连接参数逐项处理。

分应用代理与绕过局域网

分应用代理用于控制哪些应用进入 v2rayNG。正向选择表示只有选中的应用使用代理；绕过选择表示选中的应用保持直连。启用前先明确当前模式，避免把支付、局域网控制或公司认证应用意外送入远端。系统组件、浏览器内核和应用之间可能存在调用关系，仅选择主应用时，外部打开的网页或下载服务不一定沿用同一路径。

局域网设备地址、路由器管理页、投屏设备和网络存储通常应保持直连。若连接 v2rayNG 后无法访问这些设备，检查路由模式是否包含私有地址直连规则。移动网络与无线网络切换时，本地网段会变化，旧网络的特定网段规则未必适用于新网络。通用私有地址规则通常比逐个设备地址更稳定，但企业网络可能使用更复杂的内部网段，需要按实际网络补充。

移动网络切换与连接恢复

从无线网络切换到移动数据时，底层网络地址、DNS 和 IPv6 条件都会改变。应用可能保持系统连接状态，但原有远端会话已经失效。正常情况下内核会重建连接；若长时间无流量，可先切换一次客户端连接，而不是立即删除订阅。公共无线网络常要求先完成网页认证，应在暂停代理后完成认证，再重新连接。

若只有某个应用无法访问，先关闭分应用代理验证，再检查该应用是否使用私有 DNS、内置 QUIC 或独立代理设置。若所有应用都失败，查看日志中是否存在 DNS 超时、连接拒绝或 TLS 相关提示。日志求助时只保留错误阶段和类型，删除完整服务器地址、用户标识与订阅内容。移动端问题常与后台限制和网络切换有关，因此排查时必须记录“前台正常还是后台异常”“无线网络正常还是移动网络异常”这两个条件。

订阅管理、协议参数与路由分流

订阅解决配置分发，路由决定每一类流量从哪个出口离开。稳定配置的关键是区分服务端参数与本地策略，不在错误层级反复修改。

订阅更新的完整过程

客户端更新订阅时，会请求订阅地址、读取返回内容、解析各服务器条目，再写入本地分组。任何一层失败都会表现为“更新失败”，但处理方式不同。请求阶段超时要检查当前网络和订阅地址可达性；返回空内容要检查订阅状态；解析失败要检查编码、格式和客户端支持；写入后列表为空则检查分组筛选和过滤规则。可以按照订阅链接失效或解析失败六步自查逐层定位。

订阅地址可能包含访问凭据，不应被公开分享。不同设备使用同一订阅时，更新频率应保持合理，避免在短时间内连续刷新。客户端支持定时更新时，可以设置符合实际需求的周期，但不要把节点测速和订阅更新混为一项任务。更新只同步配置，测速才会主动访问服务器。服务端移除条目后，下一次更新可能同步删除，因此重要的手工配置应放在独立分组。

协议与传输参数必须成组匹配

VMess、VLESS、Trojan 和 Shadowsocks 描述的是不同协议体系，WebSocket、gRPC、TCP 等属于传输层，TLS 与 REALITY 则涉及安全握手和服务端身份参数。一个连接能否成立，取决于整组参数与服务端一致，而不是只要协议名称相同即可。VLESS 配置常见字段包括用户标识、传输方式、安全类型、服务器名称与流控；Trojan 需要匹配密码与 TLS 相关信息；Shadowsocks 需要匹配加密方式和密码。

订阅正常生成的配置通常不需要手工改协议字段。只有服务端明确提供修改说明时，才调整对应参数。把 WebSocket 路径、gRPC 服务名、服务器名称或公钥留空，都可能导致连接失败。客户端显示的服务器备注只用于识别，不参与握手；修改备注不会改变连接。协议选择的横向说明可查看VMess、VLESS、Trojan、Shadowsocks 场景选型。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-4111-8111-111111111111",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/vless"
        }
      }
    }
  ]
}

该片段用于说明字段层级，示例域名和用户标识不能直接用于连接。真实配置还需要与服务端匹配的 TLS 服务器名称、请求头或其他传输参数。图形客户端通常由订阅自动生成完整结构，日常配置不必直接编辑 JSON。只有在阅读日志、核对字段或迁移自定义规则时，才需要理解这些层级。

路由规则的匹配顺序

路由通常根据域名、IP、端口、网络类型和进程信息匹配出口。规则从上到下判断时，更具体的规则应放在更前面，默认规则放在末尾。常见出口包括代理、直连和阻断。局域网与本机地址应直连；明确需要远端出口的域名进入代理；不需要访问的遥测或恶意地址可以阻断。规则没有命中时走默认出口，因此默认值决定了配置的整体倾向。

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

IPIfNonMatch 表示域名规则未匹配时，再解析地址用于 IP 规则判断。它会增加 DNS 参与度，因此 DNS 配置必须稳定。若使用 AsIs，路由更依赖原始域名规则，不会为了 IP 匹配主动解析所有未命中域名。不同内核和客户端对可用策略名称、规则集来源及更新机制可能有差异，应以当前客户端界面提供的选项为准。

全局、绕过与自定义规则怎么选

全局模式适合短时间验证服务器是否可用，因为几乎所有目标都会进入代理，变量最少。它不适合作为所有环境的默认答案：局域网设备、本地开发地址和企业内部服务可能因此不可达。绕过大陆类预设会按内置域名和地址规则分流，维护成本较低，但规则集需要随客户端更新。自定义路由适合有明确业务边界的用户，应从少量规则开始，每增加一条都记录匹配目的和预期出口。

判断路由是否生效不能只看网页能否打开。应在客户端日志中确认目标域名、匹配规则和最终出口。域名被应用提前解析为地址时，客户端可能只能看到 IP；启用嗅探后可以从部分连接恢复域名信息，但并非所有协议都能可靠识别。路由问题要同时考虑应用请求形态、DNS 返回和规则顺序。保留一份默认路由配置，可以在自定义规则失效时快速回退。

系统代理、TUN与 DNS 协同

系统代理决定应用是否主动连接本地端口，TUN 从网络层接管流量，DNS 决定域名如何得到地址。三者职责不同，但配置错误时会表现出相似的“网页打不开”。

系统代理适合哪些场景

系统代理设置成本低，适合浏览器和遵循操作系统代理接口的桌面程序。客户端通常在本机监听 HTTP、SOCKS 或混合端口，再把系统代理指向回环地址。应用请求进入本地端口后，内核根据路由选择代理或直连出口。系统代理不会天然覆盖所有程序：命令行工具、游戏、后台服务和自行实现网络栈的应用可能忽略它。

启用系统代理前应确认本地端口已经监听。端口被其他进程占用时，内核可能改用其他端口或直接启动失败，而系统仍指向旧端口。退出客户端时应清除系统代理；异常退出后若全局断网，第一步就是检查残留。系统代理只应指向 127.0.0.1 或客户端明确允许的本机地址，不要把远端服务器地址直接填入系统代理设置。

TUN 为什么覆盖范围更广

TUN 创建虚拟网络接口并接收系统路由送来的数据包，因此能覆盖不支持 HTTP 或 SOCKS 代理的程序。客户端需要把数据包转换为内核可处理的连接，再依据规则发送到直连或代理出口。它通常需要更高权限，也更容易与其他虚拟网络、企业安全程序、虚拟机和容器路由冲突。启用 TUN 前，必须先验证同一服务器在系统代理模式下正常连接。

TUN 配置至少涉及接口地址、路由注入、DNS 接管、MTU 和绕过范围。MTU 过大可能导致部分网络中握手成功但大页面加载失败，过小则增加分片和开销。默认值通常更适合多数网络，不应在没有证据时调整。若问题只发生在移动热点、企业网络或某个宽带环境，可通过逐步降低 MTU 验证，但每次修改后要重建连接并清理旧会话。

DNS 查询在哪一层发生

应用可以把域名交给系统解析，也可以使用自身的加密 DNS。系统代理模式下，SOCKS 请求可能携带域名，也可能只携带应用已解析的 IP。TUN 模式常通过 DNS 接管把查询送入客户端，以便路由规则使用域名信息。若 DNS 走直连而目标连接走代理，可能得到不适合当前出口的地址；若全部 DNS 强制走远端，又可能影响局域网名称和企业内部域名。

稳定方案通常把公共域名与内部域名分开处理：局域网和企业域名交给本地 DNS，其他查询按路由策略选择解析器。需要基于域名分流时，应确保客户端能够看到域名，或使用嗅探补充信息。嗅探不是解密应用内容，而是从连接握手中识别可见的目标名称；面对加密程度更高或非标准流量时，识别结果可能有限。

FakeDNS 的适用边界

FakeDNS 会从保留地址池返回虚拟 IP，并在客户端内部保存虚拟地址与原始域名的映射。应用随后连接虚拟 IP 时，客户端可以恢复域名并提前执行域名路由。它适合 TUN 场景下需要稳定域名分流、又无法从连接中直接获得域名的情况。工作原理和组合方式可参阅FakeDNS 原理与适用场景。

FakeDNS 不适合不经客户端处理的流量，也可能影响依赖真实地址的诊断工具、局域网发现和某些应用的地址校验。开启后如果系统显示保留网段地址，这是预期结果，不能据此判断 DNS 被篡改。真正需要检查的是虚拟地址连接是否被客户端接住、映射是否存在，以及最终出口能否解析和连接真实目标。关闭 FakeDNS 时应重启受影响应用，必要时刷新系统 DNS 缓存，避免旧虚拟地址继续停留。

推荐的渐进配置法

1. 先用系统代理验证节点确认订阅、协议、TLS 和远端连接没有基础错误。
2. 保持默认 DNS 验证域名检查普通网页、局域网地址和目标应用的基本行为。
3. 单独启用 TUN暂不添加复杂路由，观察虚拟接口、默认路由和应用覆盖范围。
4. 加入私有地址直连恢复路由器、打印机、网络存储和内部服务访问。
5. 最后调整 DNS 与 FakeDNS每次只改变一项，并通过日志确认域名、地址和出口对应关系。

判断配置是否完成，应覆盖四类测试：普通网页能否加载、局域网资源能否直连、不读取系统代理的目标程序能否按预期进入 TUN、客户端退出后直连网络能否恢复。只通过其中一项并不能证明整体路径正确。对复杂网络保留一份“系统代理、默认 DNS、默认路由”的基础配置，再单独保存 TUN 配置，切换环境时比反复手工改参数更可靠。

配置常见问题与分层排查

排错应沿数据路径从外到内进行：系统网络、客户端入口、内核启动、订阅参数、远端连接、DNS 与路由。每一步都要有可观察结果。

第一层：确认直连网络与系统状态

先停止客户端接管，关闭 TUN，清除系统代理，确认设备在当前网络下可以直接访问普通网站。若直连本身失败，应先处理无线网络认证、移动数据、路由器、系统时间或 DNS，而不是修改服务器配置。公共网络可能要求打开认证页面；企业网络可能限制未知端口；休眠恢复后网卡可能没有正确获取地址。只有直连基线正常，后续测试才有意义。

同时确认没有其他代理客户端、虚拟网络程序或残留环境变量。Windows 检查系统代理和本地监听，macOS 检查当前网络服务与终端变量，Linux 检查桌面代理、环境变量和策略路由，Android 检查系统连接状态与后台限制。若关闭 v2rayN 或 v2rayNG 后网络仍被接管，说明系统层存在残留，应先恢复再继续。

第二层：确认客户端和内核真正启动

窗口能够打开不代表内核已经运行。选择服务器后查看状态区和日志，确认配置生成成功、本地端口开始监听、没有立即退出。配置解析错误通常会明确指出字段、协议或 JSON 位置；端口占用会显示监听失败；权限问题常出现在 TUN 接口或网络扩展创建阶段。先处理日志中的第一条关键错误，后续错误往往只是前一错误的连锁结果。

若本地端口没有监听，系统代理指向该端口也不会产生有效连接。修改端口后要同步更新系统代理、浏览器设置和终端环境变量。多个客户端同时启动时，后启动者可能无法占用默认端口。退出全部实例、确认端口释放，再只启动目标客户端，是排除争用最直接的方法。

第三层：区分订阅失败与服务器失败

订阅更新成功只说明配置能够被获取和解析，不代表其中每个服务器都可用。反过来，订阅更新失败也不一定影响已经保存的旧服务器。排查时记录两个独立结果：订阅地址能否更新，现有服务器能否建立连接。若所有条目同时失败，优先检查当前网络、订阅统一变更、客户端内核或 DNS；若只有一个条目失败，更可能是该服务器参数或远端状态问题。

手工检查配置时，重点核对地址、端口、用户标识、协议、传输方式、TLS 安全类型、服务器名称、路径和服务名。不要通过随机替换协议或关闭 TLS 来尝试碰运气，这会让配置与服务端进一步偏离。服务端提供新订阅后，应重新更新并用新条目测试，而不是在旧条目上累计修改。

第四层：根据日志阶段判断方向

“连接超时”不能直接证明服务器不可用，因为当前网络、DNS 返回、IPv6 路径和防火墙都可能造成相同结果。最有效的交叉测试是保持服务器不变更换网络，再保持网络不变更换服务器。如果同一服务器在另一网络正常，问题偏向当前网络路径；如果同一网络下其他服务器正常，问题偏向该条目或远端。每次测试只改变一个变量，结论才可靠。

第五层：处理能连接但无法正常使用

客户端显示已连接，但网页无法打开时，先确认应用请求是否进入日志。完全没有请求，检查系统代理、分应用代理或 TUN 路由；有请求但 DNS 失败，恢复默认 DNS；域名解析成功但远端连接超时，检查服务器与网络；部分网站失败，检查 IPv6、MTU、路由规则和目标地址选择。只有浏览器失败时，还要检查浏览器内置代理、私有 DNS、扩展设置和缓存。

网页可以打开但速度异常时，不要仅依赖节点列表中的响应时间。真实速度受服务器负载、线路、目标站点、传输方式和当前网络共同影响。关闭批量测速、下载任务和其他占用带宽的程序，以同一目标做对照。Mux 并非所有环境都能提高性能，移动网络或不稳定链路下可能放大单连接故障；出现持续卡顿时可恢复默认并重新测试。

第六层：恢复、迁移与提交有效日志

复杂配置无法确认问题来源时，先导出需要保留的订阅地址和自定义规则，然后建立最小配置：一个订阅、一个服务器、默认 DNS、默认路由、系统代理。最小配置成功后，按路由、TUN、DNS、FakeDNS、分应用代理的顺序逐项恢复。若某一步重新出现问题，就能把范围锁定在该设置，而不是直接重装客户端。

跨设备迁移时不要复制运行中的缓存、锁文件和临时配置。优先迁移订阅地址、独立手工服务器、路由规则说明和必要的 DNS 选择。不同平台对权限、路径和网络接口的处理不同，完整复制配置目录可能带入无效路径或平台专属状态。迁移后按照各平台章节重新完成系统代理或 TUN 授权。

向他人提供日志时，应描述平台、客户端名称、使用系统代理还是 TUN、问题发生在安装后还是配置变更后、直连是否正常，以及最早出现的关键错误。删除订阅地址、完整服务器域名、用户标识、密码、路径中的个人目录名和可识别网络信息。不要只提供“无法使用”的结论；可重复步骤和分层结果比大段完整日志更有价值。

• 安装包与平台、处理器架构和软件包体系一致。
• 订阅更新与服务器连接分别记录结果，不混为同一问题。
• 系统代理、TUN、应用内代理只保留当前需要的一套入口。
• 局域网与内部服务具有明确的直连规则。
• 日志已隐藏订阅、用户标识和服务器敏感信息。