V2Ray 配置文件参考

一、JSON 结构与配置边界

区分客户端数据与内核配置

v2rayN 保存的订阅分组、界面选项和服务器记录，属于客户端数据。启动连接时，客户端根据当前服务器、路由预设和参数设置生成内核配置。内核读取的是后一份文件，不是界面数据库。直接修改运行目录中的临时配置，可能在切换服务器或重启后被覆盖，因此先判断要改的是界面选项、路由模板，还是独立的自定义配置。

v2rayNG 同样承担导入、选择服务器和启动内核的工作；v2flyNG 则是使用 V2Fly 内核的安卓备选。三者不能因为菜单名称相似，就假定导出的配置完全相同。查阅日志时记录实际启动的内核名称；查阅配置时确认文件来自本次启动，而不是上一次导出的副本。配置路径随平台和客户端设置变化，不要照搬其他机器的固定目录。

顶层对象如何分工

传统 JSON 的最外层是对象。inbounds 和 outbounds 是数组，分别容纳一个或多个入口、出口；routing、dns、policy 通常是对象。字段必须位于对应层级，不能把某个出站的 settings 放到顶层。花括号表示对象，方括号表示列表，键名和字符串使用英文双引号，数字与布尔值不加引号。

用于定位本地问题的完整基线

下面配置只接受本机 SOCKS 流量，并通过本机网络直接访问目标。它不连接任何远端代理，也不自动设置系统代理，适合先验证内核能否启动、本地端口能否接收请求。保存为独立文件时使用 UTF-8 编码；不要把说明文字、代码围栏或行号写入文件。若客户端已占用相同端口，应先停掉原来的内核进程。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

这份基线故意没有加入路由和远端服务器，避免多个变量同时变化。请求成功说明本地监听与直连链路基本成立，并不证明订阅服务器可用。后续增加出站时，应把需要作为默认出口的项目放到首位，再逐步添加规则。每一步保留上一份可工作的文件，出现错误就回退本次改动，而不是继续叠加更多设置。

标准 JSON 不允许尾随逗号和注释；部分内核输入方式可能接受扩展语法，但跨工具迁移时不应依赖它。重复键也要清除，不同解析器处理重复键的结果可能不同。编辑器的语法检查只能发现括号、引号之类的格式问题，不能判断协议字段是否受当前内核支持，更不能判断服务器地址是否真实可达。

二、inbounds：本地监听与流量入口

监听地址与端口分别控制什么

入站决定应用怎样把流量交给内核。listen 是绑定的本地地址，port 是等待连接的本地端口，protocol 指定入口使用的协议。监听 127.0.0.1 只供本机程序使用；监听 0.0.0.0 则绑定所有 IPv4 接口，可能被局域网设备访问。地址扩大以后，还要考虑防火墙、认证和所在网络的可信程度。

本地监听端口与服务器端口没有对应相等的要求。浏览器连接本地端口，内核再连接远端服务器端口，两段连接各自独立。端口被占用时，启动日志通常会给出绑定失败的信息；应先找出占用进程，再决定关闭旧进程或更换端口。只改命令中的端口，不改客户端监听设置，结果仍然是连接被拒绝。

SOCKS 与 HTTP 入站的选择

SOCKS 入站适合支持 SOCKS 代理的应用，HTTP 入站适合填写 HTTP 代理地址的程序。二者不是同一个协议，不能只因为端口能连通就混用。下面片段将它们分开监听，标签也保持不同，便于在路由和日志中辨认来源。这是独立双端口示例，不表示客户端当前生成的配置一定采用这种布局。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      }
    },
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

使用这段配置测试 HTTP 入站，应填写 http://127.0.0.1:10809；测试 SOCKS 入站，则使用对应的 SOCKS 地址。某些客户端会生成混合入口，使同一个端口识别多种代理请求，但这种能力取决于所用内核和具体生成方式。排错时先看实际配置，不要根据教程截图推断端口协议。

UDP 与流量探测的边界

SOCKS 的 udp 打开后，只是允许该入口处理符合协议的 UDP 转发请求。应用本身还需要支持 SOCKS UDP，后续出站和远端链路也要支持对应能力。它不会把系统中所有 UDP 数据自动收进来。浏览器的普通 HTTP 代理请求与某些应用的 UDP 通信也可能走不同路径，需要分开验证。

sniffing 尝试从已进入内核的流量中识别目标信息，例如 HTTP 主机名或 TLS 握手中的域名，用来辅助路由判断。它不是解密功能，也不能保证每个请求都有可识别的域名。某些加密握手、纯 IP 服务或非标准协议可能无法提供这些线索，因此不能用“开启探测”替代正确的 DNS 和路由设计。

destOverride 涉及用探测结果处理目标地址，不仅是给日志增加一个名称。若原目标是特定 IP，而探测得到域名，后续解析和连接目标可能受到影响。遇到某个站点只有开启探测时才异常，应对同一请求做开关对照，并检查是否命中了不同规则。不要同时更改探测、DNS 和服务器，避免失去判断依据。

局域网共享与系统接管不是一回事

给手机或电视共享电脑代理时，设备应填写电脑的局域网地址，不能填写电脑视角的回环地址。还需允许相应入站连接，并限制来源网段；在公共网络中不应暴露未经认证的入口。具体图形操作可参考允许局域网连接的设置方法，修改后从另一台设备测试，而不是只在电脑本机测试。

普通 SOCKS、HTTP 入站需要应用主动使用代理。系统代理开关只是向支持它的程序发布代理设置，TUN 则涉及虚拟网络接口、路由和权限，不能靠新增一个普通入站获得相同效果。若浏览器可用而终端不走代理，先检查程序是否读取系统设置或环境变量；若完全没有入站日志，优先查流量入口，不要先调整远端协议。

三、outbounds：出口、标签与远端连接

出口对象与默认出口

出站描述内核接到请求后，使用哪种方式连接目标。每个对象的 protocol 决定 settings 内允许哪些字段；相同名称的设置不能在不同协议间机械复制。tag 是本地识别标签，供路由引用，不会自动发送给服务器，也不是订阅中的显示名称。建议用短而稳定的标签，把界面备注和配置引用分开管理。

没有规则命中时，传统配置通常使用出站数组的第一项。因此，交换数组顺序可能改变大量未明确匹配的流量。将代理出站放在首位，再配置私有地址直连，与将直连放在首位、只挑部分域名代理，是两种不同的默认行为。迁移配置时应先写清楚希望采用哪一种，再核对规则，不能只看标签是否齐全。

直连与阻断是两个基础出口

freedom 使用本机网络连接目标；它不意味着不需要解析域名，也不保证目标可达。blackhole 用来拒绝选中的流量；如果误放在首位，未匹配请求也可能被拒绝。下面片段适合作为路由的基础配套，两个标签分别提供直连和阻断动作，本身并不包含远端代理连接。

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

路由中的 outboundTag 必须与这里的标签逐字一致，大小写和连字符也算在内。修改标签时要同步查找所有引用位置。多个出站使用相同标签会让阅读和定位变得不可靠，不应把标签当成可重复的分类名称。某些缺失引用在配置加载时就会报错，另一些组合可能到请求处理时才暴露问题。

用本地上游理解出站结构

下面出站将请求交给本机另一个 SOCKS 服务。它不需要远端账号，便于说明服务器列表的嵌套关系；只有当 127.0.0.1:2080 确实有另一个服务监听时才会成功。不要把这个上游端口指回当前内核自己的入站，否则可能形成流量回环。需要独立测试时，先确认上游服务本身可用。

{
  "outbounds": [
    {
      "tag": "upstream",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 2080
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

VMess、VLESS、Trojan 和 Shadowsocks 的认证结构不同。服务器地址、端口、用户标识或密码、加密方式都应来自服务端提供的配置，不能靠更换 protocol 名称完成转换。协议参数之外还可能存在传输和 TLS 条件。客户端导入成功仅说明链接能被解析，不代表远端认证与传输一定匹配。

连接失败应该分到哪一层

远端地址是域名时，建立代理连接之前通常就需要先解析这个地址。若把这次解析强制依赖尚未建立的代理，会出现循环依赖。连接日志中的解析失败、连接超时、连接被拒绝、认证失败、TLS 握手失败分别指向不同阶段；先按错误发生的阶段排查，比连续修改多个出口参数更有效。

需要多级转发时，应确认当前内核的出站串联字段及适用范围，不要把另一内核的示例直接合入。上游本地监听、中间出口和最终出口各有自己的失败点，链路越长，越需要逐跳验证。普通订阅使用者优先保留客户端生成的单出口配置，只有明确知道额外一跳解决什么问题时再增加复杂度。

更新订阅可能替换服务器记录，但不一定替换自定义配置中的旧地址、认证参数或标签。发现界面显示已更新而连接仍使用旧数据时，检查当前选中的配置类型和启动日志。涉及分享配置时，删除认证信息、订阅地址和可关联个人账户的字段；保留层级、协议名称与错误阶段，通常已经足够讨论结构问题。

四、routing：规则顺序与出口选择

先匹配，后选择出口

路由不是服务器列表，而是对已经进入内核的请求进行判断。规则通常按数组顺序检查，命中后选择相应出口，不再继续寻找后面看起来更具体的规则。因此，一条范围很大的规则放在开头，可能遮住后面的精细规则。阅读配置时应从第一条往下模拟，而不是按域名规则、IP 规则分别看完再猜结果。

同一条规则内，不同类别条件通常需要同时满足；同一类别中的多个值则表示可选匹配。例如同时填写 inboundTag 与 domain，含义是指定入站且目标域名符合条件，不是二者任选其一。想表达两种独立情况时，应拆成两条规则。标签条件特别适合区分浏览器入口与其他应用入口。

一个可阅读的规则片段

以下片段需要第三章中的 direct 和 block 出站。它依次处理示例阻断域名、私有地址和文档示例域名。geoip:private 需要运行环境提供相应数据资源；如果日志提示数据文件缺失，应解决资源路径问题，或者根据实际网络改用明确的 CIDR 列表，不要忽略启动错误。

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

full: 用于完整域名匹配；domain: 用于该域名及其子域名。二者都不应填写网页路径、查询参数或协议前缀。要匹配某个网站的请求，不能把整段网页地址放进域名数组。正则表达式适合确有模式需求的场景，但更难审查，能用明确域名表达时就不必引入复杂正则。

域名策略不等于 DNS 总开关

AsIs 表示路由阶段尽量沿用已有目标信息，不为了 IP 规则主动解析域名。IPIfNonMatch 会在域名匹配未得到结果时，尝试解析并继续 IP 判断；IPOnDemand 则在遇到需要 IP 判断的规则时触发解析。具体过程还受请求本来携带的是域名还是 IP 影响，不能只看策略名称。

若应用已经把域名解析成 IP，再以 IP 连接本地代理，内核可能没有原始域名可供匹配。流量探测有时能补充线索，但并非对所有协议有效。排查“域名规则没有命中”时，先确认入口拿到的目标形式，再确认探测结果，最后才检查域名列表；否则很容易把信息缺失误判成规则语法错误。

端口、网络类型与私有地址

port 匹配的是目标服务端口，不是本地代理监听端口；network 可用于区分 TCP 和 UDP。把网页端口全部设为代理，并不等于把某个浏览器的全部行为设为代理，因为 DNS、实时通信或其他协议可能使用不同目标端口。按进程选择出口的能力也不能从普通字段路由自动推导出来。

私有地址规则常用于保留路由器管理页、局域网服务和本地资源的直连路径。不过，某个域名解析成私有地址时，能否命中 IP 规则取决于路由是否获得解析结果。使用合成地址方案时，还要按该方案的内核要求处理映射和接管，不可把合成地址简单归入普通私网直连，导致请求绕过正确的还原流程。

验证规则时选择一个明确目标，临时启用能观察出口标签的日志，发起一次请求，然后核对入口、目标与出口。请求重试可能产生多条记录，浏览器后台连接也会干扰判断，命令行单请求更适合定位。关于连接测试可接着阅读首次连接与代理生效检测，不要用单纯的页面打开速度推断路由。

五、dns：解析来源与循环依赖

先区分三处解析

配置 DNS 前，先区分应用自行解析、内核内置解析和远端服务器解析。应用可能先从系统拿到 IP，再把 IP 交给代理；也可能把域名交给 SOCKS，由后续链路处理。内核中的 dns 对象只影响使用内置解析器的路径，并不自动替换系统解析器，更不会自动改变浏览器单独设置的加密 DNS。

服务器自身的域名也需要解析，它与最终访问的网站域名不是同一个任务。前者属于建立代理链路的前置条件，后者可能根据协议和出站行为留给远端处理。判断 DNS 问题时应把这两个域名单独记录。若服务器地址无法解析，访问任何网站都可能失败，不能据此认定所有目标站点的解析都出了问题。

基础字段与条件解析

servers 可以包含简单服务器地址，也可以包含带匹配条件的对象；hosts 用于在内置解析器中设置明确映射。下面示例展示固定映射与域名条件服务器的层级。它不是推荐所有网络统一使用的方案，实际服务器可达性、网络策略和隐私需求仍要自行评估，不能把公共解析地址视为任何环境下都可用。

{
  "dns": {
    "hosts": {
      "lab.example.com": "192.168.50.10"
    },
    "servers": [
      {
        "address": "1.1.1.1",
        "port": 53,
        "domains": ["domain:example.com"]
      },
      "8.8.8.8"
    ]
  }
}

示例中的局域网地址用于说明静态映射，只有本地确实存在对应服务时才有意义。内核的 hosts 也不等同于操作系统的 hosts 文件：如果请求从未经过内置解析器，这项映射可能完全不会参与。对域名做固定映射后，还需考虑服务地址变化、多个地域入口和证书名称，固定 IP 不是长期替代正常解析的通用方法。

查询如何发出与如何兜底

DNS 服务器条目中的域名条件用于选择解析服务器，不是给业务流量选择代理出口。业务路由仍由 routing 处理。条件服务器失败后是否使用其他服务器、是否并发查询、是否接受返回地址，需要结合当前内核的相关字段判断。不同内核的兜底参数不能互相套用，修改前应确认字段名称和实际语义。

内置 DNS 发出的查询也有网络路径。某些形式走内核路由，某些带本地语义的解析形式则采用本地网络栈，不能只凭“使用了加密 DNS”判断查询经过哪个出口。使用域名形式的解析服务地址时，还需要解决解析服务自身域名的引导问题；若引导再次依赖同一服务，就可能形成循环。

典型循环是：建立代理需要解析服务器域名，解析请求又被指定必须通过这个尚未建立的代理。解决时先画出依赖顺序，为建立链路所需的地址保留可工作的引导解析路径，再处理业务域名。直接把所有 DNS 请求统一送往同一代理出口，表面上规则简单，实际可能让启动阶段完全无法完成。

IPv4、IPv6 与缓存

能拿到 AAAA 记录，不表示当前网络具备稳定的 IPv6 路径；只能连 IPv4，也不代表域名没有 IPv6 服务。修改查询策略会影响返回地址族，但不会修复路由器、运营网络或远端监听缺失的问题。遇到一部分目标超时，应分别观察解析结果与连接地址，再决定是否需要临时限制地址族做对照测试。

DNS 缓存可能存在于浏览器、操作系统、客户端和远端多个位置。修改配置后，同一个域名仍显示旧行为，不一定代表新设置未生效。先重启实际负责解析的组件，或换一个明确的测试域名，再观察日志。不要为了清理缓存同时删除客户端全部数据，那会引入订阅、路由和服务器选择等新的变量。

对照命令时，socks5:// 与 socks5h:// 在 curl 中的域名处理方式不同，后者把目标域名交给 SOCKS 代理侧处理。这个差异适合判断本地解析是否参与，但成功结果仍只说明该请求路径可用。若需要继续定位更新订阅时的解析错误，可查看订阅更新失败排查，因为订阅下载未必使用当前代理链路。

六、policy：超时、用户等级与统计

策略控制行为，不选择出口

policy 用来设置连接处理策略，例如握手等待时间、空闲超时和统计开关。它不是路由规则，也不负责决定某个域名走直连还是代理。出现连接失败时，先找出失败阶段；只有日志显示确实与等待、空闲断开有关，才有理由调整策略。把所有超时都调大，常常只是让错误出现得更晚。

levels 中的键是用户等级，写在 JSON 中时使用字符串形式。等级不是速度档位，也不是订阅套餐等级，而是协议用户配置引用的一组策略索引。是否存在可引用的用户等级，取决于相应入站和协议。未配置专用等级时应理解默认行为，不要认为新增一个等级对象就会自动应用到全部流量。

连接时间字段的含义

下面片段展示等级零和系统统计开关的结构。时间字段单位为秒，数值用于说明完整写法，不是面向所有网络的优化建议。需要保留当前内核默认值时，可以不显式填写相应字段；需要改动时，先记录原始行为，再以单项变化做对照，尤其要保留长连接应用的测试结果。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5,
        "statsUserUplink": false,
        "statsUserDownlink": false
      }
    },
    "system": {
      "statsInboundUplink": true,
      "statsInboundDownlink": true
    }
  },
  "stats": {}
}

handshake 对应受该策略控制的协议握手等待，不能泛化成所有远端拨号、TLS 协商和网页响应的统一超时。connIdle 处理连接在没有有效数据活动时的空闲期限。实时通信、远程会话和消息推送可能长时间没有业务数据，期限设得过短会增加重连；期限过长则可能让失效连接占用资源更久。

uplinkOnly 与 downlinkOnly 涉及连接一侧结束后，另一侧仍可继续传输的等待阶段，并不是上传限速和下载限速。数值较小可能更快清理连接，也可能截断仍有数据要发送的半关闭会话。下载大文件、流式响应或长时间保持的请求时，应特别留意这类收尾行为，而不是只测试一个短网页。

统计开关与展示界面的关系

启用统计通常需要 stats 对象与对应统计策略共同配合。系统级统计面向入站等对象，用户级统计则要求协议用户具有可识别的配置。打开用户统计开关，并不意味着所有匿名 SOCKS 请求都会自动获得独立用户报表。统计名称和读取方式还受内核的服务接口及客户端实现影响。

配置中允许累计统计，不代表图形界面一定会展示这些数值。读取统计的程序需要合适的接口和调用方式；接口监听位置也要限制在可信范围。普通使用场景中优先采用 v2rayN 自己的统计实现，不必为了让界面出现某个数字而额外暴露控制接口。统计中没有记录时，也应先确认流量有没有经过对应对象。

日志等级与资源使用

日常运行可保留 warning 等较克制的日志等级。排查时临时使用更详细等级，复现一次后立即恢复，避免日志持续增长。访问日志与错误日志用途不同：前者帮助判断请求走向，后者帮助判断连接在哪个阶段失败。文件路径必须可写；路径错误可能导致日志缺失，不能直接据此判断没有请求。

若启用文件日志，桌面客户端以普通用户运行时，不应将日志输出指向只有管理员能写入的系统目录。磁盘写满、目录只读或安全策略限制，都可能影响观察结果。排查客户端打开即退出的问题，应先看进程启动与目录权限，再看连接策略，相关步骤见v2rayN 启动闪退排查。

策略字段不负责操作系统级的进程优先级、全局带宽限制或电源管理。安卓后台限制、Linux 休眠恢复、网络接口切换都可能使旧连接失效，这些现象不能单靠延长空闲时间解决。遇到待机后无法恢复，先对照前后台状态和网络变化，再分别检查客户端后台运行条件、系统代理恢复情况和内核日志。

七、协议、传输与内核兼容

把一条连接拆成三层

描述服务器时，应分清代理协议、承载传输和安全层。VMess、VLESS、Trojan、Shadowsocks 处理代理数据与认证；TCP、WebSocket 等描述如何承载连接；TLS 或其他安全机制处理相应的连接保护。三层参数必须与服务端一致，不能因为域名和端口正确，就忽略传输类型、路径或证书名称。

配置中的 settings 属于代理协议，streamSettings 属于连接传输。把 WebSocket 的路径放进协议用户对象，通常不会获得想要的效果；把认证字段放进传输对象，也不能完成协议认证。先检查字段所在层级，再检查字段值，比反复导入同一条错误链接更有效。

读取 WebSocket 与 TLS 片段

以下只是某个兼容出站对象内部的传输片段，不能单独运行；需要与真实服务端的协议配置合并。示例域名与路径用于说明字段位置，不是可连接的服务器。若客户端生成的字段名称与此不同，应以实际选定内核支持的结构为准，尤其不要把不同代际传输的名称当成别名随意替换。

{
  "streamSettings": {
    "network": "ws",
    "security": "tls",
    "tlsSettings": {
      "serverName": "edge.example.com",
      "allowInsecure": false
    },
    "wsSettings": {
      "path": "/proxy",
      "headers": {
        "Host": "edge.example.com"
      }
    }
  }
}

出站服务器地址决定最初连接到哪里；TLS 的 serverName 参与服务器名称指示和证书验证；WebSocket 的 Host 则是 HTTP 升级请求中的主机信息。它们有时相同，有时在合法的反向代理部署中不同，但不能凭猜测填写。连接到了正确 IP，仍可能因名称不符被前置服务拒绝。

WebSocket 路径需要与服务端路由匹配，开头斜杠、大小写、末尾斜杠和查询部分都可能影响处理。出现非预期的 HTTP 响应时，应检查反向代理是否把请求交到了正确后端。直接在浏览器打开域名首页成功，只能证明网站入口可访问，不能证明对应的升级路径和代理协议后端正常。

证书错误不应靠关闭验证掩盖

allowInsecure 保持关闭。证书错误应分别检查系统时间、证书有效期、名称是否匹配、证书链是否完整，以及系统信任库是否正常。若企业网络使用经过授权的内部证书体系，应按照组织规则管理信任，而不是把所有连接都改成跳过验证。关闭验证会削弱对错误服务器的识别能力，也会掩盖真实配置问题。

TLS 握手失败还可能来自安全层不一致：客户端发起 TLS，而服务端对应端口只接受普通 TCP，或反过来。某些错误发生在认证之前，因此更换用户标识不会解决问题。先确定端口上的实际服务，再检查安全层，再检查传输升级，最后检查代理认证，顺序清楚才能减少无效试错。

V2Fly、Xray 与客户端的分工

Project V 提供了相关模块化代理设计的背景，V2Fly 与 Xray 属于不同内核家族。二者在基础 JSON 结构上有交集，但新协议能力、安全层字段和部分路由行为会分化。REALITY 属于需要核对内核支持的能力，不能把相关设置直接加入任意 V2Ray 配置。具体参数应来自与服务端匹配的配置来源。

桌面使用 v2rayN 时，先确认当前配置实际调用哪个内核；安卓使用 v2rayNG 时注意其 Xray 配置能力，使用 v2flyNG 时按 V2Fly 能力检查。客户端名称不等于某一个固定字段集合，也不能用外观相似证明兼容。选择方面可参考三款客户端与内核对比，再决定是否迁移。

迁移配置应按协议、认证、安全层、传输、路由和 DNS 逐层核对，先保留一个可工作的服务器，再搬迁附加规则。遇到不认识的字段，不要直接删除后继续使用，因为它可能是连接成立的必要条件。配置能被加载与配置表达了原本意图是两回事，最终仍需用明确请求和日志验证实际行为。

八、配置合并、验证与分层排错

把修改落实到真正的配置来源

修改之前，先导出或备份客户端现有数据，另存当前可工作的自定义配置。普通服务器记录优先通过 v2rayN 界面编辑；路由预设在路由管理位置修改；完整自定义配置则单独维护。不要一边编辑客户端生成的临时文件，一边在界面切换服务器，那样很难判断最后运行的是哪一份内容。

合并本文片段时先建立字段清单：顶层对象只保留一份同名键；入站端口不能与现有监听冲突；出站标签保持唯一；规则引用能够找到对应标签；需要的数据资源确实存在。示例里的私有地址和文档域名也要按目的处理，不需要的规则直接移除，不能让教学场景变成长期遗留设置。

先测入口，再测出口

恢复第一章的完整基线并启动后，可以执行下面的 SOCKS 测试。它要求本机 10808 正在接受 SOCKS 请求。这里的目标是公开文档示例域名，不依赖私人服务器信息。若该站点在当前网络不可用，可以换成已知可访问的 HTTPS 地址，但应在整个对照过程中保持目标不变。

curl -I --connect-timeout 10 --max-time 20 \
  --proxy socks5h://127.0.0.1:10808 \
  https://example.com

如果使用第二章的双入站配置，可以再单独测试 HTTP 入口。只有确实启用了该端口，下面命令才有意义。服务器可能返回成功、重定向或其他有效 HTTP 状态；收到响应说明这次请求到达了 HTTP 服务，但不自动证明经过远端代理。基线本来就是直连出口，不能把它的结果当作服务器连通证明。

curl -I --connect-timeout 10 --max-time 20 \
  --proxy http://127.0.0.1:10809 \
  https://example.com

显式填写代理地址比只依赖系统代理更适合排错，因为它减少了环境变量、桌面设置和应用兼容性的影响。需要验证系统代理时，再使用实际应用发起请求并检查入口日志。命令可用而浏览器不可用，问题可能在浏览器配置；浏览器可用而某个程序不可用，问题可能在该程序的代理支持或 DNS 行为。

按错误阶段缩小范围

若启动成功但没有任何请求记录，应先确认应用是否进入代理，不要立即怀疑远端服务器。若有请求记录但出口不是预期标签，应检查规则顺序与默认出站。若出口正确而连接失败，再检查服务器域名解析、网络连接、TLS 和认证。每次只沿着已经得到证据的一层继续往下查。

不要把 ping 的结果当作代理协议测试。目标可以拒绝 ICMP，但仍接受正常业务连接；也可以回应 ICMP，却没有开启指定端口。类似地，端口能建立 TCP 连接只说明有服务接收连接，不说明它使用预期协议。需要将入口测试、端口可达、协议握手和实际请求分别记录，避免用一个结果替代整条链路。

恢复与复查

一次变更验证成功后，重新启动客户端并重复同一个测试，确认设置没有被重新生成的配置覆盖。再验证局域网资源、需要代理的目标和长连接应用，确保没有只修好一条路径却破坏另一条。网络切换或休眠恢复后的行为也值得单独检查，特别是启用了系统代理或 TUN 的桌面环境。

提交问题时保留内核名称、操作系统、错误阶段和删去敏感信息的相关片段。不要公开订阅链接、完整认证数据或含账户参数的日志。若修改后无法定位，先恢复备份，再按本章顺序重做最小测试；常见现象可继续查常见问题，需要重新梳理导入与连接步骤则返回使用指南，不要靠反复重装替代配置定位。