V2Ray 配置文件参考

JSON 结构总览

配置对象与连接路径

V2Ray 配置文件的顶层是一个 JSON 对象。入站负责接收应用连接，出站负责发送连接，路由负责在两者之间选择去向，DNS 负责配置范围内的域名解析，策略负责部分连接限制与统计开关。这几个模块不是按文件位置依次执行的脚本，而是由内核读取后建立的运行结构。理解配置时应追踪一条请求经过哪个入站、匹配哪条规则、最终交给哪个出站，而不是只检查某个字段有没有出现。

图形客户端和内核也需要分开理解。v2rayN、v2rayNG 与 v2flyNG 提供节点编辑、订阅管理和代理开关；实际建立连接的是背后的内核。客户端界面的一个选项可能生成多个 JSON 字段，也可能只修改操作系统设置。系统代理开关通常属于后者，不能因为配置里存在 HTTP 入站就认为浏览器已经使用它。下面先用本地 SOCKS 入站和直连出站建立一份结构完整的基线，便于确认基础链路。

{
  "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": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  }
}

类型、数组与标签引用

JSON 对字段类型有明确区分。端口在此示例中是数字，开关使用布尔值，标签与地址使用字符串，多个入站和出站放在数组里。字符串必须使用双引号，末尾元素不能保留多余逗号，标准 JSON 也不接受注释。编辑器能打开文件不代表内核能解析文件；语法错误和字段含义错误是两个层次。先确认括号、引号与类型，再检查协议是否支持对应设置，能避免把简单语法问题误判成网络故障。

标签是模块之间的连接依据。路由里的出站标签必须与出站对象的标签完全一致，大小写不同也可能导致引用失败。标签最好使用简短、明确且唯一的名称，例如直连、阻断与远端代理分别采用不同标识。不要仅凭数组里的显示顺序判断标签含义；通常未匹配路由的连接使用第一个出站，因此调整出站顺序本身就可能改变默认行为。复制片段时应把引用与目标一起核对。

合并片段与保存修改

合并配置时，同一个顶层字段只保留一份。已有出站数组应追加或修改对象，而不是再写一个同名数组；重复键在不同解析器中的处理方式可能不同，容易出现界面看似保存、实际只读取后一份内容的情况。对象内的字段也应按所属层级归位，例如传输设置属于相应出站，不能放到顶层路由对象。遇到可选字段，先保留内核默认值，再为确实需要的行为增加设置，不必把所有文档参数都填进文件。

桌面端首推使用 v2rayN 管理常规节点，但不要直接覆盖它运行时生成的临时配置。下次选择节点、更新订阅或重启服务时，客户端可能重新生成文件。应先确认是在编辑自定义配置，还是修改客户端持久保存的设置。测试前保留一份可工作的配置，记录改动字段与预期结果；测试后检查日志中的实际监听端口和所选出站。配置结构稳定以后再加入路由与 DNS，问题范围会明显缩小。

inbounds 入站配置

监听地址、端口与应用接入

入站定义内核在哪里接收连接、以什么协议理解连接。普通桌面使用中，SOCKS 与 HTTP 是常见的本地入口。应用必须主动把请求交给这个入口，或者由系统代理、虚拟网卡等机制转交。监听地址设为本地回环地址，只接受本机连接；设为所有网卡地址则可能允许局域网设备访问。后一种方式还涉及防火墙、认证与网络边界，不能只为了排错就扩大监听范围，尤其是在公共网络或多用户设备上。

端口必须与应用填写的代理端口一致，并且没有被其他程序占用。端口占用通常在启动日志中体现为绑定失败；此时更换节点不会解决问题。可以先关闭另一个代理客户端，或在图形设置里调整本地端口，再让应用同步使用新端口。SOCKS 端口和 HTTP 端口不是可以随意互换的名称：把 HTTP 请求交给仅接受 SOCKS 握手的入口，会在连接早期失败，表现可能只是浏览器提示代理服务器异常。

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

认证、UDP 与域名信息

本地单用户场景经常使用不带认证的 SOCKS 入站，但这不意味着任意监听地址都适合关闭认证。共享给其他设备时，要同时评估谁能访问端口、客户端协议是否支持所需认证，以及系统防火墙是否限制来源。认证只是一个环节，不能代替合理的监听边界。HTTP 入站的设置结构与 SOCKS 入站不同，不能直接把一套认证字段复制过去；应按当前协议和内核支持的格式设置，并分别验证应用能否完成握手。

SOCKS 入站中的 UDP 开关只表示该入口允许处理相应的 UDP 请求，不保证整个路径都能传送 UDP。应用是否使用 SOCKS 的 UDP 关联、远端协议和服务是否支持、出站是否允许，以及防火墙是否放行，都会影响结果。普通浏览器的系统代理测试也不能覆盖所有 UDP 行为。若网页可访问但某类应用失败，先区分失败的是 TCP 连接还是 UDP 流量，再判断是否需要改变接入方式，避免把所有现象归到节点质量。

域名由谁解析也与入站方式有关。应用可以把域名交给 SOCKS 入口，也可以先自行解析成 IP 再建立连接；HTTP 代理通常能从目标信息中得到域名。路由若依赖域名规则，而入站仅接收到 IP，结果可能与预期不同。协议嗅探可以从部分可识别流量中恢复目标域名线索，但并不是所有流量都具备这样的信息。启用嗅探还可能影响目标选择，应在明确需求后使用，不要把它当成保证域名规则命中的万能选项。

v2rayN TUN 模式与系统代理

v2rayN TUN 模式与普通本地入站解决的是不同层面的问题。系统代理主要向遵循系统设置的应用提供代理入口；TUN 模式通过虚拟网络接口接收符合其路由范围的流量，适合一些不读取系统代理的应用。它涉及虚拟网卡、路由与权限，不能简单等同于在入站数组中加入一个字段。客户端使用的接入实现和配置生成方式可能随平台变化，手工内核配置与客户端 TUN 设置应分别阅读。

切换 TUN 前先确认常规代理路径能工作，再检查所需权限与其他网络软件是否冲突。一次只保留一套主要接管方式，避免多个虚拟网卡或代理进程同时修改路由，导致流量循环或解析路径不明确。关闭 TUN 后若访问仍异常，检查系统代理是否残留、虚拟接口是否恢复以及应用是否缓存代理设置。关于浏览器与终端的不同接入方式，可继续阅读系统代理不生效的分线排查，不要仅凭一个应用的结果判断整个入站失效。

outbounds 出站配置

默认出站与连接目标

出站描述请求离开内核的方式。直连出站由本机直接连接目标，阻断出站终止匹配请求，代理出站则先连接远端服务，再由远端处理目标连接。出站数组可以同时包含这些对象，具体使用哪个由路由决定。常见配置把代理对象放在第一位，使未匹配特殊规则的连接走代理；本页第一章的基线则故意把直连放在第一位，只用于验证本地接入。复制示例前先看默认出站，否则容易把结构测试配置误当作远端代理配置。

远端地址、远端端口、用户标识与传输方式需要作为一个整体核对。地址正确但端口不对，通常连不上服务；网络握手成功但用户参数不一致，可能在协议阶段被拒绝；用户参数正确但传输层设置不同，也无法建立预期连接。客户端显示的节点名称只是别名，不能证明这些字段一致。应通过节点编辑界面核对服务提供的完整参数，尤其注意导入后是否丢失传输路径、服务名或安全设置。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-0000-0000-000000000000",
                "encryption": "none",
                "level": 0
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.com"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

VLESS 协议与传输、安全层

VLESS 协议的用户配置中，常见的加密字段为示例里的取值，但这不表示整个连接没有安全层。协议、传输与传输安全是三个不同维度：协议决定代理请求如何表达，传输决定这些内容通过哪类连接承载，安全层决定相应连接如何保护。上面的示例采用 TCP 与 TLS，只用于展示字段关系，实际服务并不存在。若服务使用其他传输或安全方案，必须按服务参数修改，不能把所有方案的字段堆在一个对象里。

V2Ray 协议选择首先受服务端配置与当前内核能力约束，而不是在客户端菜单中自由更换名称。VMess、VLESS、Trojan 与 Shadowsocks 的认证和参数结构不同，不能仅改协议字段就实现互换。VMess 还需要关注设备时间等条件；不同协议的安全设计也不能用单个设置项概括。需要比较基础差异时，可阅读VMess 与 VLESS 的区别，再回到实际节点参数决定客户端内的选择。

TLS 的服务名称需要与证书及服务端配置相符。远端连接地址可以是域名或 IP，但连接地址与用于证书验证的名称并不总是同一概念。浏览器能打开某个地址，也不能证明该地址提供对应的代理协议。遇到证书错误，应检查系统时间、名称和证书链，并确认参数来源；不要先关闭证书验证来消除错误提示，这会隐藏真实配置问题，也削弱原本的连接验证过程。

内核兼容性与参数保留

Xray 与 V2Fly 共享部分配置概念，但不能据此推断每个字段、每种传输和每个扩展都通用。v2rayN 可提供内核选择，v2rayNG 与 v2flyNG 则面向不同内核体系；切换前需要核对节点依赖的功能。出现未知字段、协议不支持或启动失败时，应先回到当前内核支持范围，而不是反复修改远端地址。生态对应关系可查阅Project V、V2Fly 与 Xray 的关系。

导入已有节点后，优先保留客户端能够识别的原始参数，逐项确认再做定制。某些界面会根据传输类型隐藏不相关输入项，隐藏不代表此前填写的内容一定参与最终配置。可以查看生成配置中的出站对象，确认参数确实位于正确层级。一次测试只改变一个设置，并保留失败日志与时间点；若同时更换协议、传输和内核，即使最终恢复连接，也很难知道是哪项调整起了作用。

routing 路由规则

规则顺序与匹配条件

路由把连接特征与出站标签关联起来。常见特征包括目标域名、目标 IP、目标端口、网络类型和入站标签。规则通常按顺序检查，先命中的规则决定连接去向，因此精确例外应放在宽泛规则之前。未匹配任何规则时，连接通常交给第一个出站。理解默认出站和规则顺序比记住更多字段更重要：一条靠前的宽泛规则可以让后面的精细规则始终没有机会处理相应请求。

同一条规则内，不同类别的条件通常需要同时满足，而同一类别数组中的多个值用于提供可选匹配。例如同时写入站标签和目标域名，意味着只处理该入站收到的相应域名请求，而不是匹配其中任意一个条件就生效。多个意图不应硬塞到同一对象中；需要表达两种独立情形时，应拆成两条规则。拆分后也更容易记录每条规则的目的，并通过日志定位哪条配置改变了出站。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:blocked.example.com"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.com"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

域名规则与地址规则的边界

示例中的完整域名匹配仅针对指定名称，域名匹配则用于相应域及其子域。第一条先阻断一个具体子域，再允许同一主域的其他匹配请求直连，展示精确规则优先的效果。不要用普通字符串的直觉替代各前缀的语义，尤其是正则表达式：过宽表达式可能意外匹配不相关域名，也会增加维护成本。先使用明确的完整域名或域名后缀，确实需要表达复杂规律时再采用正则，并准备正反两类测试目标。

私有地址规则只匹配实际进入路由判断的目标 IP。若请求携带的是域名，而路由策略保持不解析，单靠私有 IP 网段规则未必能识别这个域名最终指向的内网服务。可以为明确的内部域名增加域名规则，或按需求选择会参与 IP 判断的域名策略。另一方面，域名可能返回多个地址，IPv4 与 IPv6 结果也可能不同，所以一次测试命中规则并不意味着全部地址族、全部解析结果都能得到相同去向。

路由的域名策略与直连出站的域名策略作用位置不同。路由策略主要控制判断规则时是否需要解析域名；直连出站策略主要影响实际直连时的地址选择。将两者混为一谈，会出现“已设置解析策略但路由仍不匹配”的误判。采用按需解析时，还应理解触发条件及当前内核实现，避免无意中增加 DNS 查询。能够通过域名准确表达的规则，不必为了匹配 IP 而强制解析所有请求。

规则资源与可验证的调整

一些路由配置引用地理地址或域名分类资源。这些引用依赖客户端提供的资源文件、资源名称与更新方式，并不是写进 JSON 就自动存在。资源缺失可能导致启动错误，分类内容不同也可能改变匹配范围。本页使用明确域名和网段，便于独立理解；如果导入外部规则，应先查看它需要哪些资源、是否适用于当前内核，再检查生成配置中的实际引用，不要只根据规则标题判断兼容性。

修改路由后，建议选取一个应直连、一个应代理和一个应阻断的目标分别验证，并检查连接日志记录的出站标签。浏览器缓存、已有长连接以及应用自行解析都会让结果看起来没有变化；需要时关闭旧连接或重新打开应用。若发生全局断连，先移除最后加入的宽泛规则，再核对标签拼写与默认出站。规则数量不是质量指标，少量能解释、能测试的规则更适合长期维护，也更便于迁移到另一个客户端。

dns 域名解析配置

先确认解析发生在哪里

DNS 问题应先按解析位置分类。应用可能使用系统解析器，也可能内置自己的解析方式；本地代理可能收到域名后在内核中解析；远端服务也可能根据域名连接目标。这些路径可以同时存在。顶层 DNS 对象只控制使用内核 DNS 功能的相关请求，不会自动接管设备上所有程序的域名查询。因此“修改了 DNS 但浏览器结果没变”并不能直接说明设置失效，要先确认浏览器的请求是否进入该解析路径。

连接目标的解析与代理服务器地址的解析也要分开。出站需要先找到远端服务，若远端地址本身是域名，启动或建连时就可能需要解析它。随后访问的网站域名又可能在其他位置解析。把所有查询都要求经过尚未建立的代理连接，可能形成启动依赖循环。设计解析通路时，应明确远端服务地址怎样解析、解析服务器怎样访问，以及代理失效时是否还有可用的必要解析路径，而不是只选择一个看起来更熟悉的服务器名称。

{
  "dns": {
    "hosts": {
      "service.example.com": "192.0.2.10"
    },
    "servers": [
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

静态映射、服务器与地址族

这个片段用本地系统解析器建立基线，并展示静态域名映射的结构。示例地址属于文档用途地址，不能作为真实服务目标；测试真实网站时应移除这条教学映射。静态映射适合明确知道目标地址且需要固定解析结果的场景，不适合长期替代变化频繁的服务解析。域名对应的地址可能因地域、负载与服务迁移而改变，固定一个旧地址可能使连接失败，也可能让请求绕过正常的地址选择机制。

解析服务器既可以采用系统解析，也可以采用内核支持的其他形式。不同形式可能使用不同协议、端口与通路，不能仅看服务器地址就判断是否经过代理。配置基于 HTTPS 的解析服务时，还需考虑这个服务域名自身的解析与连接路径。部分内核会区分本地直连查询与可被路由处理的查询方式，具体行为应核对所用内核。先用简单、已知可达的解析方式验证，再增加域名分配规则，能减少多个依赖同时失败的风险。

地址族策略决定查询或接受哪些 IP 类型，但不能让原本没有 IPv6 连通性的网络突然具备相应能力。选择只使用某个地址族后，若目标没有对应记录，也可能失去可用地址。遇到部分站点连接慢、解析成功却超时，应检查得到的地址族是否与本机、远端服务及最终出站的连通性一致。调整前记录解析结果，调整后对同一域名重复观察，不要仅凭一次成功访问就断言某个地址族在所有场景下更合适。

域名分配、缓存与路由协作

更复杂的 DNS 配置可以为部分域名指定解析服务器，并控制回退行为。指定服务器回答失败、返回空结果或被过滤后，是否继续查询其他服务器，会影响最终结果与访问速度。这里需要同时看内核支持的服务器对象字段和回退逻辑，不能把“优先使用”理解成“只允许使用”。如果设置了地址范围限制，还应确认目标正常结果是否可能落在范围之外，否则会把有效回答当作不符合条件的结果。

DNS 与路由之间需要保持语义一致。希望某个内部域名直连时，应让解析路径能获得内部地址，并让路由识别相应名称或地址；希望某类连接通过远端服务时，也要确认解析位置不会破坏服务预期。不要把 DNS 服务器选择、路由出站选择和浏览器的安全解析设置视为同一个开关。它们分别作用在不同层面，排错时可以先固定其中两项，仅调整另一项，再从日志和应用行为确认变化。

缓存会让修改后的结果暂时看不出来。缓存可能位于浏览器、操作系统、内核或远端解析器，重启一个进程并不一定清除全部层级。验证时先确认配置已重新加载，再关闭旧连接，必要时重新启动目标应用；同时保留解析失败、连接超时和证书错误的区别。若只有一个应用异常，应先检查它是否启用独立解析方式。涉及虚拟网卡的场景还要看 DNS 是否由客户端另行接管，避免反复修改未参与实际请求的顶层对象。

policy 策略与统计

用户等级与连接时间限制

策略模块用于定义部分连接行为和统计开关，不负责决定请求走哪个节点。常见层级是按用户等级设置策略，并为整个系统设置统计选项。用户等级是配置引用，不是账号权限、付费等级或节点质量评分；只有协议对应的用户对象支持并使用这个等级时，相应策略才有作用。若配置里写了一个等级，却没有任何相关用户引用它，就不能据此期待所有连接自动采用该组参数。

连接建立、空闲保持和半关闭等待是不同阶段。握手时间限制约束建立连接过程中的等待，空闲时间限制针对没有活动的连接，单向关闭后的等待用于处理另一方向尚未完成的数据。缩短这些数值可能加快回收资源，也可能让慢网络、长轮询或长时间静默的应用频繁断线。参数调整应依据具体症状，不要把所有超时一起调小，再把由此产生的断开误判为远端服务不稳定。

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

统计开关、身份与读取方式

示例中的时间字段按常见内核语义使用秒，数值用于说明结构，不是适合每个网络的推荐组合。等级对象的键是字符串，用户对象中的等级通常是数字，二者在配置里的类型不同。先保留客户端默认策略，确实遇到可复现的超时问题后再调整。某些缓冲区或连接管理字段的支持范围、单位与默认值会随内核而不同，不能把网上的一整套参数直接当作通用优化方案。

统计模块开启与统计结果可读是两件事。空统计对象用于启用模块，策略中的开关决定收集哪些方向或对象的数据，但不会自动在界面上生成图表。读取结果还需要客户端具备对应支持，或配置内核支持的统计接口。客户端本身显示的速度或流量也可能采用另一套采集方式。因此界面没有出现用户统计，不一定说明整个统计模块失效，应先确认它准备读取哪类数据，以及接口是否实际存在。

用户级统计通常还依赖相应用户对象中的可识别身份字段及协议支持，只有等级开关可能不足以形成预期条目。本地普通 SOCKS 入口并不因为写了等级零就自动获得远端用户身份。入站、出站和用户统计反映的观察位置也不同，不能不加区分地相加作为实际网络用量。封装开销、不同传输层和多个连接都会影响比较结果，统计更适合观察趋势与定位活动来源，而不是直接对应服务端账单。

统计接口与资源边界

如果需要手工配置管理接口，必须阅读当前内核的接口模型与服务列表，并将监听范围限制在所需边界内。接口入口、对应路由与服务名称往往需要协同配置，仅加入一段策略不会建立可访问的管理通道。不要为了让统计工具连上就把接口开放到所有网卡；这类通道不应与普通代理入口混淆。图形客户端已经管理相关接口时，优先使用其现成展示，避免另建入口与已有端口发生冲突。

策略变化也要用可重复的业务行为验证。针对空闲断开，记录应用建立连接后的静默时间和断开时间；针对握手失败，记录是否已经连接远端端口、是否进入安全层或协议阶段。只有证据落在相应阶段，才值得修改相关策略。若实际问题是 DNS 失败、路由指向阻断或节点参数错误，增加超时只会让用户等得更久，不会修复连接。资源占用异常也应先检查连接数量来源和流量循环。

完成测试后应恢复不再需要的诊断开关。详细日志与大量统计条目可能增加持续观察成本，保存的数据也可能包含访问习惯。配置手册中看到的每个模块并不都需要常驻开启，稳定运行时只保留能够解释用途的选项即可。对于移动端，还要区分策略引起的连接回收与系统后台限制：应用退到后台后被系统暂停，不能单靠延长内核空闲时间解决，需要检查应用权限和电池管理设置。

订阅与客户端配置生成

订阅内容不等于完整配置

订阅主要负责向客户端提供节点信息，完整运行配置通常由客户端结合当前节点、本地入口、路由、DNS 和其他设置生成。不同订阅格式能承载的信息范围不同，有的只描述节点，有的带有更多配置结构；客户端是否接受并保留这些内容，也取决于导入方式。不要把订阅地址、分享链接和完整 JSON 文件当成同一种资源。导入前应确认拿到的是哪类内容，再选择对应的订阅更新、剪贴板导入或自定义配置入口。

v2rayNG 订阅导入的常见流程是创建订阅分组、填写别名与地址、保存后执行更新，再检查分组中是否出现节点。v2rayN 的订阅分组设置也采用相近的管理思路。别名便于区分来源，地址用于获取实际内容，两者不能互相替代。更新成功后仍需选择节点并启动连接；下载到了订阅内容不代表远端服务可用，也不代表系统代理或移动端 VPN 接入已经开启，这些步骤要分别确认。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth"
      }
    }
  ],
  "outbounds": [
    {
      "tag": "selected-node",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "local-socks"
        ],
        "outboundTag": "selected-node"
      }
    ]
  }
}

上面的对象使用直连协议模拟一个被选中的出站位置，仅解释生成结构，并不是订阅内容格式。真实客户端会把所选节点转换成相应代理出站，再与本地设置组合。节点名称可能变化，而客户端内部出站标签可能保持固定；也可能按配置模式生成不同标签。因此手写规则不能只依赖列表中的显示名称，应检查最终生成的标签。如果客户端提供统一的代理出站引用，应优先按它的规则编辑方式设置。

更新边界与自定义配置

订阅更新可能替换节点参数、增删节点或改变别名，具体合并行为由客户端决定。对订阅节点直接做手工修改后，下次更新可能覆盖这些改动。需要长期保留的特殊节点，可以按客户端支持的方式放入独立分组或独立配置，并记录来源与修改目的。本地路由和 DNS 是否会随更新改变也要看导入模式：仅更新节点与导入完整配置的行为不能混为一谈，更新前后检查实际运行对象更可靠。

自定义完整配置适合需要明确控制结构的用户，但可能绕过客户端部分自动生成功能。某些界面里的节点选择、路由预设或本地端口修改未必会影响这份配置。进入自定义模式前，应确认谁负责入站、谁负责管理接口、客户端是否仍会自动增加字段，以及启动时加载的文件位置。不要一边使用完整自定义配置，一边期待所有常规界面选项都能同步写入；先建立清晰的配置所有权，再增加定制内容。

迁移、隐私与客户端选择

迁移到另一款客户端时，先迁移节点，再重建本地接入和路由，不要假设所有界面预设都有同名对应项。桌面端首推 v2rayN，Android 可以根据内核需求选择 v2rayNG 或 v2flyNG；同样的节点信息在不同内核中可能受功能支持范围影响。查看客户端下载页选择系统对应入口，搜索 v2rayNG 下载时也应先确认设备架构。架构影响程序能否安装运行，不直接决定节点协议或路由行为。

订阅地址往往包含访问凭据，完整链接不适合放入公开截图、聊天记录或故障报告。报告问题时保留错误类型、响应状态和更新时间，隐藏查询参数及用户标识。更新失败应先区分无法访问地址、返回内容为空、内容格式不支持和节点解析失败；这些阶段与代理节点能否连接并非一一对应。若一份订阅只有部分节点缺失，重点检查缺失节点所用协议和传输是否受支持，而不是立即重装整个客户端。

自动更新间隔也需要适度设置。过于频繁的更新会增加不必要请求，还可能在排错期间不断改变测试对象；过长则可能保留已经失效的参数。按服务实际变更频率和使用需求决定即可，不应把短间隔理解成更高连接质量。开始排查时可以暂时固定节点与配置，完成验证后恢复常规更新。首次完整操作仍按入门指南的订阅步骤进行，本章主要帮助解释更新之后哪些模块发生了变化。

配置验证与故障定位

从读取配置到应用访问

验证顺序应沿连接路径展开：先确认配置语法能读取，再确认内核启动和本地监听，然后确认应用确实使用入口，接着检查路由选择、DNS 结果、远端连接与协议握手，最后测试实际应用。这个顺序能把故障缩小到一个阶段。网页打不开并不是具体原因，重装客户端也不能替代定位；只有知道最后成功的阶段和最先失败的阶段，才能决定下一步检查端口、权限、参数还是网络通路。

修改后先确认加载的是新配置。客户端可能保持旧进程运行，或者启动时重新生成另一份文件；编辑器里的内容与运行状态不一定一致。保存配置后按客户端的方式重新启动服务，再检查启动日志中的监听地址、端口与所用内核。若日志显示未知字段，先查兼容性；若显示地址绑定失败，先查端口；若连启动日志都没有，则检查程序是否正常启动，可参照客户端闪退与权限问题排查。

{
  "log": {
    "loglevel": "info"
  }
}

日志信息与问题分类

临时使用信息级日志可以帮助观察接入与出站过程，但日志内容和详细程度取决于内核与客户端。不要预期每一条规则都会给出统一格式的命中记录，也不要把一个提示词脱离上下文解释。读取时保留时间顺序：应用发起连接之后是否有入站记录，是否选择出站，失败发生在解析、建连还是握手。诊断结束后恢复适合日常使用的级别，分享日志前隐藏目标地址、订阅参数和用户标识等敏感内容。

同一错误可能有多种原因，因此表格用于确定检查顺序，而不是给现象贴唯一结论。远端超时可能是网络不可达，也可能是端口错误；握手错误可能来自服务名称不符、认证不一致或传输参数缺失。用已知可工作的配置进行对照，比反复添加陌生参数更有效。对照时尽量保持同一设备、同一网络和同一测试目标，避免把网络环境变化当成配置修复效果。

V2Ray 节点测速与实际可用性

V2Ray 节点测速包含不同测试方法。端口连通测试只说明目标端口能否建立连接，不一定完成代理协议；通过代理访问测试地址更接近应用使用，但仍受测试站点、DNS 与路由影响；下载测试观察持续传输表现，也会消耗流量。界面里的一个时间值不能代表全部访问体验。比较节点时保持测试方法和目标一致，结合实际使用的应用验证，不能只按一次排序结果决定长期配置。

测试成功但浏览器失败时，重点检查两者是否使用同一入口和路由。浏览器扩展、绕过列表、自带解析与旧连接都可能改变请求路径；终端工具还可能使用自己的代理设置或环境变量。反过来，浏览器成功也不能证明所有应用都遵循系统代理。对存在差异的应用逐一确认接入方式，并记录是否能在内核日志中看到请求。需要扩大流量接入范围时，再回到本页的 TUN 章节评估权限与路由影响。

回退、记录与稳定运行

每轮测试只改一组相关字段，并写下预期现象。例如为一个域名增加直连规则后，预期是出站标签改变，而不是所有访问速度都提高；调整解析策略后，预期是地址族或解析路径改变，而不是认证错误消失。若结果不符，先恢复上一份可工作配置，再核对规则前置条件。保留简短的改动记录，包含字段、测试目标和观察结果，能防止多次试验后忘记当前配置为什么存在。

稳定配置应保留明确的默认出站、有限且可解释的规则、符合实际接入方式的 DNS，以及必要的本地监听边界。把临时教学映射、诊断接口和试验参数清理掉，再恢复订阅更新。若仍需报告问题，说明客户端名称、操作系统、内核类型、失败阶段与脱敏日志，不必公开完整配置。后续查阅从本页目录进入具体模块，日常连接则沿入门指南执行；这样既能保留可维护的结构，也能避免每次异常都从头重建全部设置。