v2rayN
进阶配置手册

配置层级与修改前备份

区分客户端、内核与操作系统

v2rayN 的主窗口保存服务器资料、订阅分组、路由预设和界面选项。启动连接时，客户端会根据这些资料生成内核需要的运行配置。系统代理则属于操作系统设置，负责告诉遵循该设置的应用把请求交给本地代理端口。这三层关联，但不是同一个开关。修改服务器列表不会自动改变所有应用的入口；切换系统代理也不会替内核添加路由规则。

阅读配置文件前，先在客户端确认当前服务器、路由预设和运行内核，再看底部状态栏与日志。本站桌面操作以 v2rayN 为主，Android 对应 v2rayNG，使用 V2Fly 内核的备选客户端为 v2flyNG。客户端界面相近不代表配置字段相同；即使都能导入一种分享链接，内部生成的配置也可能不同。跨客户端迁移时先迁移连接资料，再逐项重建高级设置。

建立可以返回的基线

修改前通过客户端提供的备份或导出入口保存现有配置，并记录系统代理状态、监听地址、本地端口、当前路由预设和 TUN 开关。若准备复制客户端数据目录，应先退出客户端，让数据库和配置文件完成写入。备份文件可能包含订阅地址和服务器认证资料，适合留在受控的本地位置，不宜直接附在公开的问题描述中。

基线不只是“网页能打开”。还应确认一个日常应用能正常连接、局域网设备能够访问、关闭客户端后系统网络可以恢复。分别记录这些操作依赖系统代理还是 TUN。后续若只有某一类请求出错，就能把问题定位到入口、规则或解析，而不是把所有设置同时改回去。需要重新建立基础连接时，按使用文档的顺序完成一次验证，再继续高级配置。

一次只改变一个变量

建议按订阅、路由、DNS、TUN 的顺序调整。每次只修改一个主题，保存并重载后重新建立连接；仍在运行的长连接通常不会因为规则变动就立即迁移。观察日志时使用同一个目标和同一种应用，避免把缓存、应用重试或站点临时故障误认为配置效果。若需要对比两个设置，先写下预期变化，例如“局域网目标从代理改为直连”，再检查实际出站。

日志等级也应有基线。普通使用保留客户端默认等级即可，排查时再短时提高详细程度。日志中可能出现域名、地址、路径和订阅请求信息；分享前删除认证参数及个人网络信息。错误日志说明发生了什么，不一定说明原因就在最后一行。应从首次失败的位置向前看，先确认内核启动成功，再判断 DNS 和目标连接，避免把后续连锁错误当作多个独立问题。

不要直接编辑客户端临时生成的运行文件并期待长期保留。重新连接、切换服务器或更新订阅，都可能触发再次生成。能在图形界面保存的选项，应在界面修改；需要自定义配置时，使用客户端明确提供的自定义入口，并备份原文。某个字段能通过 JSON 语法检查，也不代表当前内核支持它。出现未知字段、协议不支持或配置解析失败时，先核对内核类型，再检查嵌套位置。

本页后续配置都沿用这条边界：客户端负责保存意图，内核负责执行规则，操作系统负责流量入口。遇到启动失败、端口占用或系统代理残留，可转到常见问题按症状查阅；涉及主窗口位置的说明，可参考v2rayN 主界面功能速览。

订阅分组与服务器过滤

让一个订阅对应一个管理边界

订阅分组适合按配置来源划分，而不是按一次测速结果划分。在 v2rayN 的“订阅分组”中添加分组，填写便于识别的备注和订阅地址，保存后再执行更新。分组备注最好写来源与用途，例如工作设备配置或测试配置，不要把地址中的认证参数复制到备注里。添加完成后先只更新这个分组，确认内容属于预期来源，再让它参与日常选择。

“全部”通常只是服务器列表的汇总视图，不意味着所有行来自同一个订阅。需要删除或批量操作时，先切到目标分组，核对当前筛选条件和选择范围。相同别名可能出现在不同分组中，别名也不是服务器的唯一标识。判断重复项目时，应同时看协议、目标地址、端口和传输设置，不能只因为名称相同就删除其中一个。

分清列表搜索与更新过滤

服务器列表中的搜索主要影响眼前显示的项目。订阅设置里的过滤项则可能影响更新后保留哪些项目，两者的风险不同。列表里看不到某一行时，先清空搜索文字，再检查分组是否选对，最后查看订阅更新过滤。不要在筛选结果仍然生效时判断订阅已经清空，也不要立即删除分组重新添加，否则会丢失原本可用的过滤和更新设置。

部分界面使用关键词匹配，部分过滤项接受正则表达式。应以输入框说明为准，不能把两种语法混用。如果明确支持正则，可先用较宽的包含条件测试，再逐步收紧。下面表达式演示按别名筛选的写法，只匹配明确的名称片段；它不是路由规则，也不决定流量经过哪个出站。名称本身由订阅提供，不能据此保证服务器的实际位置或能力。

香港|日本
^(香港|日本)
测试|备用

第一行表示名称包含其中一个词，第二行要求名称以其中一个词开头，第三行可以用于支持排除正则的输入框。每行是独立示例，不是要一起粘贴的多行配置。若客户端只有一个过滤输入框，先确认它是包含还是排除；正则中的竖线表示“或”，不是普通文字分隔符。遇到订阅名称包含括号、加号等字符时，还应考虑正则转义。

更新之前保留可用项目

更新订阅通常会替换该来源管理的服务器资料，手动修改订阅服务器的字段可能在下一次更新时被覆盖。需要长期保留独立修改时，先复制到专门的手动分组，再修改副本，并给备注加上用途。这样可以区分来源维护的资料与本地维护的资料。手动副本不会自动获得订阅后续的地址变化，因此也要定期确认是否仍然有效，不能把复制当成永久可用的保证。

过滤条件改动后，先执行一次单分组更新，并阅读更新提示。如果结果为空，依次检查过滤方向、表达式、订阅响应和网络连接。返回内容可能是错误页面、登录提示或额度说明，而不是可解析的服务器列表；更新失败不一定是正则问题。应保留原分组资料，恢复较宽条件后再次尝试，不要通过连续全量更新来覆盖已有的可用配置。

分享链接导入与订阅更新也要分开理解。剪贴板导入得到的是当时的一组连接资料，订阅地址则是后续更新入口。两者可能导入相同服务器，但维护方式不同。需要持续更新的配置，应保留来源清晰的订阅分组；一次性测试的分享链接放进手动分组更容易清理。二维码或链接含有连接凭据，不适合当作普通截图公开展示。

服务器选用应结合真实连接验证。TCP 端口能建立连接，只说明链路的一部分可达，并不代表协议握手、目标解析和网页请求都成功。订阅过滤不应依赖一次短暂测试就永久排除大量项目。需要理解不同测试结果时，参阅TCPing、真连接延迟与下载测速的区别，再决定日常筛选依据。

路由规则实战：顺序、匹配与出站

先确定规则处理的是哪些流量

路由规则只处理已经进入内核的连接。一个应用没有使用系统代理，也没有被 TUN 接管时，修改内核路由不会改变它的网络路径。“全局”预设一般表示进入内核的请求优先使用代理出站，并不等于操作系统所有流量都已进入代理。排查规则前，先确认应用入口；系统代理与路由的区别可结合系统代理与路由模式说明阅读。

在 v2rayN 的路由设置中，先复制现有预设，再在副本里增删规则。内核通常从上到下检查规则，先匹配的规则决定出站，因此具体例外应放在宽泛规则之前。若同一条规则同时指定域名和端口，通常要求两类条件同时成立；同一个域名数组中的多个条目则按其中任意一项匹配。把一串条件都塞进同一条规则，可能比预期限制更严格。

建立一个便于验证的顺序

下面片段先处理局域网域名与私有目标地址，再放一个精确域名拒绝示例，最后演示域名集合直连。它只展示 routing 对象，要求完整配置已经定义名为 direct 和 block 的出站，并装载对应规则数据。示例中的保留域名用于解释语法，不代表需要拒绝某个实际服务。未匹配请求走哪个出站，仍取决于完整配置。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:lan"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

full: 用于精确域名，domain: 用于域名及其子域，geosite: 引用域名集合，geoip: 引用地址集合。集合是否存在、覆盖什么内容，取决于实际加载的数据文件。规则数据缺失会导致配置加载失败或规则不可用，不能只看字段拼写正确就认为环境完整。更新数据后，域名归类也可能变化，应重新验证关键业务。

geoip:private 匹配的是私有等保留目标地址，不等于“所有本地服务名称”。使用域名访问路由器、打印机或内部服务时，内核可能尚未得到目标地址；在 AsIs 策略下尤其需要为内部域名配置明确规则。企业网络也可能使用不属于常见私有地址段的内部地址，届时应按实际网段添加 CIDR，而不是盲目扩大直连范围。

理解域名策略与兜底行为

AsIs 不会为了 IP 规则主动把所有域名解析成地址。IPIfNonMatch 可在域名规则未匹配后尝试解析，再进行地址匹配。IPOnDemand 更积极地在需要地址规则时解析。后两者会把路由结果与 DNS 结果联系起来，也可能增加查询和等待。选择策略前，先判断规则主要依据域名还是地址，不要把积极解析当作普遍的性能优化。

完整的 Xray 配置中，未命中路由的连接通常使用出站数组的第一个出站；客户端预设也可能额外生成兜底规则。因此阅读局部片段不能推断最终默认行为。若希望用最后一条规则兜底，需要明确覆盖的网络类型及目标出站，并确认不会抢先吞掉后续规则。改变预设后，应查看客户端生成配置或路由命中日志，核对实际顺序，而不只看预设名称。

验证时为每条关键规则选择一个可重复请求：内部服务检查直连，精确域名检查指定出站，其余域名检查兜底。每次新建连接，记录目标域名、解析地址和出站标签。若规则没有生效，按“是否进入内核、规则是否靠前、条件是否同时满足、出站标签是否存在”的顺序检查。浏览器缓存和连接复用会掩盖变化，重载页面不一定意味着新建了网络连接。

DNS 配置优化：解析路径与路由配合

把解析器与目标连接分开检查

一次访问可能涉及系统 DNS、浏览器安全 DNS、客户端内置 DNS 和远端解析。它们不一定全部参与，也不一定使用相同的网络路径。应用把域名交给代理时，本机可能不需要先解析目标；应用先得到地址再连接时，内核看到的可能只有地址。优化前先说明“谁在问、问谁、查询经过哪里”，否则换了 DNS 服务器却没有改变实际使用的解析器。

DNS 配置中的服务器地址，与查询最终走直连还是代理不是同一个问题。某些内核内部 DNS 请求可以参与路由，某些特殊模式则绕过常规处理。服务端是否能够解析目标，也与本机选择的解析器不同。排查时先用客户端日志确认请求由哪一层发起，再判断失败发生在查询阶段还是目标连接阶段；不要把目标握手失败简单归为 DNS 污染或解析器故障。

从小范围分流开始

下面是 Xray 内置 DNS 的局部示例：常规查询使用一个公网解析器，指定域名集合与局域网名称优先交给局域网解析器。192.168.1.1 仅适用于确实在该地址提供 DNS 的网络，使用前应替换为当前网关或内部 DNS 的实际地址。这里采用普通 DNS 便于说明职责，不代表适合所有网络，也不代表查询已经加密。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": ["geosite:cn", "domain:lan"],
        "skipFallback": true
      },
      "1.1.1.1"
    ]
  }
}

domains 表示该服务器优先处理的域名范围，skipFallback 用来避免它参与其他域名的一般回退选择，并不单独保证内部域名永远不会交给其他服务器。严格的内部域名隔离还要结合所用内核的回退选项与实际查询日志验证。若内部解析器没有返回结果，应先修复内部记录，不要随意增加公共回退，以免把内部命名信息发往不相关的解析服务。

UseIPv4 只是示例查询策略，不是建议所有用户关闭 IPv6。网络具备稳定 IPv6 时，可以采用适合该内核的双栈策略；只有 IPv6 连接持续失败时，才需要对照测试地址族。解析结果有 IPv6 地址，但应用或出站没有可用 IPv6 路径，会表现为等待后回退。应分别确认系统地址、默认路由、DNS 回答和代理端支持，而不是只删掉一条解析结果。

避免解析请求绕回自身

加密 DNS 使用域名作为服务器地址时，首先需要解析这个解析器域名，这就是引导解析问题。若引导过程又依赖同一个尚未建立的加密连接，就会形成循环。客户端可能提供引导 DNS 或静态主机映射，应按当前内核说明配置。启用 TUN 后，还要确认解析器的连接不会再次被错误送入同一入口。日志中反复出现相同查询与连接重试，是需要检查环路的信号。

域名分流最好与 DNS 分流保持相同意图。内部业务走直连时，应能获得内部网络认可的地址；通过代理访问的目标，则要考虑地址对远端是否可达。地址集合规则依赖解析结果，不同解析器返回不同地址时，可能命中不同出站。若目标访问路径频繁变化，先对照路由的域名策略与 DNS 服务器选择，不要立即把所有域名写进地址规则。

修改 DNS 后，需要给缓存一个明确边界。应用、系统和内核都可能缓存答案，只重启其中一层未必生效。先重建应用连接，再按系统提供的方式清理缓存，必要时重启客户端内核。浏览器若启用了自己的安全 DNS，可能继续绕过系统解析设置；验证阶段可暂时使用系统解析进行对照，确认原因后再恢复原设置。不要同时改浏览器、系统与内核三个解析器。

比较配置时，应固定应用和目标，分别观察首次查询、缓存命中后的请求以及重新建立连接的行为。更多解析器不一定更快，过多回退会增加路径不确定性。确认一个默认解析器和少量必要例外后，再考虑细分规则；出现异常时先恢复默认 DNS，保留原路由，便于判断问题是否确实来自解析层。

TUN 模式：接管范围与路由回退

TUN 解决入口，不替代连接资料

TUN 通过虚拟网络接口接收系统交给它的 IP 流量，再由客户端配套的网络栈或核心组件处理。它适合不遵循系统代理的应用，但不等于所有协议都能获得相同行为。普通系统代理主要处理应用主动提交的代理连接，TUN 则涉及系统路由、DNS 和虚拟接口。二者的入口不同，后续仍需要可用的服务器与合适的路由规则。

在 v2rayN 中启用“启用 Tun 模式”前，先确认普通代理方式可以正常访问目标。服务器本身不可用时，增加 TUN 只会扩大故障影响。客户端可能需要管理员权限、系统网络扩展授权或配套组件，具体提示取决于平台和安装方式。按界面提示完成授权即可，不要为了绕过错误随意关闭系统防护或把整个应用目录设成所有用户可写。

先完成一轮最小接管测试

首次测试先退出其他会建立虚拟网卡或改变默认路由的软件，记录当前网络接口，然后启用 TUN。观察启动日志是否完成接口创建，系统中是否出现对应虚拟接口，再用一个原本不使用系统代理的应用验证。若界面开关已经打开但内核未启动，流量可能没有被正确接管。应以日志和实际请求为准，而不是只看开关颜色。

桌面客户端的 TUN 界面可能由不同组件承担，不能把 Xray 的路由片段当成通用 TUN 配置。先使用客户端提供的默认模板，确认基本工作，再修改排除网段、DNS 接管或网络栈选项。Android 的 v2rayNG 通过系统 VPN 接口接管应用流量，相关选项与桌面界面不完全一致；调整应用范围时，需要重新建立连接才能可靠验证。

区分入口排除与内核直连

入口排除表示流量不进入 TUN，内核中的 direct 则表示流量已经进入内核，再由内核直接连接目标。它们可能都能访问局域网，但对日志、DNS 与系统路由的影响不同。访问打印机、文件共享或内部业务时，先判断协议是否适合当前网络栈，再决定使用入口排除还是内核直连。不要因为网页能打开，就认定所有局域网发现协议也会正常。

尤其要注意服务器自身连接的出口。代理出站发往服务器的连接，必须有办法到达真实网络，不能被重新送回同一个 TUN 入口形成循环。客户端默认模板通常会安排相关排除或绑定，但自定义路由、多个虚拟接口和外部网络工具可能破坏这一安排。日志反复建立同一服务器连接、CPU 占用异常或连接立即超时时，应先检查出口环路，而不是继续更换节点。

系统代理与 TUN 同时开启并非一定错误，但会增加入口判断难度。某些应用经系统代理进入本地端口，其他应用直接由 TUN 接管，排查时容易混淆。建立基线时可先清除系统代理，只保留 TUN 验证；需要恢复普通代理模式时，再关闭 TUN 并启用系统代理。修改过程中应记录每一步，避免关闭客户端后留下指向已停止端口的系统代理。

休眠唤醒、切换无线网络或插入有线连接后，默认接口与网关可能变化。若只有这些时刻出现故障，可先重建客户端连接，观察接口和 DNS 是否随网络更新。不要用永久扩大接管范围的方式掩盖恢复问题。退出测试时，关闭 TUN、确认虚拟路由已撤销，并用不经客户端的方式验证基础网络；若仍异常，再按系统网络设置逐项恢复。

FakeDNS：虚拟地址与域名还原

虚拟地址不是目标服务器地址

FakeDNS 为域名分配一个内部使用的虚拟地址，并在内核中保存域名与地址的映射。应用拿到这个地址后发起连接，流量必须再次进入能够读取映射的处理链，内核才能还原域名并继续路由。它的作用是保留域名信息，尤其适合应用先解析再连接的场景。虚拟地址本身不提供远端服务，也不能拿到普通网络中直接访问。

因此 FakeDNS 不是单独更换一个 DNS 服务器就能完成的功能。DNS 回答、虚拟网段接管、映射查询和出站处理需要相互配合。若只让应用获得虚拟地址，却没有让连接进入对应内核，请求就会超时。若 DNS 由一个进程回答、连接由另一个没有共享映射的进程处理，也无法可靠还原。配置前先画出这条路径，比先调整地址池大小更重要。

配置片段需要与入站配套

下面是 Xray 格式的局部示例，展示虚拟地址池与 DNS 选择。它不包含 TUN 接管、完整入站和出站，因此不能独立运行。地址段属于保留用途范围，使用前仍应核对当前网络及其他虚拟接口是否占用。不要把这段配置直接复制进使用另一种字段结构的 TUN 核心；客户端若提供完整 FakeDNS 模板，应优先使用模板保持各部分一致。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"],
    "queryStrategy": "UseIPv4"
  }
}

在支持该机制的 Xray 入站中，还需要相应的域名还原能力。下面仅展示入站对象内的 sniffing 字段，不能作为独立入站使用。这里的 fakedns 表示尝试利用虚拟地址映射恢复目标域名，并不等于对所有加密协议都能读取应用层内容。是否同时启用其他目标探测选项，应按实际协议和内核行为决定。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"]
  }
}

地址池大小决定可维护的映射容量，不决定网速。池过小、并发域名过多或缓存存活时间过长时，旧映射可能被替换。应用若仍缓存旧地址，后续连接就可能失去原来的域名关联。增加池容量只是其中一种处理方式，还要确认内存开销、应用缓存和重连行为。不要把扩大地址池当作所有偶发连接错误的统一解决方案。

处理需要真实地址的例外

局域网名称、内部认证服务或需要把解析地址交给其他设备的应用，可能需要真实地址。此类查询应按域名或用途排除 FakeDNS，并交给合适的内部解析器。例外不仅是 DNS 规则，还要与路由一致：真实地址请求应走正确出站，虚拟地址请求则必须留在映射处理链内。若同一域名时而返回真实地址、时而返回虚拟地址，先检查解析器选择与缓存来源。

应用自带的安全 DNS 也可能绕过 FakeDNS。此时部分连接仍带真实地址，部分连接使用虚拟地址，行为看起来不一致。验证时先固定 DNS 入口，观察查询结果是否落在配置地址池内，再检查内核能否恢复域名。看到虚拟地址只能证明回答生效，不能证明后续连接成功；还必须确认请求命中预期的域名规则，且最终到达真实目标。

安全回退可按以下顺序进行：恢复普通 DNS 配置，重载内核，清理系统与应用的 DNS 缓存，再重新建立连接。必要时退出仍保留连接池的应用。确认虚拟地址不再出现后，检查普通解析和路由是否正常。若只有某个应用在启用 FakeDNS 时失败，先给它建立受控例外进行对照，不要立即把整个地址池扩大或把全部流量改成直连。

FakeDNS 是否值得启用，取决于是否需要解决域名丢失造成的分流问题。已有稳定域名入口、普通 DNS 与路由都工作正常时，可以保留现状。它是一种改变解析与连接关系的工具，不是必选的性能开关；稳定性来自处理链闭合、例外明确，以及可执行的缓存清理与回退步骤。

多订阅管理：更新、去重与跨设备迁移

先制定命名与更新规则

多个订阅同时使用时，最容易失控的不是数量，而是来源与用途混在一起。建议按来源建立独立分组，再用备注区分正式使用、临时测试和手动保留。分组名保持稳定，服务器别名允许由来源更新。不要把订阅地址当作分组名，它可能带有认证信息，也不便于在截图和日志中安全引用。分组顺序可以按使用频率排列，避免每次都在“全部”视图里寻找。

自动更新应围绕实际需要设置，而不是越频繁越好。先确保手动更新可靠，再启用合理的更新周期。多个订阅在同一时刻更新，遇到网络尚未就绪或来源响应缓慢时，错误容易叠加。客户端若支持分别设置更新周期，可让测试来源与日常来源分开；不支持时，至少在切换网络后先确认基础连接，再执行批量更新。

保留订阅更新所需的网络路径

订阅更新可能使用直连，也可能经过当前代理，具体取决于客户端选项。若更新必须依赖当前服务器，而该服务器又已经失效，就会形成维护上的循环依赖。可保留一组近期验证可用的配置作为恢复入口，或者在来源允许的网络环境下直连更新。不要在尚未拿到新资料时删除最后一组可用服务器，更不要把更新失败直接等同于整个订阅已经失效。

遇到更新失败，先区分连接超时、响应内容异常和解析失败。连接超时检查网络路径，响应内容异常检查是否返回了订阅数据，解析失败检查格式与客户端支持范围。错误页面也可能以成功的网络响应返回，因此“请求完成”不代表导入成功。保留原分组并记录错误类型，比重复粘贴地址更有助于排查；分享错误信息时应删除地址中的认证部分。

去重不只比较别名

两个订阅可能包含同一服务器，也可能只是使用同一个地址却有不同的认证、传输或 TLS 设置。去重应比较完整连接参数，并确认客户端的去重功能采用什么依据。仅按别名删除会误伤名称相同但配置不同的项目；仅按地址删除也可能把不同服务合并。正式清理前先备份，先处理单个分组，再检查当前选中的服务器是否仍然存在。

订阅中的服务器被替换或删除后，客户端原有选择可能失效，也可能自动选到其他项目。更新后应核对当前服务器、路由预设和连接状态，不要只看列表仍有内容就认为会话已恢复。自动选择若依赖测试结果，还应确认测试方式与实际用途一致。需要稳定业务路径时，维护一个明确的人工选择流程，通常比频繁重排整个列表更容易定位问题。

迁移连接资料，不盲目复制运行环境

电脑与手机共用订阅地址，意味着两端各自从同一来源获取资料，不代表路由、DNS 和应用接管范围会自动同步。迁移到 v2rayNG 或 v2flyNG 时，应重新检查内核支持、VPN 授权和应用范围。桌面端的本地文件路径、监听端口和 TUN 模板也不适合原样搬到另一平台。先让目标设备完成基础连接，再补上必要的高级规则。

完整备份适合同类环境恢复，单节点分享适合临时迁移，订阅地址适合持续维护。选择方式时要考虑来源是否允许多设备、设备数量限制和更新频率。备份不只是服务器清单，也可能包含界面设置与本地路径；恢复后应检查日志目录、监听地址和启动选项。需要详细比较三种方式，可阅读电脑与手机共用配置方案。

若订阅地址意外公开，仅删除截图并不能让旧地址失效，应在配置来源提供的管理入口更换或撤销相关地址，再更新各设备。日常维护可以保留一份不含认证资料的操作记录，记录分组用途、过滤意图和恢复步骤。这样即使设备更换，也能重建管理结构，而不必依靠记忆判断每一个分组的作用。

自定义出站：标签、接口与连接链

出站标签必须在配置中真实存在

出站是内核把连接交给下一步处理的位置。direct、block 和 proxy 常被用作标签，但标签只是配置中的名称，不是看到单词就自动生成的功能。路由里的 outboundTag 必须对应实际出站对象。一个名为 direct 的标签若绑定了别的协议，其行为也不会因为名称改变。阅读自定义配置时，应同时核对标签、协议与参数。

下面片段定义两个 Xray 出站：一个通过 Freedom 协议直接连接目标，一个通过 Blackhole 协议拒绝连接。它适合解释路由目标，不包含远端代理服务器。数组里的直连出站位于第一项，完整配置若没有匹配路由，默认行为可能因此落到直连；把它合并到已有配置时，必须重新核对顺序，不能直接覆盖客户端生成的出站数组。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

远端代理出站还需要完整的服务器资料、认证信息、传输设置和安全参数。本页不提供虚构服务器配置。实际使用时由已导入的资料生成，再通过客户端支持的路由或自定义配置入口引用。若客户端会自动生成 proxy 标签，不要未经检查再创建同名对象；重复标签可能造成配置错误或不可预期的选择，应保持每个用途对应清晰且唯一的名称。

明确一条连接经过几层代理

多个出站并列存在，通常只是提供多个可选方向，不会自动组成连接链。路由选择某个出站后，请求一般交给该出站处理；要让一个代理出站再通过另一个出站建立连接，需要内核明确支持的转发或连接链设置。相关字段随内核而异，不应把不同配置格式混用。调整前先画出应用、本地入站、第一跳、下一跳和目标，确认每一层的职责。

连接链不一定改善性能。它增加握手、故障点和排查难度，也可能改变 DNS 在哪一端执行。第一跳不可达时，后续配置再正确也没有意义。应先分别验证每个出站单独可用，再验证组合路径；日志中要区分连接代理服务器失败与代理连接目标失败。普通 TCP 请求能够通过，也不保证 UDP 或其他传输具备同等支持，必须按实际业务单独测试。

自定义本地出站与监听范围

如果准备把请求转交给本机另一个代理程序，先确认对方监听地址、端口和协议。SOCKS 与 HTTP 代理不是可以互换的名称。两个程序也不能监听同一个地址与端口组合。连接到本地服务时，应优先使用回环地址；只有确实需要给局域网设备使用，才考虑扩大监听范围，并同时检查防火墙和访问控制。开放监听不会自动提供身份验证。

出站绑定网卡或本地地址适用于明确的多网络场景，但可移植性较差。无线切换、有线断开或系统休眠后，原绑定对象可能消失。除非需要固定出口并能够维护对应设置，否则先使用系统正常路由更容易恢复。TUN 环境尤其要核对绑定是否绕开虚拟入口，避免把出站连接重新送回自身。修改接口设置后，应测试断网重连，而不只验证当前连接。

验证自定义出站可以从一条精确域名规则开始，将测试目标指向新标签，其他请求保留原预设。确认内核正常启动、标签存在、规则命中和目标请求完成后，再扩大范围。如果日志提示未知出站，检查拼写和对象是否被客户端覆盖；如果出站存在但连接超时，检查本地监听、远端可达性和传输支持。配置能加载只是第一步，完整请求成功才是最终验证。

对于日常使用，保留一套标准配置作为恢复入口，比长期维护多层自定义连接更重要。需要新增服务器时先到客户端下载页确认客户端选择，再按使用文档建立基础连接；只有标准入口无法表达具体需求时，再添加自定义出站。完成后保存配置意图、关键标签与回退方法，让下一次修改仍能从明确基线开始。