V2Ray 新手到进阶完整配置手册

01

建立模型

核心概念：客户端、内核与流量路径

先区分图形客户端与代理内核

v2rayN、v2rayNG 和 v2flyNG 是面向不同平台的图形客户端。它们负责保存订阅、展示节点、生成运行配置、修改系统代理，并把启动与停止操作包装成可见界面。真正处理连接、协议、传输和路由的是客户端调用的内核。v2rayN 可在桌面系统中管理相应内核；v2rayNG 以 Xray 内核为主要执行组件；v2flyNG 对应 V2Fly 内核。排错时必须分清问题发生在界面层、系统代理层还是内核层。界面显示已启动，只能说明进程已被拉起，不能单独证明目标应用的流量已经进入本地代理。

Project V 是相关协议、工具和实现形成的技术生态，V2Fly 与 Xray 则是其中常见的内核家族。对普通使用者而言，内核差异主要体现在协议支持、配置字段和传输组合上。选择客户端时不需要先研究每个底层字段，但订阅中的节点协议必须被当前内核识别。例如，节点使用 VLESS 与 REALITY 组合时，客户端和内核都需要支持相应字段；仅仅看到订阅成功更新，并不代表节点参数一定能够运行。

用入站、出站和路由理解一次请求

V2Ray 配置可以先抽象成三部分。入站负责接收本机应用送来的流量，常见形式是本地 SOCKS 或 HTTP 端口，也可以是由 TUN 接管的虚拟网络流量。出站决定流量下一步去哪里，通常至少包含代理出站、直接连接出站和阻断出站。路由位于两者之间，它按照域名、IP、端口、网络类型或进程等条件选择一个出站。理解这条链路后，很多界面选项就不再孤立：系统代理是在告诉应用使用哪个入站，节点选择是在确定代理出站的参数，分流规则则负责把不同请求交给不同出站。

以浏览器访问一个网站为例：浏览器先根据系统代理设置，把请求发送到客户端监听的本地端口；内核取得目标域名后，从上到下检查路由规则；命中代理规则时交给当前节点，命中直连规则时由本机网络直接建立连接。若浏览器没有读取系统代理、应用自行实现网络栈，或者目标地址在规则判断前已经被错误解析，流量路径就会改变。因此，“客户端运行”“系统代理开启”“应用流量被接管”是三个需要分别确认的状态。

节点、分享链接与订阅不是同一层对象

节点是一组能够建立连接的参数，通常包含服务器地址、端口、用户标识、协议、传输方式、TLS 相关选项和服务器名称。分享链接是单个节点的序列化表达，例如以 vmess:// 或 vless:// 开头的文本；订阅地址则用于获取一批节点或分组配置，并可在后续更新。订阅不是代理服务器本身，它更接近一份可刷新清单。删除本地订阅并不会改变远端内容，修改订阅生成的单个节点也可能在下一次更新时被覆盖。

协议与传输也要分层理解。VMess、VLESS 等描述连接协议；TCP、WebSocket、gRPC 等描述承载方式；TLS、REALITY 等负责特定的安全与握手组合。不同字段必须与服务端配置一致，不能通过反复切换本地选项猜测。需要进一步确认术语时，可查阅名词解释 →。先建立这套结构，再进入后面的安装和配置阶段，能够避免把“订阅更新失败”“节点握手失败”和“系统未接管流量”混为同一类问题。

02

准备环境

选择客户端与完成安装

按平台和内核需求确定客户端

桌面端首选 v2rayN，覆盖 Windows、macOS 与 Linux，适合需要订阅管理、系统代理、路由规则和 TUN 的用户。Android 可选 v2rayNG 或 v2flyNG：v2rayNG 使用 Xray 内核，适合订阅包含较新 Xray 协议组合的情况；v2flyNG 使用 V2Fly 内核，可作为 V2Fly 配置体系的对应选择。三款客户端的安装入口、系统架构说明和安装包类型集中在下载页 →，不要仅根据文件名中的相似词判断平台。

Windows、macOS 与 Linux 的安装关注点

Windows 用户需要先在桌面版和经典 WPF 版之间选择。桌面版采用跨平台界面，适合希望在不同桌面系统上保持操作方式一致的用户；经典 WPF 版适合习惯传统 Windows 界面和既有配置流程的用户。两者都不应同时接管系统代理。更换版本前先退出正在运行的客户端，并记录订阅地址、路由配置和自定义端口。若系统托盘仍存在旧进程，应先正常退出，而不是直接删除正在使用的程序目录。

macOS 安装时最重要的是芯片架构。Apple Silicon 设备应选择 arm64 对应安装包，Intel 设备选择 x64。可在系统信息中查看芯片类型。首次启动时，系统可能要求确认应用运行权限；启用系统代理或 TUN 时，还可能出现网络配置授权。授权仅用于写入相应系统网络设置，取消授权后相关模式通常不能完整启用。若应用被移动到其他目录，系统对其路径的记录可能变化，建议固定放置后再配置开机启动。

Linux 用户首先按发行版选择 deb 或 rpm 包，再确认处理器架构。Debian、Ubuntu 及其衍生发行版通常使用 deb，Fedora、Rocky Linux 等常见 rpm 系发行版使用 rpm。桌面环境之间的系统代理接口存在差异，客户端写入设置后，应在桌面网络面板中复核 HTTP、HTTPS 或 SOCKS 代理是否指向本地监听地址。仅在终端中运行的程序通常不会自动读取桌面代理，可能还需要显式设置环境变量或使用 TUN。

Android 安装与后台运行条件

近年的主流 Android 设备通常使用 arm64，无法确认架构时可选择通用安装包。安装完成后，首次建立连接会触发系统的网络连接授权，这是创建本地网络接管所需的标准步骤。v2rayNG 与 v2flyNG 不应同时保持连接状态，否则后启动的客户端会占用系统提供的网络接管通道。切换客户端前先断开当前连接，再导入同一订阅进行兼容性比较。

移动系统可能在熄屏后限制后台进程。若连接在锁屏一段时间后中断，应检查客户端的电池使用策略、后台活动权限和省电规则，而不是先修改节点参数。移动网络与无线网络切换会导致已有连接失效，内核需要重新建立出站；此时短暂断开属于网络环境变化，持续无法恢复才需要查看日志。将客户端固定在最近任务列表或允许后台活动，可减少系统回收造成的中断。

安装后先做最小化检查

完成安装后先启动客户端，但暂时不要开启 TUN、复杂路由或自定义 DNS。确认界面能够正常打开、内核组件能够启动、日志目录可写，并记下默认本地端口。随后再导入一条确定有效的订阅或节点，使用系统代理完成首次连接。最小配置能够建立基线：如果此时工作正常，后续问题通常来自新增的路由、DNS 或 TUN 选项；如果最小配置已经失败，则应先检查订阅、节点参数和本地端口占用。

03

建立配置

订阅导入、节点选择与更新

导入前检查订阅地址的边界

订阅地址通常是一段 HTTPS 地址，客户端通过它获取节点清单。复制时要保留完整路径与查询参数，不能只复制域名部分，也不要把页面展示地址和订阅接口地址混用。地址前后若带有空格或换行，应在保存前去除。订阅属于需要谨慎保管的配置入口，不应放入公开截图、日志贴文或可被其他人读取的同步文档。若订阅提供方更换地址，应在客户端中更新订阅项，而不是继续修改旧地址生成的节点。

在 v2rayN 中，通常先进入订阅分组管理，新增订阅名称与地址，保存后执行更新；在 v2rayNG 或 v2flyNG 中，则通过订阅设置新增条目，再返回主界面刷新。名称只用于本地识别，可以写成用途或环境名称。导入完成后应看到节点条目，而不是只有订阅分组。若提示更新成功但列表为空，需查看响应内容是否确实是客户端可识别的订阅格式，以及当前分组筛选条件是否隐藏了新条目。

订阅更新会覆盖哪些内容

订阅节点由远端清单生成，再次更新时，同一节点的服务器、端口、协议和传输参数可能被替换。直接编辑订阅节点只能用于临时诊断，不适合作为长期修改方式。需要保留自定义节点时，应建立独立的手工分组或复制为本地节点，并为其使用明确名称。路由规则、系统代理模式和本地监听端口通常属于客户端设置，不会因为订阅更新而自动变成远端值，但某些订阅可附带分组或规则信息，具体应以导入预览为准。

合理的更新流程是：先停止正在进行的重要连接，执行订阅更新，观察新增、删除与名称变化，再选择一个节点进行测试。不要在更新后同时修改 DNS、路由和代理模式，否则发生异常时难以判断是哪项变化导致。若旧节点消失，应先确认订阅清单是否已经调整；若节点仍在但连接失败，再查看协议字段是否变化以及内核是否支持。

选择节点时不要依赖单一测试结果

客户端提供的连通性测试、延迟测试或真实连接测试代表的检测目标并不完全相同。TCP 端口可连接，只说明网络能够到达指定端口；协议握手成功，才能进一步说明关键参数匹配；目标网站可访问，还受到 DNS、路由和目标服务状态影响。因此，某个测试结果不能替代完整访问验证。更稳妥的方法是先选择节点，启动系统代理，再访问一个已知可用的 HTTPS 页面，同时观察客户端日志中是否产生对应连接记录。

节点名称可以帮助识别用途，但不应被当作协议事实。应在节点详情中确认 address、port、协议类型、传输方式、TLS 开关、serverName 与相关标识。若订阅含有多个协议组合，优先选择当前客户端内核明确支持的节点。v2rayNG 与 v2flyNG 对同一订阅的可见条目可能不同，这通常与内核支持范围或订阅转换结果有关，不代表订阅地址本身一定失效。

手工导入分享链接与 JSON

单节点分享链接适合临时导入或单独测试。导入前可先确认前缀是否为客户端支持的协议，再使用“从剪贴板导入”一类入口。一次复制多个链接时，应确保每行只有一个完整链接。JSON 配置则包含更完整的入站、出站、路由和 DNS 信息，通常不应与图形客户端自动生成的配置直接混合。若客户端提供“自定义配置”功能，应把它放在独立配置项中运行，以免自动节点设置覆盖其中字段。

{
  "address": "server.example.com",
  "port": 443,
  "id": "11111111-2222-3333-4444-555555555555",
  "security": "auto",
  "network": "tcp",
  "tls": "tls",
  "serverName": "service.example.com"
}

上面的字段只展示节点参数之间的关系，不代表可直接连接的服务。真实配置中，地址、端口、用户标识、传输方式和服务器名称必须与服务端一致。出现握手错误时，应逐项核对，而不是任意更换加密或 TLS 选项。想进一步理解分享链接与订阅的差异，可阅读vmess 链接和订阅地址的区别 →。

04

接管流量

系统代理、本地端口与应用边界

系统代理改变的是应用访问入口

系统代理模式会把操作系统中的代理地址指向客户端本地监听端口。支持读取系统代理的浏览器和桌面应用随后把请求交给该端口，再由内核执行路由和出站连接。它不会自动改写所有网络包，也不能保证每个程序都遵循系统设置。某些命令行工具、游戏、虚拟机、容器和自行实现网络栈的程序可能忽略系统代理。遇到“浏览器可用、另一个程序不可用”时，首先检查目标程序是否支持 HTTP 或 SOCKS 代理，而不是先怀疑节点。

客户端界面中常见“清除系统代理”“设置系统代理”“不改变系统代理”等状态。设置系统代理适合常规桌面应用；清除用于退出时恢复系统网络；不改变则只启动本地端口，由用户在具体应用中手工填写。退出客户端前应使用正常退出流程，让客户端恢复先前设置。若程序被强制结束，系统可能仍保留指向本地端口的代理地址，表现为客户端关闭后网页无法访问。此时应重新打开客户端并清除系统代理，或在系统网络设置中手动恢复。

HTTP、SOCKS 与混合端口的区别

HTTP 代理适合浏览器和支持 CONNECT 的应用，SOCKS 代理能够承载更通用的 TCP 请求，并可根据应用实现处理域名解析。部分客户端提供混合端口，让同一监听地址识别 HTTP 与 SOCKS 请求。端口号本身没有协议能力，关键在于该端口对应的入站类型。手工配置应用时，必须让应用选择的代理类型与客户端监听类型一致。把 SOCKS 端口填入仅接受 HTTP 代理的输入框，通常会立即连接失败。

命令行工具应显式确认代理变量

在 Linux、macOS 或 Windows 终端中，许多工具不会自动读取桌面代理设置。可以针对当前命令或当前终端会话设置代理环境变量。以下示例假设客户端的 HTTP 入站监听在本机 10809 端口；实际使用时应以客户端界面显示值为准。环境变量名称存在大小写和工具差异，设置后应通过工具自身的详细输出确认是否采用。

export http_proxy="http://127.0.0.1:10809"
export https_proxy="http://127.0.0.1:10809"

curl -I https://example.com

unset http_proxy
unset https_proxy

如果使用 SOCKS 入站，部分工具支持 socks5h://127.0.0.1:10808。其中带有 h 的形式通常表示域名解析也通过代理端处理，有助于避免本地解析结果与路由预期不一致。并非所有程序都识别该写法，因此要查阅程序自身参数。不要把环境变量永久写入全局启动文件，直到确认该端口会随客户端稳定启动，否则客户端停止后，所有继承变量的终端程序都会继续尝试连接一个不存在的本地服务。

确认本地端口是否真正监听

当应用报告“连接被拒绝”时，应先检查本地入站，而不是远端服务器。Windows 可使用 PowerShell 查看监听状态，Linux 可用 ss。如果端口没有监听，可能是内核未启动、配置生成失败、端口被其他进程占用或安全策略阻止绑定。若端口正常监听但没有任何访问日志，说明应用流量没有进入该入站；若有入站记录并出现远端握手错误，才进入节点参数排查。

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -In 10808,10809

ss -lntp | grep -E '10808|10809'

同时运行多个客户端时，不要让它们使用相同本地端口，也不要让两个客户端同时写入系统代理。建议为测试中的第二个客户端使用不同端口，并保持系统代理指向当前需要验证的一个。完成比较后清理不再使用的监听设置，避免开机启动时发生端口竞争。代理模式的目标是建立清晰、可观察的流量入口，而不是把所有开关同时打开。

05

控制出口

路由分流规则与匹配顺序

路由规则的本质是选择出站

路由不会改变节点协议，它只决定某类流量使用哪个出站。常见出站标签包括 proxy、direct 和 block，分别对应代理连接、直接连接与阻断。规则可以按域名、IP、端口、网络类型和入站标签匹配。图形客户端中的“全局”“绕过局域网”“规则模式”等名称，是对一组路由行为的界面封装；真正判断结果仍取决于生成配置中的规则顺序、条件和最终默认出站。

建立规则时，先写目标明确的小范围规则，再处理大范围集合，最后保留默认去向。例如，本机与局域网地址通常应优先直连；明确需要阻断的域名应放在一般代理规则之前；剩余请求再交给代理或直连。若把一个覆盖范围很大的规则放在顶部，后面的细分规则就不会得到执行。排查“规则写了但不生效”时，第一项检查就是是否已经被更靠前的规则命中。

域名规则与 IP 规则处于不同判断阶段

域名规则使用请求中的域名进行匹配，可采用完整域名、子域名后缀、关键词或 geosite 分类。IP 规则使用目标 IP，可采用 CIDR 网段或 geoip 分类。一个请求是否同时具备域名与 IP 信息，取决于入站协议、DNS 策略以及是否执行域名解析。若只依赖 IP 规则，内核可能需要先解析域名；若解析路径与预期出站不一致，就可能产生循环或错误结果。因此，能稳定用域名表达的服务优先使用域名规则，网络地址范围再使用 IP 规则。

domain: 通常表示精确域名，full: 强调完整匹配，keyword: 会匹配包含指定文本的域名，范围较宽，应谨慎使用。geosite: 和 geoip: 引用分类数据集合，适合管理大量规则，但分类数据需要随客户端资源更新。自定义规则应使用可解释的名称和注释记录在外部文档中，以免几个月后无法判断某条规则的来源与必要性。

一份最小路由配置的结构

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

domainStrategy 决定域名规则未直接得出结果时，是否以及何时解析 IP。AsIs 倾向按原始域名进行匹配，不主动为 IP 规则解析；IPIfNonMatch 会在域名规则未命中时解析 IP，再继续检查 IP 条件；某些内核还提供更积极的解析策略。选择时要考虑 DNS 配置和规则目标，而不是把“解析更多”理解为一定更准确。若现有域名规则已经完整，优先保持简单策略；只有需要基于目标网段分流时，再引入额外解析。

从简单规则逐步扩展

第一次配置分流时，建议只保留三层：私有网络直连、明确域名规则、其他流量走默认出站。确认运行稳定后，再添加广告阻断、特定进程、端口或协议规则。一次加入大批来源不明的规则，会让错误难以定位，也可能把软件更新、局域网设备发现或 DNS 请求误送到错误出站。每次新增规则后，至少验证一个应直连目标和一个应代理目标，并在日志中确认最终出站标签。

端口规则适合处理目标端口明确的协议，但现代服务经常共用 443 端口，仅按端口无法区分具体站点。进程规则依赖平台和接管方式，在系统代理模式下不一定能得到完整进程信息；TUN 环境中的支持情况也受客户端实现影响。不要把某个平台可用的进程规则直接复制到所有设备。跨平台同步时，应优先同步域名和 IP 规则，再为每个平台单独维护进程条件。

路由排错要查看最终命中结果

当某个网站走错出口时，先记录请求域名，再在日志中查找对应连接的 outbound 标签。如果日志只显示 IP，需要检查 DNS 和嗅探设置是否保留域名。随后从规则列表顶部开始，逐条判断该域名或 IP 是否可能提前命中。临时把目标域名加入第一条明确规则，可以验证问题是否来自优先级；验证完成后，再把规则移动到合理位置，而不是长期依赖顶部例外。

涉及中国大陆网络环境的境内直连与境外代理思路，可继续阅读路由分流规则实战 →。配置前还应确认规则数据与客户端资源处于可用状态。路由是一套确定性的匹配流程，只要保留目标、命中规则和出站标签三项证据，就能逐层定位，而不需要反复切换节点碰运气。

06

覆盖更多应用

TUN 模式、DNS 与路由表协作

TUN 解决系统代理覆盖不到的流量

TUN 模式通过虚拟网络接口接收系统流量，再交给内核进行路由和转发。它适合不读取系统代理的应用、部分命令行程序以及需要统一接管的桌面环境。相比系统代理，TUN 更接近网络层，因此配置范围也更广：虚拟接口地址、系统路由、DNS 接管、MTU、绕过地址和权限都可能影响结果。首次使用 TUN 前，应先确认同一节点在普通系统代理模式下能够连接，以便把节点问题与 TUN 环境问题分开。

启用时客户端通常需要系统网络管理权限，用于创建虚拟接口和写入路由。客户端正常退出后应删除这些临时设置；若进程异常结束，可能留下旧接口或路由。出现“关闭客户端后网络仍异常”时，可以先重新启动客户端并正常关闭 TUN，再检查系统网络接口与默认路由。不要同时运行多个会修改虚拟网卡或路由表的网络工具，否则相同目标网段可能被不同规则反复覆盖。

DNS 决定路由能看到什么信息

应用访问域名时，必须先获得解析结果。DNS 请求若绕开客户端，内核可能只看到后续连接的 IP；DNS 请求若被 TUN 接管，则可以结合域名规则选择解析服务器和出站。配置目标不是让所有查询都走同一条路径，而是让解析结果、路由判断和实际连接保持一致。例如，准备直连的内部域名应由能够解析该内部区域的 DNS 处理；需要按域名代理的请求，则应确保内核仍能取得原始域名用于规则匹配。

常见异常包括：域名解析成功但得到不可达地址、DNS 请求被路由回本地入站形成循环、应用缓存旧结果、IPv6 结果优先但当前路径不支持，以及浏览器启用独立 DNS 设置后绕过系统方案。排查时可先清理应用与系统 DNS 缓存，再查看客户端日志是否出现查询记录。若直接访问目标 IP 有响应而域名失败，重点检查 DNS；若域名已解析且连接在握手阶段失败，则回到节点和传输参数。

Fake DNS 与真实解析的使用边界

部分 TUN 配置使用 Fake DNS：内核先向应用返回一个保留地址，再通过映射关系恢复原始域名并执行路由。这有助于保留域名信息，也能减少应用绕过域名规则的情况。但它要求相关流量始终经过同一内核映射，若应用把保留地址缓存后在客户端停止时继续访问，就会失败。局域网服务、需要真实 IP 的程序和某些点对点场景通常应加入排除范围，不适合一律交给 Fake DNS。

是否启用应由实际需求决定。普通浏览器和支持系统代理的应用已经稳定工作时，没有必要仅为了“配置更完整”开启。需要覆盖特定不遵循系统代理的程序时，可以先使用真实 DNS 的 TUN 配置，确认路由与 MTU 正常，再评估是否引入 Fake DNS。每增加一个处理层，都应保留关闭后的对照结果。

MTU、IPv6 与局域网绕过

MTU 决定虚拟接口单个数据包可承载的大小。设置过大可能在部分网络路径中产生分片或丢包，表现为小页面可打开、较大响应停滞；设置过小则增加额外开销。没有明确症状时应保留客户端默认值。若仅在特定网络环境下出现 TLS 握手停顿或上传失败，可逐步降低 MTU 进行对照，每次修改后重建 TUN 接口并记录结果，避免连续调整多个网络参数。

IPv6 需要从系统、DNS、节点与出站路径四层同时看待。系统获得 IPv6 地址并不等于代理出站一定支持；DNS 返回 AAAA 记录后，应用可能优先尝试 IPv6。若当前配置没有完整的 IPv6 路由，应明确采用客户端提供的策略，而不是在系统与客户端之间形成一半启用、一半阻断的状态。局域网网段则通常应直接绕过，保证打印机、路由器管理页、文件共享和本地开发服务不被送往远端出站。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "port": "53",
        "network": "udp",
        "outboundTag": "dns-out"
      }
    ]
  }
}

示例表达的是规则关系：私有地址优先直连，符合条件的 DNS 流量交给专用出站。实际配置中必须同时定义名为 dns-out 的出站，否则规则引用会失败。图形客户端可能自动生成这些结构，不应在不了解生成逻辑时直接覆盖完整配置。需要自定义时，先导出当前运行配置，确认入站和出站标签，再添加最小规则。

按四步启用 TUN

第一步，在系统代理模式下验证节点与订阅；第二步，关闭其他会写入网络路由的程序；第三步，启用 TUN 但保留默认 DNS 与 MTU，测试浏览器、命令行工具和局域网地址；第四步，再根据日志添加 DNS 分流或绕过规则。若某一步失败，回到上一步确认，不要同时开启 Fake DNS、修改 MTU、切换 IPv6 和导入大规模路由。稳定的 TUN 配置来自逐层验证，而不是开关数量。

07

保持可用

日常维护、日志阅读与故障排查

把更新拆成客户端、内核、订阅和规则数据

日常维护不是反复重新安装。需要关注的对象至少有四类：图形客户端负责界面与配置生成，内核负责协议运行，订阅提供节点参数，规则数据提供 geosite 与 geoip 分类。它们的更新节奏不同，也可能由客户端分别管理。出现问题时，应记录最近改变的是哪一层。客户端更新后界面行为异常，与订阅更新后单个节点失效是两种不同问题；规则数据陈旧则更可能表现为分类匹配偏差，而不是所有节点同时无法启动。

更新前保留订阅名称、自定义路由、本地端口和关键截图。更新完成后先用原有节点和简单系统代理验证，再恢复 TUN 或复杂规则。不要把客户端更新、订阅刷新和路由大改安排在同一次操作中。若需要回退，应回退最近发生变化的一项，并核对配置目录是否仍兼容。自动启动用户还应确认更新后启动路径没有改变，系统托盘中不存在旧进程。

日志应按时间和连接阶段阅读

有效日志通常包含配置加载、入站监听、DNS 查询、路由结果、出站拨号和协议握手等阶段。排查时先清空旧日志或记下当前时间，再只执行一次目标操作。大量历史记录会掩盖真正错误。看到 connection refused 时要区分拒绝来自本地端口还是远端地址；看到超时则要判断发生在 DNS、TCP 建连还是协议握手；看到配置字段错误，说明内核甚至没有进入网络连接阶段。

日志级别可临时提高以获取详细信息，但长期保持过高等级会产生大量文件，并可能记录访问域名等运行信息。完成排查后应恢复常规级别。分享日志前，应删除订阅地址、服务器地址、用户标识、认证字段和本地路径，只保留错误类型、发生阶段和必要上下文。不要只截取最后一行，因为真正原因可能出现在前面的配置加载或 DNS 记录中。

按现象选择排查分支

系统时间、端口冲突与权限是高频基础问题

TLS 与 REALITY 等握手依赖合理的系统时间。设备时间偏差明显时，可能出现证书时间或握手相关错误。应启用系统时间同步，并确认时区设置正确。端口冲突则常发生在同时运行旧客户端、测试版或其他本地代理时。通过系统命令查看监听进程，比反复更换随机端口更直接。若决定修改端口，系统代理、应用手工代理和环境变量都要同步更新。

权限问题主要出现在 TUN、系统代理写入、配置目录和日志目录。普通系统代理通常不需要长期以高权限运行；TUN 创建虚拟接口时则可能需要系统授权。若程序只能在提升权限后启动，应查看具体失败文件或网络操作，不能把长期高权限运行当作默认解决方案。配置目录放在不可写位置时，客户端可能能打开但无法保存订阅和规则，关闭后修改全部丢失。

恢复网络时先撤销接管，再处理节点

如果客户端异常后整个系统无法访问网络，第一目标是恢复本地网络设置。先关闭 TUN，清除系统代理，确认系统 DNS 和默认路由恢复，再测试不经过客户端的普通连接。只有基础网络恢复后，才重新启动客户端检查节点。若一开始就连续切换节点，会保留错误的系统代理或虚拟路由，使所有节点看起来都失效。

移动端出现断流时，先检查网络是否从无线网络切换到移动网络、客户端是否被后台限制，以及系统网络接管标识是否仍存在。桌面端睡眠唤醒后无法恢复，可先停止连接再重新启动内核，让旧套接字和 DNS 状态被重建。频繁发生时再检查开机启动、睡眠策略和网络接口变化日志。

建立月度维护清单

稳定使用后，每月执行一次轻量维护即可：更新订阅并删除明确失效的本地副本；检查客户端与内核是否有兼容性更新；确认规则数据能够正常加载；清理过大的日志文件；检查开机启动与系统代理退出恢复；对一个直连目标和一个代理目标进行路由验证。修改记录应写明日期、改变项和回退方法。这样发生故障时，可以从最近变更开始，而不是把整个环境重置。

若准备更换设备，可导出客户端允许导出的本地设置，同时单独记录订阅入口和自定义规则。新设备上先安装对应平台客户端，再恢复订阅，最后迁移路由与 TUN。不同操作系统的路径、进程规则和网络接口名称不应直接复制。快速操作可回到使用文档 →，客户端差异可查看选型指南 →。

08

理解底层

进阶路线与配置文件结构

从图形选项映射到底层配置

进入进阶阶段，不需要立刻放弃图形客户端。更有效的方式是先导出或查看客户端生成的运行配置，把界面中的本地端口、当前节点、路由模式和 DNS 选项映射到 JSON 字段。系统代理对应的是操作系统设置，不一定直接出现在内核配置中；本地 SOCKS 或 HTTP 端口位于 inbounds；节点与直连出口位于 outbounds；分流位于 routing；域名解析位于 dns。理解映射后，才能判断某个界面开关是修改配置文件还是修改系统环境。

客户端通常会在每次启动时重新生成运行配置，所以直接编辑临时文件可能在下一次启动后消失。需要长期使用自定义 JSON 时，应采用客户端提供的自定义配置入口，或把修改写入其支持的模板与路由编辑器。修改前先复制原配置，并使用 JSON 解析工具检查语法。JSON 不允许注释、尾随逗号和未转义的特殊字符，这是许多“配置看起来正确但内核无法启动”的直接原因。

最小配置包含哪些必要部分

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-2222-3333-4444-555555555555",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "service.example.com"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

这份示例展示结构关系，不包含可连接服务。入站仅监听 127.0.0.1，因此只接受本机请求；若改为监听所有接口，就会扩大可访问范围，必须同时考虑防火墙与认证。代理出站使用示例 VLESS 参数，真实使用时必须替换 address、port、id、传输和 TLS 字段。direct 与 block 出站提供路由目标，规则先将私有地址交给 direct，未命中的流量按内核默认行为选择后续出站。

入站标签与出站标签是配置连接点

tag 不负责加密或联网，它是配置内部引用名称。路由通过 outboundTag 选择出站，也可以用 inboundTag 限定某条规则只处理特定入站。标签拼写必须完全一致，改名时要同步修改所有引用。配置复杂后，建议采用 socks-in、tun-in、proxy、direct、block 这类表达用途的名称，而不是数字编号。

多个入站可以使用不同路由策略。例如，本地浏览器 SOCKS 入站使用普通规则，TUN 入站额外处理 DNS；多个出站则可表示不同节点或不同连接方式。此时可以用 balancers 或更复杂的路由结构组织，但不应在没有明确需求时增加。节点切换由图形客户端管理已经足够时，手写多个出站反而会让订阅更新难以同步。

先学会验证配置，再扩展功能

配置验证分为三层。第一层是 JSON 语法，确保括号、数组、字符串和逗号正确；第二层是内核配置检查，确认字段名称、协议结构和标签引用有效；第三层是运行验证，确认端口监听、路由命中和握手成功。语法通过不代表协议参数正确，进程启动也不代表应用已经使用该入站。每次增加一个出站或规则后，都应重新经过三层验证。

复杂配置适合拆成可测试的小阶段。先保留一个 SOCKS 入站和一个代理出站，确认手工指定代理的浏览器可以访问；再加入 direct 与基础路由；之后加入 DNS；最后才增加 TUN。若客户端支持查看最终运行配置，应以最终文件为准，因为界面模板可能自动补充 mux、日志、策略或 DNS 字段。进一步逐段阅读可参考配置文件结构详解 →。

协议选择应服从服务端参数与兼容性

VMess 和 VLESS 都是生态中的常见协议。VMess 包含自身的认证与数据处理机制，VLESS 结构更精简，常与 TLS、REALITY 等安全层组合。客户端侧不能单独决定协议：服务端提供什么参数，本地就必须使用匹配配置。性能差异也不能脱离网络质量、传输方式、加密层和设备能力单独判断。普通用户应优先保证内核支持、参数一致和连接稳定，再考虑更细的传输开销。

当订阅同时提供多种协议时，可以用同一网络环境分别测试连接建立、长连接稳定性和移动网络切换恢复，不要只比较一次端口探测。涉及协议概念时，可阅读VMess 与 VLESS 差别 →。涉及 OpenWrt 主路由或旁路由部署，则应先理解设备将承担的入站、透明接管、DNS 与路由职责，再查看OpenWrt 部署要点 →。

形成自己的进阶顺序

建议把后续学习拆成四个阶段。第一阶段能够解释应用、系统代理、本地入站与远端出站之间的路径；第二阶段能够写出私有网络直连、指定域名代理和阻断规则，并根据日志确认命中；第三阶段能够独立处理 TUN、DNS、MTU 与局域网绕过；第四阶段才进入多入站、多出站、按进程分流或路由器透明接管。每个阶段都应保留一份最小可用配置作为回退基线。

真正的“从零到进阶”不是开启全部选项，而是能判断一个请求停在哪一层：应用是否送入本地端口，DNS 是否得到预期结果，路由命中了哪个出站，内核是否完成远端握手。掌握这四个问题后，客户端界面、JSON 配置与系统网络设置就能放进同一个模型中。需要重新选择安装包时返回客户端下载页 →，需要按最短步骤重新配置时返回快速上手文档 →。