V2Ray 配置文件参考

JSON 结构总览

配置文件描述的是内核如何处理连接，不是客户端窗口中所有选项的备份。理解它时，先沿数据路径阅读：应用把连接交给入站，路由根据目标和来源选择出站，出站再直接访问目标或连接远端服务。DNS 为需要解析的环节提供结果，策略则管理连接时限与统计。对象之间通过标签、用户等级等值关联，单独看某一段，往往无法解释完整行为。

先区分客户端文件与运行配置

v2rayN 保存的订阅分组、界面偏好、更新设置，不一定属于内核 JSON。客户端通常根据当前服务器、路由模板和参数设置生成运行配置，重新连接时可能再次生成。直接修改生成文件，下一次切换服务器后可能被覆盖。因此，应先找出设置的来源：普通端口和路由选项优先在界面修改，确实需要完整自定义配置时，再使用客户端提供的相应导入或自定义入口。

本页以常见的 V2Ray 对象式 JSON 为阅读基线，不把不同内核的扩展字段混为同一标准。v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核；v2rayN 的实际能力取决于当前选用的内核。相同的字段名可能具有不同的可选值，某些新传输也不适用于另一内核。遇到未知字段时，先确认运行内核与配置格式，而不是逐个删除报错位置附近的内容。

一个能启动的本地直连基线

下面的完整配置建立两个仅供本机访问的入口，默认直接连接目标，并预留一个拒绝出站。它用于理解结构和验证本地链路，不包含远端代理服务器，也不会自动改变系统代理。保存为普通 UTF-8 文本后，应通过兼容内核的自定义配置方式运行；若客户端已经使用这些端口，需要先停止原有实例，或同时修改本例与测试应用的端口。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  }
}

JSON 的对象使用花括号，数组使用方括号，键名与字符串必须使用双引号。数字端口不加引号，布尔值写成小写的 true 或 false。本页示例不带注释和末尾逗号，便于交给严格 JSON 解析器。即使某种加载方式允许注释，也不要据此认定所有客户端导入入口都接受同样语法。

空对象与缺少对象不总是等价。某些协议的 settings 可以为空，另一些必须包含服务器或用户列表。字段拼写大小写也需要保持一致，例如 outboundTag 不是随意命名的说明文字。相反，direct、socks-in 是示例自行定义的标签，可以更名，但所有引用处都要同步，且应避免重复标签。

不必把所有可选对象一次填满。完整并不意味着字段越多越好，而是每个已经写入的字段都有明确目的。开始查阅前，可以记录当前入口协议、端口、默认出站与预期分流行为。后续每段配置都围绕这四项核对，能减少从别处复制整份配置后，无法判断哪些规则正在起作用的问题。

inbounds 入站：应用连接入口

inbounds 是入口数组。每个入口至少要明确监听地址、端口与协议，并按协议提供设置。应用只有实际连接到这个入口，内核才有机会处理它的流量。客户端显示正在运行，不等于浏览器、终端和其他应用都已经接入。排查时先问“应用把连接发到了哪里”，再讨论路由是否正确，比直接修改分流规则更有效。

listen、port 与协议要一起核对

listen 为 127.0.0.1 时，只接收本机回环连接；0.0.0.0 表示监听所有 IPv4 接口，范围明显更大。端口是该入口实际占用的本地端口，不是远端服务器端口。本页采用 SOCKS 10808、HTTP 10809 分开监听的示例；客户端也可能使用混合入口或其他端口，实际配置应以当前运行设置为准，不能仅凭常见数字判断协议。

HTTP 代理设置应指向 HTTP 入口，SOCKS 设置应指向 SOCKS 入口。把浏览器的 HTTP 代理指到纯 SOCKS 端口，通常无法建立正确会话。HTTPS 网站也可以通过 HTTP 代理的 CONNECT 隧道访问，这不要求把本地代理地址改成 HTTPS。应用设置里的“安全代理”名称有时描述目标流量类型，而不是本地入口本身启用了 TLS。

UDP 与流量嗅探的边界

SOCKS 入口中的 udp: true 允许相应的 UDP 转发能力，但它不是全局 UDP 开关。应用必须使用兼容的 SOCKS UDP 方式，远端协议、服务端和网络路径也要支持。只有 TCP 请求正常，并不能证明 UDP 已经通过。传统 HTTP 代理入口也不能简单视作任意 UDP 应用的替代入口，游戏或实时通信程序需要单独核对接入方式。

sniffing 可以从部分应用层握手信息中识别目标域名，辅助原本只有 IP 的连接参与域名路由。它不是解密工具，也不能保证从所有加密流量中获得域名。下面的配置把识别结果仅用于路由判断；routeOnly 是否可用，应按实际内核确认。若不支持该字段，不应直接删除它并假设行为完全相同，而应重新确认是否允许改写目标。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"],
    "routeOnly": true
  }
}

这段内容应合并到某一个入站对象中，与 protocol 同级，不是放进该协议的 settings。配置树位置错误时，有的加载器会拒绝启动，有的可能忽略未知内容。只看 JSON 能被解析还不够，还需要确认内核接受了结构，并观察对应域名规则是否确实命中。

局域网共享需要额外的访问控制

让另一台设备使用代理时，客户端的“允许来自局域网的连接”往往会改变监听范围，同时还受操作系统防火墙影响。连接地址应填写代理主机的局域网地址，而不是对方设备自己的回环地址。应限制允许访问的来源，必要时配置认证；不能只把监听地址改为所有接口，就把入口暴露给不确定的网络。

Android 上的 v2rayNG 与 v2flyNG 通常还涉及系统 VPN 接口和分应用选择。某个应用是否进入该接口，与 JSON 中有没有 SOCKS 入口不是同一个问题。桌面端系统代理、应用独立代理和安卓分应用规则应分别检查；相关授权与后台运行问题可继续查看安卓 VpnService 与分应用代理说明。

outbounds 出站：协议与默认路径

outbounds 是处理连接的出口列表。出站可以直接连接目标、连接远端代理服务，也可以主动拒绝流量。它的 protocol 描述内核在这个出口使用什么协议，而不是应用最初使用了什么入口。同一个 SOCKS 入站中的连接，可以因路由结果不同，被交给不同出站；入口与出口不是必须一对一对应。

默认出站与标签引用

在常见的对象式配置中，没有路由规则匹配的连接会使用首个出站。因此，数组顺序也是实际行为的一部分。开篇配置把 direct 放在第一项，所以所有未匹配连接默认直连；实际远端代理配置若希望未匹配流量走代理，应明确安排默认出口。不要认为标签叫作 proxy 就自动成为默认路径，标签本身没有这种特殊含义。

tag 是路由引用出站的名称。规则中的 outboundTag 必须准确对应一个已定义标签，包括大小写。建议使用便于识别的短名称，并避免重复。把节点名称、订阅分组名和出站标签混用，容易造成误解：客户端界面的名称可能会被转换，并不保证原样进入运行配置，排查应查看实际生成结果。

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

freedom 表示由本机网络直接访问目标，并不表示跳过内核。连接依然可能受到内核 DNS、出站设置和系统网络状态影响。blackhole 则用于丢弃或拒绝所选流量，常作为明确的阻断结果。拒绝后应用可能表现为立即失败，也可能继续重试并等待超时，这与应用的重试机制有关，不能把页面转圈直接等同于远端连接故障。

远端协议的 settings 不能互换

不同代理协议使用不同的服务器与认证结构。VMess、VLESS 的用户信息不等于 Trojan 的密码字段，Shadowsocks 还要配合双方一致的加密方法。分享链接通常同时包含远端地址、端口、认证和传输信息，导入后应作为整体核对。只替换一个地址，却沿用另一条连接的传输或认证设置，很容易得到语法正确但无法连接的配置。

远端服务器地址回答“连到哪台服务”，请求目标地址回答“最终访问哪里”，两者处在不同层级。本地监听端口、远端服务端口、目标网站端口也应分别记录。比如应用连入本地端口成功，只能证明第一段链路成立；远端端口不可达、认证不一致或 TLS 失败，仍会使最终访问失败。日志中看到的地址，需要先判断属于哪一段。

先验证一个出口，再加入选择逻辑

添加多个出站之前，先用同一条测试请求验证单个出口。保留一个明确的直连对照，能区分目标本身不可达与代理路径异常。完整自定义配置里，客户端的“选择当前服务器”未必会重写你的出站列表，因此切换界面选项后应核对配置来源。不要把客户端的自动选择功能想当然地套到所有自定义文件上。

多路复用、链式连接和负载分配属于进一步的行为控制，不是连接失败时优先开启的补救选项。它们会增加并发、依赖与诊断复杂度。先确定入口、路由、单个远端连接均能工作，再按需求增加。协议概念容易混淆时，可先阅读四类代理协议的差异，再回到对应协议字段核对。

传输与安全：streamSettings 的层级

代理协议与传输方式是两层设置。协议负责会话与认证，传输负责这些数据如何在网络上传递；连接安全再决定是否以及怎样使用 TLS 等机制。相同协议可能搭配不同传输，但只有服务端与当前内核共同支持的组合才能工作。导入分享链接后，应整体检查协议、传输、安全方式三项，而不是只看协议名称相同就认为兼容。

network 与 security 分别描述什么

streamSettings 通常与出站的 settings 同级。其 network 指定底层传输类型，security 指定该层使用的连接安全机制。传输专属对象再提供路径、请求头或服务名称等细节。字段名称与可用值会随内核能力而不同，尤其不能把某个内核的新传输字段直接当作另一内核的通用写法。

下面是一段 TLS 配置结构示例，展示对象位置与证书名称字段。它不是完整的远端出站；示例域名采用保留的文档域名，实际应使用服务端明确要求的名称。不要用这段示例替换订阅中的全部传输配置，也不要据此假定只要启用 TLS，就能与任意远端端口完成握手。

{
  "streamSettings": {
    "network": "tcp",
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.com",
      "allowInsecure": false
    }
  }
}

serverName 用于 TLS 服务名称指示及相关证书名称验证，并不一定等于建立底层连接时填写的服务器地址。底层连接可以指向一个 IP，而证书需要匹配域名。反过来，仅把服务器地址改成域名，也不能保证应用层请求头、传输路径与 TLS 名称都已正确。应分别对照服务端要求，不用一个字段代替所有名称。

路径、请求头与证书检查

使用 WebSocket 时，路径属于传输约定，必须与服务端或前置转发配置一致；斜杠、大小写以及附加参数都可能影响匹配。请求头里的 Host 与 TLS 名称可能相同，也可能在特定部署中不同，但不能根据猜测随意填写。TLS 成功只说明安全连接阶段通过，不代表后续的 WebSocket 升级或代理协议认证也已经成功。

gRPC 的服务名称同样是服务端约定的一部分，不是界面中的备注。传输名称看起来正确，仍可能因为服务名、路径转发或中间网络设备限制而失败。排查时要定位失败发生在 TCP 建连、TLS 握手、传输握手还是协议认证阶段。每一层都依赖前一层，跳过顺序同时修改多项，会让原本可定位的问题变得难以复现。

兼容性以正在运行的内核为准

REALITY、XTLS Vision 等能力不能仅靠复制几个字段获得，客户端界面支持也不等于当前运行内核已经接受这组设置。遇到相关连接，先核对服务提供的信息与实际内核，再核对整组参数。V2Fly 与 Xray 有共同背景，但各自扩展并非完全互换，具体关系可查阅内核差异与配置兼容性。

如果更换内核后出现“未知传输”或“无法解析安全设置”，应先回到已确认兼容的配置，而不是逐个删字段直到能够启动。启动成功只意味着文件被接受，不代表双方使用了同一套连接语义。保留原始连接信息和本地修改记录，能在恢复配置时避免再次猜测，也能把兼容问题与网络问题分开处理。

routing 路由：条件、顺序与标签

路由规则决定一条连接交给哪个出站。常见字段式规则按数组顺序检查，先匹配的规则先决定结果；没有匹配时使用默认出站。规则不能替代入站接入，也不能修复一个本来就无法连接的出口。构建分流前，应先验证默认路径，再添加少量具有明确目的的规则，避免一开始导入大量无法解释的条件。

理解规则内部的匹配关系

同一条规则里不同种类的条件通常需要同时满足，例如来源入口和目标域名都符合才命中；同一种字段的数组则用于列出多个可匹配项。因此，把域名列表与 IP 列表放在同一条规则，不等于表达“域名或者 IP”。需要分别覆盖两类目标时，通常应拆成两条规则，再让它们指向同一个出站标签。

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

这段示例需要已有 direct 和 block 出站，同时需要对应的域名与 IP 数据文件。第一条对文档示例域名进行精确阻断，用于观察规则优先级；后三条表达常见的直连分类。它不是适合所有网络的完整分流方案，未匹配流量仍由首个出站处理。如果默认出站也是直连，后几条不会把其他流量自动变成代理。

域名写法与数据文件

full: 用于精确域名，domain: 用于域名及其子域匹配，regexp: 使用正则表达式，geosite: 引用域名分类。普通字符串的匹配范围可能比直觉更宽，精确需求应明确使用合适前缀。正则中反斜杠还要经过 JSON 字符串转义，排查困难时优先用几条明确的域名条件替代复杂表达式。

geosite:cn 与 geoip:cn 分别引用域名分类和 IP 分类，不是实时地理定位，也不是一对一对应的数据集。数据文件缺失、类别不存在或文件格式不兼容，都可能影响加载。更新客户端或数据后，某些目标的命中结果也可能变化；需要长期固定的业务例外，适合用清楚的自定义域名规则表达。

domainStrategy 不等于 DNS 服务器选择

AsIs 通常保持原目标形态，不为路由匹配主动把域名转成 IP；IPIfNonMatch 会在域名阶段未匹配时尝试解析后再检查；IPOnDemand 会在路由判断需要 IP 时触发解析。具体执行仍受内核实现影响。这些选项回答“路由何时需要 IP”，而 DNS 对象回答“解析请求如何处理”，两者不能混为一项设置。

当应用直接提交 IP，域名规则可能没有可用的域名信息；当目标保留为域名，纯 IP 规则是否生效又受解析策略影响。流量嗅探能在部分情况下补充信息，却不能保证每条连接都有域名。判断规则失效时，应先核对内核收到的是域名还是 IP，再看规则顺序和数据类别，不要直接把所有流量改成同一个出口。

验证分流时，挑选一个精确域名、一个预期直连目标和一个默认路径目标，分别建立新连接。浏览器连接池可能复用旧会话，修改配置后需要重新建立连接再观察日志。系统代理中的绕过列表还可能让请求在进入内核前就直连，这与内核路由是两套机制；更多常见现象可在FAQ 中按连接排障分类查阅。

dns 配置：解析发生在哪里

DNS 配置首先要回答解析发生的位置。浏览器、操作系统、应用自带解析器、内核内置解析器和远端服务都可能参与。写入一个 dns 对象，只是配置内核内置解析器的行为，不代表系统中所有 DNS 请求都会自动被它接管。应用若先解析成 IP 再交给代理，内核最初看到的目标就可能已经没有域名。

servers、hosts 与查询策略

servers 定义解析服务器；列表项可以采用简单地址，也可以采用包含匹配条件的对象。下面展示常见的分域解析结构，选项以支持这些字段的内核为前提。IP 地址是公开解析器示例，不代表任何网络都能访问，也不是固定推荐。应用到真实环境前，应先确认这些解析器在当前网络和预期路径上可用。

{
  "dns": {
    "hosts": {
      "example.com": "192.0.2.10"
    },
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIPv4"
  }
}

hosts 是内核解析器的静态映射，不会修改系统的 hosts 文件。示例中的 192.0.2.10 属于文档保留地址，只用于展示结构，不能据此访问真实服务。静态映射适合明确且稳定的特殊需求；把经常变化的网站长期固定到一个 IP，可能绕过正常调度，并使证书、可达性或服务区域出现不符合预期的结果。

带 domains 的服务器条目为特定域名提供匹配条件，expectIPs 用于检查结果是否符合预期分类，但它不是“只允许这个地区访问”的防火墙。解析器候选、回退与结果接受逻辑还取决于内核和其他选项。不要把服务器数组简单理解为永远严格地从第一项失败才尝试第二项，也不要只凭排列顺序推断所有查询的去向。

解析路径与连接路径需要分别验证

解析请求能否到达 DNS 服务器，与最终网站连接是否走代理是两个问题。某些解析方式可以参与内核路由，某些带有本地语义的模式会直接使用本地路径，细节需按实际实现确认。只添加一个指向代理的域名规则，不一定改变所有解析请求的出口；只更换 DNS 地址，也不会自动修复错误的远端认证或传输参数。

使用基于 HTTPS 的解析服务时，还存在“先解析解析器自身域名”的引导问题。若解析服务器地址本身是域名，而当前解析路径又依赖它，可能形成循环依赖。应理清启动阶段如何找到解析器和代理服务器，保留可达的引导路径，并避免让代理服务器域名的解析依赖尚未建立的同一条代理连接。

IPv4、IPv6 与缓存

UseIPv4 用于限制相应查询策略，不等于关闭整台设备的 IPv6。应用若使用自己的解析器，仍可能取得 IPv6 地址并尝试连接。反过来，能够解析 AAAA 记录也不说明当前网络具备可用的 IPv6 路径。应分别验证解析结果与连接结果，避免用全面关闭某种地址族来代替对具体失败链路的定位。

修改解析设置后，应用缓存、系统缓存和已有连接都可能继续影响观察结果。先建立一条新的请求，再对照日志中的目标形态与路由选择。命令行的系统解析工具通常测到的是系统解析链路，不一定等于内核解析器的行为；需要验证内核 DNS 时，应让测试请求通过实际入口，并结合运行日志判断，不能只看一次系统查询就宣布配置生效。

policy 策略：连接时限与统计

policy 主要管理用户等级对应的连接行为和系统级统计选项。这里的“策略”不是域名分流规则，也不是系统代理模式。路由决定连接交给哪个出口，策略决定相关连接可以等待多久、何时结束以及是否记录部分统计。把这两个对象分开理解，能够避免用缩短超时去解决路由选错等不相关问题。

levels 与用户等级的关系

levels 的键是等级编号字符串，例如 "0"。支持用户等级的协议对象可以通过其用户配置引用等级；没有显式指定时，通常会涉及默认等级，具体取决于协议与内核。等级不是优先级排名，也不会让某个用户的网络连接自动更快。配置前应确认被管理的用户对象确实使用这个等级，否则修改可能没有作用。

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

这是一组用于解释字段的示例值，不是所有场景的推荐参数。handshake 控制相关握手阶段允许的时间，connIdle 控制空闲连接时限，uplinkOnly 与 downlinkOnly 则涉及连接一侧结束后另一侧继续工作的等待时限。常见实现以秒为单位，但这些时限作用于内核连接流程，并不等同于浏览器显示的页面加载计时。

把时限设得过短，可能使高时延网络上的握手尚未完成就被中止，也可能影响长轮询、消息推送或短时间没有业务数据的连接。设得过长则可能保留更多空闲资源。出现偶发断开时，先确认究竟是超时、远端关闭还是应用主动结束，不能看到断线就同时增大所有数值。过度调整会掩盖链路质量问题，并增加复现难度。

统计开关不是完整监控接口

用户流量统计、入站统计和出站统计的对象不同。开启某个开关，不代表客户端一定展示相应数字；统计模块、查询接口以及客户端自身的采样方式也需要配合。用户统计还可能要求可识别的用户信息。不要把这些计数与网卡流量直接等同，协议开销、重传和其他进程流量可能使它们在口径上不同。

如果完整配置需要统计，通常还要按内核要求配置统计对象及查询能力。API 入口属于管理面，应该限制在本机或受控网络，不应为了读取流量而直接暴露到不可信接口。本页不提供开放管理端口的拼接示例；使用图形客户端时，优先使用客户端已有的统计功能，避免重复开启相互冲突的管理入口。

策略、日志与并发要分开调整

日志等级由 log 对象控制，不是 policy 的统计开关。策略统计关注字节计数，日志关注运行事件，二者不能互相替代。多路复用也有独立的配置位置，并不因为启用用户统计就自动开启。排查资源占用时，应分别观察连接数量、业务并发、日志输出和统计需求，再决定具体修改哪一项。

桌面与移动设备对后台连接的限制还可能来自操作系统。Android 的电池优化可能暂停客户端，网络切换也可能使现有连接失效，这些问题无法单靠增大 connIdle 解决。先确认进程仍在运行、系统网络接口仍有效，再检查内核策略。否则会把系统层面的中断误判成配置中的空闲超时。

评估修改是否有效，需要在同样的网络、同样的应用和相近的使用过程下复测。短请求正常，不代表长连接正常；长时间保持连接，也不代表资源利用合理。记录具体失败阶段和日志比反复套用所谓通用优化参数更有帮助。对没有明确需求的选项保持克制，通常更利于维护和后续升级兼容。

验证与排错：从文件到实际请求

配置验证分成四层：文本能否解析、内核能否加载、应用是否接入、最终路径是否符合预期。前一层通过不能替代后一层。一个合法 JSON 可能引用不存在的出站，一个已经启动的内核可能没有收到应用连接，一次成功访问也可能只是系统绕过代理后的直连。每层都留下可观察的证据，才能判断修改真正影响了哪里。

先排语法和加载错误

先检查双引号、逗号、括号配对和字段类型。复制代码时不要把解释文字或代码围栏一同放入文件。JSON 能解析后，再看内核启动日志是否提示未知协议、缺少数据文件、无效标签或端口占用。报错给出的行列通常指向解析停止位置，真正缺失的逗号可能在上一行，因此应连同前后对象边界一起检查。

确认运行的是刚刚修改的文件，而不是客户端重新生成的另一份配置。图形客户端通常能查看日志或相关运行信息，具体入口名称可能随界面变化。排查时不必一开始就更换客户端；先保留原文件副本，关闭冲突实例，重新启动一次，并记录首次出现的错误。后续重复错误可能只是同一根因引发的连续重试。

用明确的入口发起测试

下面两条命令针对开篇分开的 SOCKS 与 HTTP 入口。SOCKS 地址中的 socks5h 表示把域名交给代理侧处理，适合与本地解析路径作区分。Windows 命令环境中可显式使用 curl.exe；其他系统使用可用的 curl 命令。测试访问的是文档示例站点，不是测速，也不能据此判断所有应用都已走代理。

curl --noproxy "" --proxy socks5h://127.0.0.1:10808 --head https://example.com/
curl --noproxy "" --proxy http://127.0.0.1:10809 --head https://example.com/

显式设置空的绕过列表，是为了减少现有代理环境变量对测试的干扰。若本地端口立即拒绝连接，先查进程、监听地址和端口；若本地接入成功但远端超时，再查出站和网络。对照开篇直连基线时，成功只证明“应用到内核再到目标”的基础链路成立，不证明已经存在可用的远端代理服务。

按日志里的阶段定位字段

warning 适合一般运行，定位细节不足时可短时提高日志详细程度。修改后重新发起一条容易识别的请求，记录时间、目标、入口和选中的出口，再恢复日常日志等级。详细日志可能包含域名、地址和连接信息，分享前应移除订阅地址、认证内容及其他敏感数据，不要直接发送整份运行文件。

“超时”只是结果，不是唯一原因。目标不可达、解析失败、错误出口或远端握手停滞都可能表现相似。应先确定失败位置，再选择检查字段。对典型日志的进一步解释，可查看运行日志与常见报错；如果只有终端不生效，查看系统代理与终端路径排查，不要先改动整套路由。

形成可恢复的修改记录

每次修改保留三项信息：改了哪个对象、预期改变什么、用哪条请求验证。更新订阅或切换服务器后，再确认客户端是否保留了自定义设置。需要回退时，恢复最近可运行的配置而不是继续叠加补丁。若仍无法确定问题所在，按教程主线重新验证导入、模式和连接，再按本页的对象顺序逐层加回定制内容。