全平台安装配置

准备工作与配置边界

区分客户端、内核与连接配置

v2rayN 是桌面图形客户端，负责保存连接配置、启动内核和调整代理相关设置。实际解析协议、建立远端连接与执行路由规则的是内核。Project V 是相关技术生态的背景，V2Fly 与 Xray 属于不同的内核发展分支。界面能够打开，不等于内核已经启动；内核正常运行，也不等于系统应用已经把请求交给它。这三层需要分别验证。

桌面平台优先按本手册使用 v2rayN。Android 先选采用 Xray 内核的 v2rayNG；已有配置明确要求 V2Fly 行为时，再考虑 v2flyNG。不要仅根据名称相近就交换配置文件。协议支持、传输参数和扩展字段取决于客户端与实际内核的组合，服务提供方给出的兼容说明应当与当前选择对应。

确认架构、权限和网络前提

下载前先查看设备处理器架构，而不是仅看系统名称。常见桌面处理器使用 x64，部分设备使用 arm64；macOS 还需要区分 Apple Silicon 与 Intel。Android 的处理器、系统位数与可安装的软件架构也可能不同。包格式同样重要：安装器、磁盘映像、发行版软件包分别适用于不同安装流程，不能通过修改文件扩展名互相转换。

准备一份有权使用且仍然有效的订阅地址，或者完整的单条连接参数。客户端本身不附带可用的远端服务。连接所需内容通常包含服务器地址、端口、身份凭据、协议与传输设置；启用 TLS 或 REALITY 时还可能涉及服务器名称、公钥等字段。缺少参数时应向配置提供方确认，不要用猜测值补齐。

先确保设备本身能正常联网，系统日期、时间与时区设置合理。明显错误的时钟会影响证书有效期判断，也可能使部分协议的认证失败。确认浏览器可以打开普通网页，再检查是否存在单位网络认证页、系统级代理、另一款正在运行的隧道工具或安全软件规则。基础网络不通时，反复更新订阅通常不能解决问题。

明确系统代理与 TUN 的区别

系统代理通过操作系统提供的代理设置，让遵循这些设置的应用连接本地监听端口。它不等于所有应用都会转发流量，部分程序有独立代理配置，另一些程序完全忽略系统代理。TUN 则通过虚拟网络接口接管符合条件的流量，覆盖范围更广，但也会引入路由、DNS 与权限方面的额外变量，适合在普通代理链路确认正常以后再启用。

局域网共享与本机使用也是不同场景。本机连接通常只需要回环地址监听；允许局域网连接后，其他设备才可能访问监听端口，同时必须考虑防火墙、监听地址与访问边界。初次安装保持局域网共享关闭，不要为了排错直接放开所有网络访问。确有共享需求时，可另读局域网代理共享说明。

建立可回退的操作顺序

安装或迁移前，在客户端完全退出后备份配置目录。备份可能包含订阅地址、身份凭据和使用记录，应存放在受控位置。先记录当前系统代理状态、监听端口与路由选择，再开始修改。截图需要遮盖完整订阅链接、服务器凭据和二维码；这些内容被复制后，可能允许他人使用同一份服务配置。

建议按安装、导入、启动、显式代理测试、系统代理测试、TUN 测试的顺序推进。每次只改变一个主要变量，并记录变化前后的表现。升级后有问题时，优先对照备份与日志，不要立刻把所有设置恢复成未知状态。若需回退，先退出新客户端，再恢复匹配的配置副本，避免两个进程同时读写同一目录。

Windows 安装与代理接管

选择桌面版或经典 WPF 版

进入Windows 下载入口，先区分 v2rayN 桌面版与经典 WPF 版。桌面版采用跨平台界面，WPF 版保留经典桌面交互。两者并不是连接协议的两个等级，也不应仅凭外观判断性能。按照设备系统、使用习惯以及所需功能选择即可；本页不要求为了完成配置同时安装两种界面。

下载页的 Windows 主入口面向 x64。若设备使用其他架构，先核对系统兼容性，不要把 x64 文件当成原生 arm64 包。安装时按安装器提示完成目标目录与必要组件设置。若系统报告缺少运行环境，应依据错误内容安装匹配组件，而不是从不明来源复制动态库。能够完成安装但不能启动时，也要保留原始报错文字。

首次启动不要把配置目录放在只读位置，或交给同步软件同时修改。安装目录与用户配置目录不一定相同，应从客户端提供的目录入口或日志确认实际路径。普通系统代理一般不要求长期以管理员身份运行；涉及虚拟接口、驱动或特权操作时，再按明确提示授权，避免把权限提升当作通用修复步骤。

导入订阅并确认内核启动

打开订阅分组设置，新建一个用途明确的分组名称，将订阅地址完整粘贴到地址字段，保存后执行更新订阅。更新成功后，在列表中选择一条配置作为活动项。导入动作只是把连接数据保存到本机，不能证明远端可用。若更新后为空，先阅读订阅更新结果，再检查地址是否实际返回连接配置，而不是账户登录页面。

选择配置后启动或重载内核，查看日志是否出现启动失败、端口占用或字段不支持等错误。若某条配置依赖 Xray 扩展，所选内核也必须能够解释对应参数。不要在没有说明的情况下切换所有内核设置。存在多个分组时，应确认活动项属于刚更新的分组，避免把旧配置的连接表现误认为新订阅的状态。

先测本地代理，再设置系统代理

在参数设置中查看本地监听端口。常见设置使用 10808，但实际值应以本机界面为准；它是电脑上的监听端口，不是服务器端口。确认监听类型后，可让一个支持手动代理的应用显式使用回环地址与该端口。显式代理测试成功，再把系统代理设为自动配置系统代理，检查浏览器是否采用新设置。

系统代理生效还受到浏览器策略、扩展程序和应用内部设置影响。某个浏览器正常而另一个应用失败时，应先查看后者是否支持系统代理，而不是直接更换远端配置。若终端工具需要单独设置代理，应仅在对应进程中配置并及时撤销。系统代理和终端环境变量属于不同入口，修改其中一个不一定会改变另一个。

启用 TUN 与处理平台特有问题

需要接管不遵循系统代理的应用时，再尝试启用 TUN。按照当前客户端提示完成必要授权，随后检查虚拟接口、默认路由和 DNS 是否出现异常。第一次测试保留简单路由，暂时退出其他虚拟网络工具。若启用后本来正常的直连也中断，先关闭 TUN 恢复网络，再从日志与接口状态定位，不要同时修改证书、订阅和防火墙。

Windows 防火墙提示要区分出站连接与允许其他设备访问本地服务。仅本机使用代理时，不需要为了消除提示而允许任意网络的入站访问。若端口被占用，先退出重复运行的 v2rayN 实例，确认托盘中是否仍有旧进程。调整端口后，所有手动填写过代理地址的应用都要同步修改，否则会继续访问旧端口。

退出前先清除系统代理，再正常关闭客户端。若程序异常结束后浏览器全部断网，打开系统代理设置，检查是否仍指向已经停止的本地端口。自启动也应在手动运行稳定后开启，并验证重新登录时只有一个实例。睡眠唤醒后连接失败，可先检查基础网络是否恢复，再重载内核，避免把尚未完成联网的状态当作配置损坏。

升级前导出必要设置并备份配置目录，安装完成后先对比监听端口、活动配置与路由选择。不同界面之间迁移时，不保证所有窗口选项都能逐项对应；先恢复连接所需数据，再重新检查平台设置。基础主线可对照使用指南中的代理设置步骤，不要在迁移过程中一次性引入新的分流规则。

macOS 安装与权限处理

按芯片选择安装包

先在系统的关于本机信息中查看芯片或处理器。Apple Silicon 设备选择 arm64，Intel 设备选择 x64，再前往macOS 下载入口获取 v2rayN。不要只凭电脑购买年份判断架构，同一年可能存在不同芯片机型。架构不匹配可能导致无法打开、依赖转换运行环境或出现额外兼容问题，优先选择与设备一致的包。

打开磁盘映像后，按包内安装说明将应用复制到应用程序目录，再从目标目录启动。不要长期直接在磁盘映像里运行，因为映像被推出、路径改变或登录后未挂载，都可能影响后续启动。配置文件也不应手动塞进应用程序包内部；应用更新可能替换程序包内容，用户数据应保存在客户端实际使用的配置位置。

如果系统显示安全提示，先核对文件来源与提示类型，再使用系统提供的安全与隐私授权流程。系统判定应用损坏、架构不兼容和来源确认并不是同一问题，处理方法也不同。不要一开始就全局关闭系统安全机制，也不要照抄来历不明的终端命令删除属性。无法判断时保留完整提示，回到下载入口重新确认所选文件。

导入配置与验证代理链路

启动后先建立订阅分组，保存地址，再执行更新。若把内容从备忘录或聊天软件复制过来，注意全角符号、换行与尾部空白。更新成功以后选择活动配置，启动内核并查看日志。macOS 上的界面名称可能与 Windows 略有差异，应按设置含义查找，而不是要求每个按钮位置完全相同；服务器参数与本地监听参数仍需分开理解。

先通过支持显式代理的应用测试回环地址与监听端口。确认内核工作正常，再启用系统代理。macOS 的代理设置与网络服务关联，Wi-Fi、有线网络以及其他网络服务可能具有各自状态。切换网络后某个应用不再走代理时，应核对当前服务的代理项目，而不是只看客户端上一次显示的开关状态。

部分应用会在启动时读取代理设置，修改系统代理后可能需要重新打开应用。也有应用采用自己的网络配置，不能以浏览器能连接来推断它们必然跟随。测试时选定同一个目标与同一种接管方式，避免混用浏览器缓存、已有连接和新建连接。必要时关闭原有窗口重新测试，让观察结果对应当前设置。

TUN 权限与网络切换

TUN 涉及虚拟网络接口和系统路由，具体授权方式取决于客户端当前实现。只在应用明确请求时授予所需权限，并观察授权后内核是否真正启动。窗口中的开关处于开启状态，不代表系统已经创建了有效接口。若提示权限不足、接口创建失败或路由添加失败，应按日志逐项处理，而不是反复点击开关期待自动恢复。

同时使用企业网络工具、虚拟机桥接网络或其他隧道服务时，可能发生路由与 DNS 竞争。先在只运行 v2rayN 的条件下建立基线，再逐个恢复其他工具。若必须共存，需要明确哪些地址走直连、哪些由另一套网络接管。不要为了让网页短暂恢复而删除不认识的系统路由，这可能影响远程访问或单位网络资源。

电脑从睡眠恢复、从有线切到无线，或进入需要网页认证的网络后，已有连接可能失效。先关闭代理接管并完成基础网络认证，再启动内核和恢复代理。若每次唤醒都失败，记录失败时是否能直接访问普通网页、是否仍有本地监听、日志是否显示远端重连；这些信息比单独描述“网络卡住”更有助于区分问题层级。

退出、更新与配置迁移

正常退出前关闭系统代理与 TUN，并确认系统网络设置已经恢复。直接结束进程可能留下指向本地端口的代理设置；此时应用停止监听，浏览器就会持续连接失败。恢复网络时先查看当前网络服务的代理项目，只清除与本次客户端相关的设置。若设备受组织策略管理，不要覆盖管理员预设的代理配置。

迁移到另一台电脑时，先备份订阅与必要设置，再安装适配新芯片的程序。连接配置可以迁移，但原机路径、登录启动项和网络权限不能机械复制。迁移后重新验证监听地址、系统代理与 TUN，确认运行正常再删除旧备份。包含身份凭据的备份不宜长期留在公共共享目录，导入完成后应按自己的数据管理方式妥善保存。

Linux 安装与桌面环境

区分发行版包格式与处理器架构

打开Linux 下载入口，依据发行版选择 deb 或 rpm，再确认处理器架构。Debian、Ubuntu 等通常使用 deb，Fedora 等通常使用 rpm；衍生发行版仍应以自身软件管理说明为准。x64 与 arm64 是架构差异，不是包格式差异。同一种格式可能同时提供不同架构，文件能够下载并不说明系统一定能够安装。

可在系统设置中查看系统与处理器信息；熟悉终端时也可运行下面的只读命令辅助确认。常见输出中，x86_64 对应 x64，aarch64 通常对应 arm64。发行版标识用于选择安装方式，不应仅根据桌面外观判断。图形界面相似的系统，底层包管理器和依赖集合仍可能不同。

uname -m
cat /etc/os-release

使用发行版的图形软件安装器打开下载的软件包，并阅读依赖与权限提示。安装失败时先区分架构不匹配、依赖缺失和软件管理器正在占用数据库三种情况。不要强行忽略依赖完成安装，也不要在另一个更新任务尚未结束时删除包管理锁文件。解决系统包状态后再重新安装，比反复覆盖应用目录更稳妥。

普通用户启动与配置目录

安装完成后，从应用菜单以日常用户启动 v2rayN。不要为了方便把整个图形客户端长期作为高权限进程运行，否则可能生成属于其他用户的配置文件，导致下次普通启动无法写入。若出现保存失败，先检查实际配置路径与文件归属。应用显示配置目录时，以该路径为准，不要假定所有发行版都把用户数据放在同一个位置。

建立订阅分组、更新订阅并选定活动配置后，启动内核，检查日志中是否有执行权限、端口占用或内核文件缺失的提示。若软件包安装完整但程序无法调用内核，还要考虑安全策略、挂载选项和文件权限。不要对整个用户目录递归放宽权限；应该先定位出错的具体文件，再按发行版的权限规则处理。

系统代理并非所有程序的共同入口

Linux 的系统代理受桌面环境、应用工具包与程序自身实现影响。桌面设置中启用代理后，某些浏览器能够使用，终端程序却可能保持直连，这是入口不同，并不必然说明客户端异常。先在一个可手动指定代理的应用里测试本地监听，确认内核链路正常，再检查桌面系统代理是否写入了当前会话实际读取的位置。

图形应用、终端环境变量与后台服务之间通常不会自动同步代理配置。在终端设置变量也不代表已经修改整个桌面会话；后台服务还可能拥有单独的运行环境。排错时应记录请求由哪个程序发起，以及它从哪里读取代理。避免同时保留多套互相冲突的代理地址，尤其是在监听端口调整或客户端卸载以后。

如果需要在应用中手动填写 SOCKS 代理，应确认该应用如何处理域名解析。有些实现会先在本地解析域名，再把地址交给代理；另一些支持把域名交给代理端处理。二者会产生不同的 DNS 行为。不要只看“SOCKS”字样就推断解析路径一致，具体应结合应用选项、客户端日志与实际检测结果判断。

TUN、特权操作与网络管理服务

TUN 通常涉及设备访问与网络管理权限，客户端可能通过授权提示或辅助机制完成相关操作。先检查错误信息，再按当前应用的权限流程授权，不要随意给整个程序目录增加宽泛能力。系统使用的网络管理与解析服务不同，路由或 DNS 写入方式也可能不同；跨发行版照搬修复命令，可能覆盖原有网络管理配置。

启用 TUN 后无法解析域名时，先关闭 TUN 看是否恢复，再检查系统解析器状态、客户端 DNS 设置及已有虚拟接口。若局域网地址同样失联，应重点查看私有地址路由与接口优先级。虚拟机、容器和企业隧道都可能占用额外网段，不要假设所有本地网段都只有家庭路由器使用的那一段地址。

配置自动启动前，先验证登录桌面后手动运行稳定。用户会话启动与系统启动服务的权限、环境变量和配置路径不同，不能把图形客户端直接等同于后台守护进程。退出或卸载前恢复系统代理，停用 TUN，再确认网络正常。若要迁移配置，先停止进程，保留文件归属，并在新系统重新检查路径与授权。

更新后若只有托盘入口消失，但窗口与内核仍能运行，应先检查桌面环境的托盘支持，而不是重新导入全部订阅。若窗口无法显示，则查看图形会话与启动报错。把界面问题、内核问题和网络问题分开记录，可以减少无关改动；相关路由数据的维护方式可继续查阅规则文件更新教程。

Android 安装与后台运行

选择 v2rayNG 或 v2flyNG

进入Android 下载入口，优先选择 v2rayNG；需要 V2Fly 内核兼容行为时，再使用 v2flyNG。两者是独立应用，订阅、活动配置与后台设置应分别检查，不能假定会自动共享。安装多个客户端用于比较时，一次只启动一个 VPN 服务，避免把另一个应用被系统停止的表现误判为连接故障。

大多数较新的手机可优先考虑 arm64，但最终仍以系统支持的应用架构为准。无法确认或出现架构相关安装错误时，可查看设备信息并考虑通用版。通用版包含更多架构适配内容，并不表示远端连接能力更强。电视、模拟环境或旧设备尤其需要单独确认，不要只根据处理器宣传名称判断系统实际支持的位数。

安装时，系统可能要求为发起安装的文件管理器或浏览器授予安装来源权限。只对本次确有需要的来源授权，完成后可按设备管理习惯收回。更新安装失败时，要区分签名不一致、存储不足、架构不匹配与系统限制。不要未经备份就卸载旧应用，因为卸载通常会同时删除它保存的订阅、连接配置和本地设置。

导入订阅与批准 VPN 请求

在订阅分组中添加地址，保存后执行更新，再选择一条活动配置。通过剪贴板导入时，先确认复制的是连接内容或订阅地址，而不是分享页说明文字。通过二维码导入时注意使用场景，单条连接二维码与订阅二维码的含义可能不同。导入后查看配置类型与关键参数，不要仅凭列表里出现一项就认为数据完整。

首次启动 VPN 模式时，系统会显示连接请求。确认请求来自刚安装的客户端，再批准创建 VPN 连接。状态栏出现 VPN 标识只说明系统层面存在该服务，并不能证明远端已经连通。接着查看客户端日志与实际访问结果。若服务立刻停止，应优先查看权限、活动配置和内核启动错误，而不是直接修改电池策略。

Android 通常只允许同一用户或配置空间中有一个活动 VPN 服务。其他网络过滤、企业访问或隧道工具可能与当前客户端竞争。出现启动后另一个应用断开，先明确系统限制与工作配置空间，再决定保留哪一个服务。不要反复同时启动多个应用；这样产生的断开日志不能准确反映单个客户端自身的稳定性。

应用分流与仅代理模式

需要只接管部分应用时，可以使用客户端提供的应用选择功能。先确认当前列表采用包含还是排除逻辑：选择某个应用可能意味着让它经过代理，也可能意味着让它绕过代理。修改后重启连接，再用目标应用新建请求验证。系统组件、工作资料中的应用和不同用户空间内的应用，未必都出现在同一份列表里。

VPN 模式与仅代理模式的覆盖范围不同。仅代理模式主要提供本地监听服务，目标应用还需要主动使用该代理，不能期待所有手机应用自动跟随。家庭 Wi-Fi 的手动代理设置也不能简单等同于客户端 VPN 模式，它可能只对特定网络与部分协议生效。比较耗电或连通性时，应先确保两次测试使用的是相同模式。

后台保活、耗电与网络切换

如果亮屏可用、锁屏后中断，先检查客户端是否仍在运行，再查看电池优化、后台活动、自启动和数据节省设置。不同系统名称并不统一，应寻找允许后台运行的实际含义。先只为当前客户端调整必要限制，观察是否改善，不必一次性关闭全局省电。更详细的分支可阅读后台保活与省电设置。

流量持续传输、频繁重连与过于密集的检测都可能增加耗电。排查时记录待机环境、网络类型和是否存在大流量应用，不能只凭电池统计中某项比例较高就认定异常。手机从 Wi-Fi 切换到移动网络后，原连接可能需要重新建立；先确认移动网络本身可用，以及客户端是否被禁止使用后台移动数据。

系统若设置了始终开启 VPN 或阻止未经过 VPN 的连接，停止客户端后可能仍无法直连。恢复网络时应检查这些系统级选项，而不只是关闭应用内按钮。准备卸载或更换客户端前，先取消对应绑定并导出必要配置。导出文件与截图同样可能包含敏感地址，分享排错信息时只保留错误类型、时间与经过脱敏的设置说明。

订阅导入与配置管理

订阅地址、分享链接与配置文件

订阅地址通常返回一组连接配置，适合集中更新；单条分享链接通常只描述一个连接；配置文件还可能包含本地监听、路由与 DNS 等内容。三者不能仅凭长度或外观互相替代。导入前先明确客户端当前入口接受哪种数据，避免把完整内核配置粘贴到订阅地址框，或把需要登录的账户页面当成可直接更新的订阅接口。

订阅地址中的路径与查询参数经常包含访问凭据，复制时应保持完整，不随意删掉看似复杂的尾部内容。也不要把链接提交给来历不明的转换网站。若提供方给出针对某种客户端的订阅格式，应优先选择匹配格式；通用输出不一定保留全部传输扩展字段，导入后还需确认实际连接参数。

建立分组与安排更新顺序

按来源或用途建立分组，使用能够区分但不暴露账户信息的名称。首次更新先采用设备当前可用的网络路径；若设置为通过代理更新，就会依赖已有代理链路。已有配置全部失效时，这种依赖可能形成循环：更新需要代理，代理又需要更新后的配置。此时应恢复独立可用的网络路径，或按客户端选项尝试直连更新。

更新后检查分组内是否有内容、数量是否出现明显变化，以及活动配置是否仍然存在。提供方可能修改配置标识或移除旧项，原先选择的活动项不一定能够自动对应。先重新选择一项并启动内核，再测试访问。不要把旧日志与新配置混在一起判断；必要时记录更新完成时间，从那一刻之后查看新产生的错误。

手动修改订阅生成的配置时，要考虑下一次更新可能覆盖这些修改。长期需要的路由、监听端口与应用设置，应尽量放在客户端独立的全局设置中。若必须保存一份经过调整的连接，可在理解更新关系后单独管理，并明确它不会自动继承服务端变化。订阅分组与手工配置混放时，尤其要记录每项内容的来源。

排查订阅更新错误

超时通常表示请求未在规定时间完成，可能涉及基础网络、域名解析或所选更新路径；认证失败更可能与地址凭据、账户状态有关；解析失败则说明返回内容不符合预期格式。这些错误不能用同一个动作解决。先读取完整错误类型，再检查对应层级，避免反复刷新导致请求限制，也不要在公开场合贴出带凭据的原始链接。

如果浏览器打开地址看到的是网页，仍需区分这是登录页、错误页，还是正常的订阅展示页。不要将网页正文直接当成连接列表粘贴。若返回内容与预期不符，应向配置提供方确认地址是否过期、是否需要特定输出格式。客户端只能处理它支持的结构，无法把任意账户网页自动转换为可连接配置。

导入成功但启动时报字段不支持时，重点核对内核与协议参数。VMess、VLESS、Trojan 是不同协议，REALITY 是相关连接配置中使用的安全机制，不能把名称替换就当作完成转换。传输方式、服务器名称与身份凭据都有各自用途。升级或切换内核前先保留原始数据，并确认变化确实针对日志报告的问题。

备份、迁移与最小化披露

迁移时优先使用客户端明确提供的导入导出功能。复制整个目录前先退出客户端，并确认目标平台是否理解同一份结构。系统代理开关、文件路径、证书位置和权限状态属于本机环境，不应默认随连接数据一起迁移。目标设备导入完成后，先测试一条连接，再恢复分组和其他设置，避免一次迁移大量配置后难以定位故障。

订阅泄露后的处理应以撤销或重置访问凭据为核心，单纯修改本地分组名称没有保护作用。分享排错信息时，保留协议类型、传输方式和错误类别即可；服务器地址、身份标识、订阅查询参数以及二维码应遮盖。备份也需要设定保存期限，旧账户、已停用服务与重复导出文件不宜无限堆积。

日常维护不必把更新频率设得过密。先了解服务配置是否经常变化，再选择适度的手动或定时更新；更新与连接检测不是同一动作。操作主线可返回订阅导入指南。若只有某一个分组更新失败，应与其他分组分开排查，不要清空整个客户端来处理单个来源的问题。

路由分流与 DNS 配置

先确定接管范围，再确定出站

代理接管与路由分流处理的是不同问题。系统代理或 TUN 决定请求是否进入客户端，路由规则决定进入后的请求使用哪个出站。一个应用没有采用系统代理时，即使路由设为全局，它的请求也可能没有进入内核。相反，TUN 接管到请求以后，路由仍然可以决定直连、代理或阻断，不能把接管方式与出站模式混为一谈。

首次配置先用客户端已有的简单路由方案，确认普通网页、局域网资源与所需远端目标都能按预期访问。所谓绕过大陆通常依赖域名、地址数据与规则组合，不是地理位置的实时判断。全局代理适合临时缩小分流变量，但也可能影响本地服务或单位网络。测试完成后应恢复适合实际场景的规则，而不是长期保留排错设置。

理解规则顺序与匹配条件

路由通常按规则顺序匹配，较早命中的规则会影响后续规则是否还有机会处理。精确域名、域名后缀、分类数据库、地址范围与端口是不同条件。多个条件组合的含义还取决于内核规则语法，不能把一行里出现的每个字段都理解为任意一个命中即可。修改前应先明确目标请求具有什么信息，以及希望它走哪个出站。

下面是 Xray 路由对象的片段示例，用于说明私有地址直连。它不是可以单独运行的完整配置，合并时必须保留现有入站与出站，并保证名为 direct 的出站已经存在。客户端生成配置时也可能覆盖手工编辑内容，应优先通过对应的路由编辑功能设置，不要直接改动临时生成文件。

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

AsIs 表示该路由策略不主动为了地址匹配而解析域名，并不表示整个系统不会发起 DNS 请求。请求已经携带地址时，地址规则仍可能匹配。geoip:private 依赖对应规则数据，其他分类名称也需要数据文件支持。文件缺失、分类不存在与规则顺序错误会产生不同表现，应从内核日志确认实际失败原因。

把 DNS 路径拆成几个环节

域名可能由应用、系统解析器或客户端内部解析，解析请求自身也可能走不同出站。浏览器启用独立的加密 DNS 时，又会形成另一条路径。因此，修改客户端 DNS 不一定能控制所有应用的解析。排查时先确定是谁发起解析，再查看请求发往哪里、通过什么链路、返回的地址最终怎样参与路由，避免只替换一个服务器地址就结束检查。

系统代理主要处理应用主动交给代理的流量，不保证系统全部 DNS 都被接管。TUN 能扩大覆盖，但是否正确处理 DNS 仍取决于接口、路由与客户端配置。需要检测时，可按DNS 请求走向检测方法逐项确认。检测页面显示的解析出口还可能受到缓存和网络服务影响，不能只看一次结果就断定所有请求路径。

FakeDNS 通过虚拟地址映射辅助后续还原域名，主要用于特定的接管与分流场景。它不是普通公共 DNS 的同义词，也不能孤立地开启后期待所有应用自动兼容。需要对应的拦截、映射与域名恢复链路配合。若应用缓存虚拟地址后改用直连，可能出现连接失败；启停相关功能后，应按实际情况重建连接并处理缓存。

规则维护与验证方法

GeoIP 与 GeoSite 数据会影响分类规则的覆盖范围，但更新文件不能修复错误的规则语法。先确认客户端读取的是哪个文件、更新动作是否成功，再检查分类名称与使用位置。相关背景可查阅GeoIP 与 GeoSite 更新及写法。在配置文件中引用一个并不存在的分类，不会因为名称看起来合理就自动生效。

每次只增加一条规则，用同一个目标新建连接验证，并从日志观察出站选择。应用已有的长连接可能继续沿用旧路径，所以修改规则后不应只刷新界面判断。若目标包含多个域名或跳转流程，需要区分主页面、资源域名与接口请求；一个页面部分加载成功，不代表所有相关域名都走了相同规则。

长期使用时，为局域网资源保留清晰的直连边界，并记录自定义规则的用途。需要复杂 DNS 配合前，可先阅读FakeDNS 原理与开启时机。恢复网络时按相反顺序撤销近期更改：先移除新增规则，再恢复 DNS，最后切换接管方式。保留一份已经验证的简单方案，能够明显缩短下一次排错时间。

配置常见问题与排错顺序

从现象确定故障层级

先把问题描述成可复现的现象：哪个平台、使用哪款客户端、采用系统代理还是 TUN、哪些应用失败，以及关闭代理后是否恢复。再确认最近一次变化，是更新订阅、调整端口、启用 DNS 功能，还是切换网络。不要同时把所有设置恢复默认，否则可能丢失能够解释故障的线索，也会使原本可用的部分难以恢复。

排查顺序应从基础网络到本地进程，再到远端连接和应用行为。先证明设备能联网，再证明内核成功启动并监听端口，再用显式代理验证链路，最后检查系统代理、TUN 和分流。某一层未通过，就暂缓修改更高层设置。这样可以避免用 DNS 调整处理端口占用，或用重装客户端处理系统残留代理。

启动、订阅与连接问题

应用差异与网络恢复

记录有效信息与保留回退方案

日志优先记录故障发生前后的一小段，包含错误类型、时间、客户端名称、操作系统和接管方式即可。分享前遮盖订阅地址、服务器凭据、二维码及账户信息。连接超时、证书错误、名称解析失败和配置字段不支持应分别描述，不要统一概括成“不能用”。清晰的层级信息比大量未经处理的日志更便于复查。

问题解决后，把最终改动记入本地维护笔记，并保留一份验证可用的设置副本。若此前关闭了自启动、后台限制或其他工具，逐个恢复并重复测试，确认没有引入新冲突。需要重新走最短操作流程时返回使用指南；需要更换平台或安装包时返回客户端下载页。本页各章可作为之后升级与迁移时的检查清单。