V2Ray 配置手册
从核心概念到 TUN

阶段一 · 建立概念

核心概念与流量路径

先分清界面、内核与服务器

开始配置前，先把客户端看作两部分：图形界面保存服务器、订阅和规则；代理内核读取配置，负责监听本地端口、处理连接和选择出站。窗口能够打开，只说明界面正常，不代表内核已经启动。判断连接是否可用，应继续检查运行日志、本地监听和实际访问结果，而不是只看托盘图标或开关颜色。

V2Ray 属于 Project V 代理生态中的技术体系，V2Fly 延续相关内核开发，Xray 是另一条内核演进路线。v2rayN 是桌面图形客户端，可以按版本能力调用不同内核；v2rayNG 以 Xray 内核为主，v2flyNG 使用 V2Fly 内核。客户端名称与协议名称不是一回事，同一界面中的配置也不一定能在所有内核上运行。

沿着一次请求理解设置位置

典型路径是：应用发起请求，系统代理或虚拟网卡把流量交给本地入口，内核按路由选择直连、代理或阻断，再由相应出站完成连接。远程服务器承担代理出站的服务端部分。安装客户端并不会自动提供远程服务；订阅地址、服务器信息及使用权限需要由用户合法取得，本站下载页面提供的是客户端入口。

“节点”通常是图形客户端对一组服务器连接参数的称呼，包含地址、端口、协议、身份认证以及传输安全设置。VMess、VLESS、Trojan、Shadowsocks 是协议层面的名称；WebSocket、gRPC 等属于传输方式；TLS 与 REALITY 涉及传输安全。参数需要按服务端配置成套匹配，不能因为两个节点都写着 VLESS 就随意互换安全字段。

建立最小验证闭环

首次操作只保留一个明确目标：让一个应用通过一个已选服务器完成一次请求。先关闭其他代理工具，确认设备时间准确，选择服务器，再开启系统代理。暂时不要同时修改 DNS、路由模板和 TUN。只有最小路径通过验证，后续增加的设置才有可靠的对照；否则多个变化叠在一起，很难知道问题来自哪一层。

验证时区分三种结果：内核无法启动，说明先查本地配置、权限或端口；内核启动但代理连接失败，继续查服务器参数、订阅状态和网络可达性；只有部分应用失败，则检查应用是否遵循系统代理及路由命中情况。界面延迟测试只回答某种测试路径是否成功，不能代替业务访问，更不能直接等同于下载速度。

阶段二 · 选择工具

客户端与安装包选择

桌面优先选 v2rayN

在 Windows、macOS 和 Linux 上，优先使用 v2rayN。这样可以用接近的订阅、服务器和路由管理方式完成日常操作。选择时先看操作系统，再看处理器架构，最后确认包格式。不要从文件名较短、体积较小推断哪个更合适；架构或运行依赖不匹配，通常会在安装、启动或调用内核时直接暴露问题。

Windows 下载入口包含桌面版 Desktop 和经典 WPF 版。桌面版采用跨平台界面，适合希望在不同桌面系统间保持相近操作方式的用户；WPF 版沿用经典 Windows 桌面界面，适合熟悉既有工作流程的用户。两者的界面位置和依赖可能不同，不能把某个版本的截图当成所有版本都适用的菜单说明。

如果没有既有配置需要延续，可以先选择桌面版，再按该安装包的提示补齐运行依赖。已经在 WPF 版中稳定使用的用户，不必只为界面变化立即迁移。准备换版时，先导出必要信息并记录当前设置；让两套程序分别使用独立目录，避免同一配置目录被交替写入，也不要让两套内核同时占用相同监听端口。

安卓按内核与架构选择

Android 首推 v2rayNG，使用 Xray 内核；需要验证 V2Fly 行为或已有相应配置时，再考虑 v2flyNG。两款客户端可以作为不同的测试环境，但不要同时启动连接。系统通常只允许一个应用占用当前用户空间中的 VPN 通道，后启动的工具可能替换前一个连接，这会造成“开关仍在、实际路径已变”的误判。

多数较新的安卓手机使用 ARM64 架构，确认设备支持后选 arm64 包。不能确定架构时，可考虑通用版，再依据安装结果和设备信息核实。应用安装成功不等于订阅中的所有协议参数都受支持：客户端、内核与服务端功能需要一起匹配。出现不支持的字段时，应先确认功能要求，而不是反复更换通用安装包。

区分系统适配与配置兼容

macOS 上，Apple Silicon 对应 ARM64，Intel 处理器对应 x64；Linux 上，deb 适用于相应的 Debian 系包管理环境，rpm 适用于相应的 RPM 包管理环境。Linux 的 ARM64 包也需要 ARM64 系统，不能只因发行版名称相同就安装 x64 包。系统库、桌面环境和权限管理差异仍可能影响启动，包格式正确只是第一步。

选择客户端后，先记录系统、架构、所选界面类型与内核类型，后续排错会反复用到这些信息。下载统一进入下载中心，不要在不同来源之间混用说明。若不确定订阅要求，应向提供方确认协议和传输参数；本章的选择依据是兼容性与操作习惯，不是用客户端名称判断服务器质量。

阶段三 · 准备运行环境

安装、权限与本地监听

先让程序与内核稳定启动

Windows 上先把安装文件或解压后的程序放到固定目录，再启动客户端。对于压缩包分发形式，应完整解压后运行，不要在压缩预览窗口里直接双击主程序。配置、日志和内核文件可能需要相对路径，临时解压位置容易导致设置丢失或找不到文件。目录尽量简洁，避免放进需要特殊写入权限的位置。

首次启动若提示缺少运行环境，按当前所选安装包的要求处理，不要把其他界面类型的依赖说明直接套用。补齐依赖后重新启动，并查看日志是否存在内核启动失败、配置解析错误或监听失败。普通系统代理连接通常不需要把整个客户端长期以管理员身份运行；只有确实涉及虚拟网卡、服务安装等权限操作时，再按提示授权。

macOS 安装时先将应用放到固定的应用目录，并通过系统提供的安全确认流程处理首次打开提示。不要为了启动一个应用而整体关闭系统安全机制。Linux 安装后若界面不能打开，先从终端启动对应程序或查看桌面启动日志，区分图形依赖缺失与代理内核错误；两者的解决方向不同，重复导入订阅不会补齐系统库。

确认监听地址与端口

在参数设置中找到本地混合监听端口，记录当前值。本手册使用 10808 作为演示，实际以客户端显示为准。混合入口通常能识别 HTTP 与 SOCKS 请求，但具体能力仍取决于客户端和内核配置。先仅允许本机使用，监听回环地址；未明确需要局域网共享时，不要打开允许局域网连接或改为所有网卡监听。

如果日志提示端口被占用，先查谁正在监听，而不是连续尝试不同权限。下面的命令只用于查看连接与监听信息，不会结束进程。Windows 查看结果中是否有监听项及对应 PID；Linux 查看本地监听行；macOS 则使用系统自带的端口查询工具。没有输出时，也要确认命令权限和所查端口与实际设置一致。

# Windows PowerShell
netstat -ano | findstr :10808

# Linux
ss -lntp 'sport = :10808'

# macOS
lsof -nP -iTCP:10808 -sTCP:LISTEN

确认冲突进程属于旧客户端时，先正常退出旧程序；属于其他必要服务时，在当前客户端中换一个空闲端口。保存并重启内核后，再确认新端口已监听。所有手动填写代理的应用也要同步改端口。详细定位过程见本地监听端口被占用的排查步骤，不要根据进程编号盲目结束系统服务。

安卓完成首次授权

Android 安装后，首次建立连接会请求 VPN 授权。这是系统为本地流量接管提供的接口，不代表已经连接到远程服务器。完成授权后仍需查看客户端日志和访问结果。若安装报错，先区分架构不匹配、系统版本限制、签名冲突和文件下载未完成；不要先卸载旧应用，因为卸载可能同时移除原有配置和订阅。

阶段四 · 管理连接信息

订阅导入、更新与节点验证

将订阅地址放进订阅分组

订阅地址是客户端获取服务器配置的入口，通常包含访问凭据。复制时保留完整地址，不要删掉查询参数，也不要把链接发到公开讨论区。导入前确认来源与使用权限，并检查复制内容是否混入空格、换行、引号或聊天软件附加的说明。订阅入口需要的是可读取的配置内容，不是服务说明网页或需要交互登录的控制台页面。

在 v2rayN 中打开订阅分组管理，新建分组，填写便于识别的备注，再粘贴订阅地址并保存。回到主界面执行该分组的订阅更新，确认服务器列表是否增加。不同界面版本的菜单名称可能略有差异，但顺序不变：先保存来源，再获取内容，最后选择服务器。不要把订阅地址误填到手动服务器的“地址”字段中。

v2rayNG 和 v2flyNG 可在订阅分组设置中添加来源，再返回主界面更新订阅。二维码和剪贴板导入也可能只导入一个静态服务器条目，不一定建立持续更新的订阅关系。导入完成后应检查分组信息，确认后续维护依靠订阅更新还是手动替换。分组备注只用于管理，不会改变服务器协议或内核行为。

更新失败时先看返回内容

订阅更新一般包含网络请求与内容解析两个阶段。请求超时，先查链接是否仍可访问及当前更新走直连还是代理；解析失败，则重点看返回格式是否受支持。服务端返回的登录页、错误页或额度说明，即使网络请求成功，也不能作为服务器配置导入。客户端显示更新完成后，仍要检查条目数量变化和错误提示，而不是只看操作结束。

首次尚未建立可用代理时，优先尝试正常的直连更新。若该网络确实无法访问订阅入口，且已有可用服务器，再尝试通过代理更新。不要把订阅来源配置为必须通过一个尚未导入的服务器访问，这会形成启动依赖。更新前保留仍可用的旧条目；批量删除后再更新，一旦来源失效，就会同时失去工作连接与排错参照。

选定服务器后再做实际连接测试

导入成功后，先选一条与当前内核兼容的服务器，设置为活动项。可以先做真连接延迟测试，用来筛除明显失败的配置；再用浏览器或命令行验证业务请求。测试结果受测试目标、DNS、线路和时间影响，不是固定性能标签。不要只选列表中最小的一个数字，也不要把一次测试失败解释为整个订阅永久失效。

如果同组大部分条目都失败，先检查设备时间、订阅有效性及协议支持；只有单条失败，再比较该条的地址、端口、安全设置和传输参数。不要擅自修改订阅自动生成的关键字段来碰运气，因为下次更新可能覆盖改动。需要保留实验配置时，复制为独立的手动条目，并明确标记用途，避免与订阅源内容混淆。

完成更新后，再核对活动服务器是否仍然存在。来源改名或移除条目后，原有选择可能失效；分组过滤条件也可能让列表看起来为空。更多分支见订阅解析失败与空列表自查清单。本章完成条件是订阅来源可维护、活动服务器明确，且至少有一条连接通过实际请求验证。

阶段五 · 接入应用流量

系统代理、手动代理与全局模式

先用系统代理验证浏览器

选定活动服务器后，在 v2rayN 中启用“自动配置系统代理”或对应功能。它修改的是操作系统提供给应用读取的代理设置，应用仍可选择是否遵循。多数常规浏览器会使用这一设置，但某些终端工具、下载器和游戏有自己的网络逻辑。浏览器能连接而另一个应用失败时，先确认接入方式，不要立即更换服务器。

“清除系统代理”通常撤销客户端写入的系统入口配置，不代表内核一定已经退出；“不改变系统代理”则可能保留操作系统原先的设置。不同客户端的菜单细节以界面为准。正常退出前，先恢复不需要的系统代理，尤其是手动结束进程时：若系统仍指向本机端口，而监听程序已经停止，遵循代理的应用就会无法访问。

把接管范围与出站策略分开

“全局代理”容易产生歧义。在客户端路由语境中，它通常表示把进入内核的流量优先交给代理出站，并不保证所有应用的流量都进入内核。系统代理解决的是部分应用如何接入；路由模式解决的是已经接入的连接如何出去；TUN 则改变接管范围。三者处在不同层次，不能用一个“全局”按钮概括全部行为。

单个应用支持 HTTP 或 SOCKS 代理时，可以手动填写回环地址与本地监听端口。这样能明确控制该应用的接入，不必立刻开启更大范围的接管。先查清应用要求的协议类型，再填写地址；混合监听入口不代表界面中的每个端口都可互换。不要把远程服务器地址直接填成普通应用的本地 HTTP 代理地址。

使用显式代理进行对照测试

下面两条命令分别通过 HTTP 与 SOCKS 方式访问同一个示例站点。端口要与当前监听一致；Windows 使用 curl.exe 可避免部分终端环境中的同名命令差异。socks5h 让目标域名交给代理侧处理，但最终解析路径仍受内核配置影响。命令成功说明这一请求路径可用，不等于所有应用都已接管。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 -I https://example.com
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 -I https://example.com

在 macOS 和 Linux 中可将命令名换为 curl。先记录显式代理测试结果，再与浏览器比较：命令成功而浏览器失败，检查浏览器扩展、独立代理设置或旧连接；两者都失败，再回到本地监听和代理出站。不要用浏览器缓存页面判断连接成功，必要时打开新窗口并请求一个此前未访问的页面。

Android 的 VPN 模式通过系统接口接入流量，按应用代理设置还会影响实际覆盖范围。首次验证先不要排除测试用浏览器，连接后再按需求缩小应用范围。完成本章时，应能区分“应用没有进入代理”与“进入后出站失败”。快速操作可回看使用文档，异常现象可按疑难解答逐项对照。

阶段六 · 控制出站路径

路由规则、DNS 与分流验证

从内置模式开始，而不是空白规则

系统代理验证通过后，再选择客户端提供的路由模式。初期优先使用内置模板，理解“直连”“代理”“阻断”的含义后再添加例外。直连表示由本机网络直接建立目标连接，不等于流量完全没有经过内核；阻断表示主动拒绝匹配连接，不是连接故障。全局模式可以作为诊断对照，但不必长期替代所有精细规则。

规则通常按顺序检查，先匹配的规则决定路径。某个域名已被上方的宽泛规则命中，下方再精确的规则也可能没有机会生效。新增规则前，先写清匹配对象、期望出站和放置位置，再观察日志。不要同时添加域名、地址段和进程三套重叠例外，否则即使访问恢复，也很难确认到底是哪条规则起了作用。

识别配置片段的适用范围

下面是 V2Ray / Xray 风格的路由片段示例，不是可独立启动的完整配置。它假设完整配置已定义名为 direct 的直连出站和名为 proxy 的代理出站；示例只演示让示例域名及私有地址直连。使用其他出站标签时必须同步修改，图形客户端自动生成的配置也不应直接覆盖，否则保存设置时可能被重新生成。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
        "outboundTag": "direct"
      }
    ]
  }
}

域名规则中的 domain:example.com 用来匹配该域及其子域，不适合表达任意路径条件。代理路由通常看不到加密网页中的具体页面路径，因此不能把完整网址当域名规则填写。私有地址规则方便保留局域网服务，但并未涵盖所有特殊用途地址；实际应优先采用客户端维护的完整模板，再按真实需求补充例外。

DNS 决定规则能获得哪些信息

DNS 负责把域名转换为地址，也影响地址规则的判断条件。示例中的 AsIs 不会仅为了 IP 规则匹配而主动解析域名，它不表示整个连接过程完全不用 DNS。应用若只把解析后的地址交给内核，域名规则未必能直接命中；反过来，只有域名信息而没有解析结果时，某些地址判断也需要额外策略支持。

域名嗅探可以在支持的流量中补充目标信息，但并非任何协议都能恢复域名，也不等于解密应用内容。浏览器的安全 DNS、应用自带解析和系统缓存可能使实际路径与预想不同。排查时先确认失败发生在解析还是连接阶段，再决定是否改解析策略；盲目更换公共 DNS 不能修复错误的认证参数或未运行的内核。

验证分流时，选择一个应直连的目标和一个应代理的目标，分别发起新请求并查看日志中的目标与出站标签。只看网页最终显示的地址不够，因为页面可能使用多个域名。修改规则后应重新建立连接；已有连接可能继续沿旧路径工作。一次只调整一项，保存修改前后的配置摘要，失败时即可回退。

阶段七 · 扩展接管范围

TUN 模式、权限与回退

先确认是否真的需要 TUN

只有应用不遵循系统代理、又缺少可用的手动代理设置时，再考虑 TUN。它通过虚拟网络接口把更广范围的流量引入代理处理链，可以覆盖许多普通代理设置无法直接接入的应用。它改变的是入口范围，不会修复失效服务器、错误认证或不兼容协议。普通系统代理尚未验证成功时，应先解决基础连接，再增加这一层。

v2rayN 的 TUN 能力与当前版本、运行组件和操作系统有关，开关位置及服务要求可能不同。启用前记录现用内核、本地端口、路由模式与 DNS 设置，并保留关闭 TUN 后的恢复路径。不要仅凭某篇旧教程缺少一个按钮，就自行拼接未知内核或替换程序文件；先确认当前安装包提供的功能和界面提示。

按单一入口进行首次验证

首次启用前，关闭其他代理软件与非必要的虚拟网络工具。先清除不需要的系统代理，再按客户端提示启用 TUN，并完成所需的权限或服务授权。这样便于判断连接到底通过哪个入口。某些环境允许两种入口并存，但初次验证不宜叠加；多入口、多个虚拟网卡和多套自动路由同时变化，会显著增加定位难度。

启用后先看日志是否出现虚拟接口创建失败、权限不足、路由添加失败或 DNS 绑定冲突。若接口没有成功建立，反复切换服务器没有意义。若接口已建立但全部访问失败，应先关闭 TUN，确认原有系统代理仍可工作；能够恢复说明基础出站大概率正常，排查重点应放在接管链路，而不是重新导入全部订阅。

同时核对 DNS、UDP 与本地服务

TUN 场景中，DNS 请求可能经过系统解析、内核解析或虚拟地址映射等不同路径，应以实际配置为准。不要把其他内核的 DNS 字段直接复制过来。若网页可用而语音、游戏等业务异常，需要检查 UDP 是否从入口到代理出站都受支持；仅开启虚拟接口并不能保证远程服务器具备完整的 UDP 转发能力。

局域网打印、网络存储和办公内网需要保留正确的直连路径。启用后分别验证本地设备与代理目标，确认两者没有互相影响。企业网络可能下发自己的 DNS 和路由，擅自覆盖会影响内部服务；遇到此类环境应先了解组织的网络规则。IPv6 同样需要明确策略，不能因 IPv4 测试成功就默认所有地址族均已正确接管。

Android 的 VPN 模式也涉及系统流量接入，但不应照搬桌面虚拟网卡的驱动和管理员操作。安卓更常见的问题是 VPN 授权、应用排除名单、后台限制与其他 VPN 工具冲突。完成本章时，应能说明启用 TUN 的具体理由，并验证浏览器、目标应用和局域网服务；关闭后也能恢复原有网络，而不是把开关长期留在未知状态。

阶段八 · 维持可用状态

订阅维护、日志与分层排错

建立可重复的日常检查

日常使用不需要频繁修改配置。连接异常时，先记录发生时间、当前网络、客户端与内核类型、活动服务器、接入模式及路由模式，再重复一次同样的访问。这样的记录能区分偶发网络变化与持续配置错误。手机热点和固定网络的结果不同，也是一条定位线索，但对照时不要同时更换服务器和 DNS，否则无法判断差异来源。

订阅按来源建议或实际变化需要更新，不必用很短间隔反复请求。更新后检查活动服务器是否还有效，以及本地例外规则是否仍然保留。客户端升级前先备份必要设置，并阅读界面中的迁移提示；备份可能包含认证信息，应只放在受控位置。不要把完整配置当作普通文档同步到公开空间，也不要把订阅链接写进排错笔记。

按本地、订阅、节点、系统四层定位

第一层看本地：内核是否启动，监听端口是否存在，设备时间是否准确，磁盘是否可写。第二层看订阅：更新返回是否正常，活动条目是否过期或被移除，协议是否受支持。第三层看服务器：地址与端口能否建立连接，认证与传输参数是否匹配。第四层看系统：应用入口、系统代理、防火墙、虚拟网卡和 DNS 是否一致。

顺序可以根据明确日志提前收敛，但不要跳过证据。比如日志已经提示监听失败，就先处理端口；显示认证失败，就检查身份信息和时间；只有某个应用不通，则优先检查应用入口。关于节点超时，可继续阅读按四层顺序排查连接超时。超时只是结果描述，不说明失败一定发生在远程节点。

日志只保留必要窗口

临时提高日志详细程度，可以帮助确认目标地址与出站路径，但长期保留大量调试日志会增加磁盘占用，也可能记录访问目标。先定位一次失败请求对应的时间段，保存必要片段后恢复常规级别。分享前删去订阅、认证与私人目标信息，并保留完整报错上下文；只截最后一行“失败”，通常不足以区分入口错误和远程连接错误。

网络切换、系统休眠和后台清理都可能让旧连接失效。桌面先检查系统代理是否仍指向当前监听，再重启内核建立新连接；安卓检查后台限制及 VPN 状态。不要一出现异常就清空应用数据，这会丢失最有价值的配置对照。若重启后暂时恢复，应继续记录触发条件，而不是把重启本身当成已找到根因。

阶段九 · 扩展与复盘

进阶配置与长期学习路线

从可解释的规则开始扩展

完成前八章后，进阶重点不是收集更多参数，而是让每项设置都能解释、验证和回退。先选择一个具体需求，例如让某个域名直连、让单个应用使用手动代理，或在网络切换后保持稳定接入。写下预期路径，再找当前配置与预期之间的差异。需求越窄，测试越容易覆盖，也越不容易破坏已经正常的其他业务。

学习配置结构时，先认识入站、出站、路由、DNS 与日志之间的引用关系。标签只是配置内部的名称，必须与引用位置一致；同名字段在不同内核中也可能有不同语义。图形客户端提供的高级设置，应优先通过界面保存。只有清楚生成流程与覆盖规则后，再考虑自定义配置，避免下一次点保存时丢失手工修改。

内核切换采用同条件对照

v2rayN 的多内核能力适合验证兼容性，但不应把切换内核当作随机修复按钮。先确认目标协议、传输与安全字段受新内核支持，再保持网络、服务器和测试目标不变，只替换内核。记录启动结果与实际请求结果。某项能力不受支持时，应回到适合的内核或配置，不要删除关键安全字段来让配置勉强通过解析。

迁移到另一台设备时，也应分步进行。先安装匹配系统与架构的客户端，再重新建立订阅、确认活动服务器，最后迁移路由例外与接入设置。不要默认整个程序目录可以跨平台直接复制；文件路径、权限、接口名称和系统代理机制都可能不同。迁移后至少验证一次直连目标、代理目标及本地服务，确保旧规则没有携带错误假设。

把配置实验做成小范围变更

进阶实验建议保留一份简短变更记录，包含目标、修改项、验证结果和回退动作，不记录真实认证信息。下面的清单可以直接作为每次调整前后的检查顺序。它比一张复杂拓扑图更实用：当结果偏离预期时，能立即确认是否需要回退，以及下一次应该只修改哪一层，而不是继续叠加新的参数。

1. 确定本次只解决一个问题，并记录当前可用基线。
2. 核对目标内核支持的字段，保存修改前的必要设置。
3. 完成单项修改，重新建立连接，查看日志中的实际路径。
4. 验证代理目标、直连目标和局域网服务，记录受影响范围。
5. 失败则回退并复测；成功后再恢复常规日志与日常使用。

远程 DNS、域名嗅探、IPv6 和 UDP 可以作为下一阶段主题，但应分别学习。研究 DNS 时先固定接入模式与服务器；研究 UDP 时先确认服务端支持；研究 IPv6 时同时查看地址族、解析和路由。把这些主题一次全部打开，得到的只是一个更难解释的系统。配置项越多，越需要可观察的日志和明确的测试目标。

性能判断也要建立对照。延迟、连接建立时间、吞吐和稳定性回答不同问题，不能用一次延迟测试代表全部体验。下载慢可能来自目标站点、链路拥塞、连接复用或设备负载；只有固定测试条件并重复观察，才适合比较。关于首次验证的操作细节，可看真连接测试与代理生效验证，避免把列表排序当成完整诊断。