V2Ray 进阶配置手册

订阅分组与服务器过滤

订阅分组的首要作用是隔离来源，不是改变连接协议。每个订阅来源单独建组，可以明确更新范围、条目归属与停用边界。v2rayN 通常在“订阅分组”相关入口添加名称和地址；v2rayNG、v2flyNG 在订阅设置中管理来源。不同客户端的菜单文字可能不同，但原则相同：先建立来源，再更新该来源，最后检查导入结果。

按来源建组，再决定显示范围

组名建议描述来源用途，例如“日常来源”“备用来源”“手工配置”。不要把凭据、完整订阅地址或账单信息写进名称。多个来源即使提供相似条目，也应保持分组独立；后续某个来源停止更新时，可以只停用对应组，而不必从一张混合列表中反查。手工条目宜另建组，避免与订阅生成的条目混在一起。

填写订阅地址时，保留完整查询参数。部分订阅依靠地址中的令牌识别账户，随意删去问号后的内容会使更新失败。若地址由二维码或剪贴板导入，注意首尾空格、换行与全角标点。不要在公共转换服务中提交含认证信息的地址；格式处理优先使用可信的本地方式，具体结构可查阅订阅链接格式说明。

理解过滤发生在哪一步

“搜索”“显示过滤”“导入过滤”并不是同一件事。搜索通常只改变列表显示，不删除服务器；导入过滤可能使不匹配的条目根本不进入当前分组；删除则会改变本地条目集合。调整前先看选项说明，确认过滤是否会影响下一次订阅更新。无法确认时，先使用列表搜索，不要直接在订阅入口写入复杂表达式。

如果当前客户端支持正则表达式，可用简单且有边界的规则筛选名称。先在少量条目上验证，再扩展到整个来源。订阅名称由提供方决定，可能包含前缀、空格或不同语言，因此名称匹配并不等同于地理位置判断。过滤结果为空时，应先取消过滤重新更新，确认原始订阅确有条目，再检查大小写、分隔符和表达式语法。

^(日常|备用)-
^(?!.*测试).*$

上面两行是相互独立的正则示例：第一行匹配以“日常-”或“备用-”开头的名称；第二行排除名称中含“测试”的条目。只有明确标注支持正则的字段才适合使用，普通搜索框不一定解释这些符号。名称筛选仅用于管理列表，不能证明协议兼容、服务可用或路径符合预期。

更新后检查条目变化

更新指定分组后，先检查协议类型、地址、端口与传输方式是否成功解析。条目数量发生变化可能来自来源调整、过滤规则或格式识别差异，不应直接理解为客户端丢失配置。若整个分组消失或为空，先查看更新响应与解析错误，再恢复此前的过滤条件。重复点击更新通常不能解决格式不兼容，反而可能触发来源端请求限制。

不要依靠在订阅条目里手工改名、改传输参数来保存长期修正。下一次更新可能覆盖这些变化，也可能重建条目。确有临时修正需求时，将条目复制到手工分组，清楚标注用途，并记录与原条目的差异。原订阅仍保持原样，方便判断问题出在来源数据还是本地修改。

切换分组不一定等于切换正在使用的服务器。更新后应重新确认当前选中项，尤其是原条目被移除或重新生成时。移动端还要检查服务是否需要重新启动才能载入变化。以启动日志中的实际目标与出站为准，不以列表高亮颜色作为唯一依据；列表整理完成后，再进入路由配置，避免把来源管理问题误判为分流故障。

DNS 配置与解析路径

DNS 问题要拆成三个对象：谁发起查询，谁处理查询，查询请求经哪条路径到达上游。浏览器、操作系统、代理内核和 TUN 接管组件都可能处理解析。修改客户端里的 DNS 地址，不代表所有应用立即采用该地址；应用自带的加密 DNS、系统缓存和已建立的连接，都可能继续影响观察结果。

先明确内置 DNS 的职责

代理内核的内置 DNS 通常用于内部域名解析、路由判断或特定出站行为，它不一定自动成为系统默认解析器。系统代理模式下，一些应用会先由系统解析，再把 IP 交给代理；另一些应用则把域名交给代理入口。两条路径看到的 DNS 行为不同。要实现系统查询接管，通常还需要 TUN 侧的 DNS 劫持或相应系统设置。

v2rayN 的 DNS 界面可能按所用内核分开配置。v2rayNG 的远程 DNS、本地 DNS 与相关路由选项也应结合当前模式理解，不要仅凭“远程”二字判断流量必然通过代理。先保留客户端默认方案，确认普通连接可用，再调整上游地址与域名分流。完整替换 DNS 配置前，应记录已有规则与备用解析器的用途。

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

这是 Xray 风格的 DNS 合并片段，展示分类查询与备用解析器，不保证适合每个网络。domains 为对应域名选择服务器，skipFallback 使该服务器不参与其他域名的常规回退。它不表示被选中的域名永远不能尝试其他服务器，完整回退行为还受其他选项影响。上游能否访问、如何出站，仍需在实际配置中验证。

加密解析与引导解析

使用以域名表示的加密 DNS 服务时，客户端必须先知道该服务地址，才能建立加密连接，这就是引导解析问题。若引导解析又依赖同一个尚未建立的服务，就会形成循环。应使用明确可达的引导路径，或采用当前内核支持的静态映射方式。不要只把普通 DNS 地址换成一个加密地址，就假定解析链路已经完整。

远端代理服务器的域名也属于这条链路。若服务器地址必须通过代理才能解析，而代理又需要先连接服务器，启动就会卡在前置解析。排错时先检查服务器域名能否在服务启动前解析，再检查上游连接是否被错误送回自身。加密 DNS 保护的是查询传输过程，不会自动修正路由、服务器证书或错误的系统时间。

IPv4、IPv6 与缓存的影响

UseIP 允许使用两类地址结果，并不保证系统具备正常的 IPv6 连通性。若网络提供了 IPv6 地址但出口不可用，应用可能等待连接失败后才回退，表现为首开缓慢。先比较 IPv4 与 IPv6 的实际路径，再决定是否采用仅 IPv4 的查询策略。关闭某个查询类型也不能覆盖所有应用自行解析或直接使用 IP 的行为。

验证 DNS 时，系统查询工具只能说明系统所用解析器的结果，不一定证明代理内核的内置 DNS 工作正常。应同时查看客户端日志和应用连接记录。修改后需要考虑系统缓存、浏览器缓存与内核缓存；逐一清理或重启测试对象，比反复更换上游更容易获得可解释的结果。缓存未过期时，一次成功访问不能证明新解析器已经参与查询。

若域名能解析却无法访问，继续检查返回地址与路由出站是否一致，不要继续停留在 DNS 层。若只有局域网短名称失效，则检查搜索域与本地解析服务是否被接管。企业内部域名、打印服务名称和家庭网络设备可能依赖本地 DNS，适合设置明确的本地解析例外，而不是全部交给公共上游。

FakeDNS 与域名映射

FakeDNS 为查询域名分配合成 IP，并在内部维护域名与地址的映射。应用随后连接该地址时，接管组件可恢复原始域名，再进行域名分流或交给代理出站解析。合成地址不是目标服务器的真实地址，也不是新的远端服务器。它的价值在于保留域名上下文，减少应用先解析成真实 IP 后丢失域名信息的情况。

开启条件是完整的映射链路

FakeDNS 至少需要三部分配合：查询进入指定解析器、合成地址连接被同一套接管链路捕获、连接处理阶段能够恢复域名。只在 DNS 服务器列表中加入一个名称，而没有接管对应流量，应用可能直接把合成 IP 发往普通网关。反过来，仅配置嗅探也不会自动把系统 DNS 查询交给 FakeDNS。

先确定由谁负责合成地址。v2rayN 的 TUN 接管组件可能已经提供自己的假 IP 功能，此时不应再盲目叠加 Xray FakeDNS。两个组件各自分配地址和维护缓存，可能导致恢复域名时查不到映射。v2rayNG 与 v2flyNG 的入口和支持范围也不同，应按当前内核与客户端能力确认，不能仅因设置名称接近就推断实现一致。

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

这是 Xray 风格的功能片段，不是完整 DNS 接管方案。地址池使用专用测试地址范围，但这不意味着当前环境一定没有冲突。若局域网、企业网络或其他虚拟接口已经使用该范围，应先调整方案。地址池大小决定映射容量，不等同于并发连接上限；增大容量也不能解决没有接管查询或映射恢复缺失的问题。

入站恢复与嗅探边界

在由 Xray 直接处理对应流量的方案中，相关入站还需要启用与 FakeDNS 匹配的恢复机制。配置位置应是接收合成地址连接的那个入站，而不是随便选择一个监听入口。下面展示常见的嗅探片段，必须结合实际入站结构使用；若接管组件已在上游恢复域名，则应以该组件的配置方式为准。

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

普通 HTTP 或 TLS 嗅探与 FakeDNS 映射不是同一来源。前者尝试从应用协议获得域名，后者依赖此前的查询记录。某些协议、加密握手方式或直接 IP 请求无法提供可用域名；不能把嗅探当作必然恢复一切目标名称的功能。是否只影响路由、是否替换连接目标，也应按当前内核的具体选项理解。

缓存、切换与兼容性处理

启用后先查询一个未缓存的域名，确认应用收到合成地址，再观察连接能否恢复到该域名。停止服务或更换接管组件后，应用可能仍缓存旧的合成 IP，而新服务没有对应映射，表现为部分站点突然无法访问。此时应清理相关 DNS 缓存并重启应用，而不是继续扩大地址池或反复更换远端服务器。

局域网服务发现、对解析结果进行地址检查的程序，以及依赖真实地址的诊断工具，可能不适合使用合成地址。应优先为这类目标保留明确的真实解析例外，并验证例外是否同时覆盖 DNS 与连接路径。浏览器自带加密 DNS 还可能绕过接管解析器，使同一应用中的不同请求走不同链路，排查时需记录该设置状态。

若启用前后没有明确收益，保留普通解析方案更便于维护。回退时按顺序停止接管、恢复 DNS 配置、清理缓存、重新启动应用，再验证直连与代理目标。不要只删掉 FakeDNS 字段而继续让系统使用残留的合成地址；配置恢复与缓存恢复必须一起完成，才能得到可靠的对照结果。

自定义出站与配置回退

出站定义连接最终如何离开代理内核，路由通过标签引用它。常见用途包括直连、代理和阻断，也可以连接本机另一个已经运行的代理入口。自定义出站适合解决明确的路径需求，不应作为普通服务器导入的替代品。开始前必须知道每个标签对应什么服务、监听在哪里，以及停止该服务后会发生什么。

标签是配置内的引用关系

tag 是人为指定的标识，不会自动创建协议能力。路由写了 proxy，配置中就必须存在同名出站；名称相近并不等价。原生 Xray 配置中首个出站通常承担未命中规则的默认路径，因此出站顺序也有意义。客户端生成的配置可能另加默认规则，检查时应看实际运行结构，而不是只看编辑框中的局部片段。

下面是一份可用于本地链路测试的完整 Xray 风格配置：本机应用连接一个 SOCKS 入站，普通目标转交给本机另一 SOCKS 服务，私有地址直连。它不包含远端服务器凭据，前提是被引用的上游服务确实已在对应端口运行。不要让上游服务再次指回当前入站，否则会形成循环转发。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-in",
      "listen": "127.0.0.1",
      "port": 10810,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 10809
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

先检查协议与端口，再检查规则

使用前确认 10810 未被占用，且 10809 提供的是 SOCKS 服务。HTTP 代理端口不能仅因也叫“代理端口”就填入 SOCKS 出站。这里的端口是独立测试值，不代表客户端默认值。监听地址限定为本机回环，避免意外向局域网开放未经认证的入口；需要远程访问时，应另行设计认证、防火墙与访问范围。

示例关闭了入站 UDP，仅用于 TCP 链路验证。不能由此推断同样配置可以承载所有 UDP 应用。若要增加 UDP，需要同时检查入站、上游 SOCKS 服务与后续链路的支持。直连出站与阻断出站只是定义，只有路由命中或成为默认路径时才会被使用；添加一个名为 block 的出站，不会自动阻断任何目标。

自定义配置的接入边界

在 v2rayN 中使用自定义配置入口时，选择与文件语法一致的内核，并确认客户端如何识别本地监听端口。某些管理选项不会继续修改这份文件，系统代理设置也可能仍指向旧端口。移动端导入能力与桌面不同，应使用当前客户端支持的配置类型，不要把文件能够保存等同于服务能够按预期启动。

多个代理串联会增加依赖与排错成本。先分别验证上游与下游，再连接两者；检查任何一层是否重新接管了另一层的出口流量。若目标只是给少数域名选择不同路径，优先使用清晰的路由与独立出站，不要为了分类而增加不必要的代理层。协议选择本身可参考常见协议区别，但传输能力仍由实际链路决定。

按相反顺序回退

启动失败先读首条明确错误：JSON 语法、未知字段、端口占用和出站引用缺失应分别处理。启动成功但无法连接时，再检查上游是否监听、协议是否一致及默认出站是否正确。临时提高日志详细程度后，应只复现必要请求，排查结束恢复日常级别，避免持续保存包含访问目标的记录。

回退时先停用新增接管与自定义条目，再恢复原路由和 DNS，最后重新选择已验证服务器并建立新连接。若修改过系统代理端口，也要同步恢复。将本次变更记录为“目的、改动、验证、回退”四项，比保存一份来源不明的大配置更容易维护。首次配置主线仍以快速上手教程为准，具体症状可到疑难解答继续定位。