V2Ray 协议与内核
技术参考

协议分层：先拆开客户端里的设置项

客户端、内核与服务器不是同一层

选型的起点不是比较哪一个名称更新，而是分清连接由哪些部分共同完成。v2rayN 是管理服务器、订阅和运行模式的图形客户端；内核负责实际建立连接、处理协议、执行路由与解析规则；服务器则必须提供与客户端相匹配的接入方式。界面中能够选到某个协议，只能说明客户端提供了对应编辑入口，不代表当前运行的内核、服务器配置和导入格式已经同时支持它。

一条连接可以按本地入口、代理协议、传输方式、安全层与远端出口理解。本地入口决定应用如何交出流量，例如系统代理指向的本地代理端口，或由虚拟网卡接收的数据。代理协议负责用户认证和请求表达；传输方式决定这些数据如何装入底层连接；安全层负责相应的传输保护。远端出口再向目标服务发起连接。任意一层失配，都可能表现为浏览器一直等待，但处理方法完全不同。

协议与传输方式必须分别核对

VMess、VLESS、Trojan 和 Shadowsocks 属于代理协议或代理方案名称。TCP、WebSocket、gRPC 则描述传输方式，不能把两组名称放在同一列评判替代关系。VLESS 可以与不同传输及安全设置组合，但实际支持范围受到内核和服务端限制。服务端若要求 WebSocket，客户端只把协议类型选成 VLESS 而保留普通 TCP，并不能得到等效连接；相应的路径、主机名和安全层设置也要一起匹配。

TLS 与 REALITY 也不应被理解为另一个服务器地址或另一份订阅。它们位于连接的安全配置部分。普通 TLS 连接需要根据服务器身份核对证书与名称；REALITY 有自己的身份验证参数和握手机制。客户端界面把它们放进同一个下拉框，是配置组织方式上的接近，不意味着字段可以逐一替换。尤其不要把 TLS 的证书选项直接照抄到 REALITY，或者把 REALITY 的公钥填进用户标识栏。

用分层思路理解导入和测速结果

订阅导入成功，通常只说明文本能够被解析成一条客户端记录。它没有证明远端端口可达，也没有证明认证参数正确。端口可达同样不等于协议握手成功：某个端口能够建立底层连接，后续仍可能因为名称、路径、用户标识或安全参数不匹配而中止。因此核对连接时，应按照导入解析、底层建立、协议认证、目标访问的顺序推进，不要把一个成功提示当作全部链路已经完成的依据。

路由与 DNS 会进一步影响看到的现象。某个应用可能没有交给客户端，某个域名也可能被分配到直连出口；此时测试结果无法代表所选服务器。建议先使用同一个应用、同一个目标和明确的接管模式进行验证，再增加分流规则。把一次测试中的变化限制在一个层次，才能知道结果来自协议、解析还是本地入口。常见字段的简短定义可随时对照术语表，避免把名称相近的设置当成同一个参数。

代理协议：诞生背景与设计取舍

VMess 与 VLESS：两条不同的设计路径

VMess 是 Project V 生态中的重要协议，设计时把用户认证、请求表达和数据保护组织在协议体系内。它长期积累了较广的客户端与订阅支持，适合已经部署了完整配套配置的场景。现代配置应关注所用实现支持的认证与加密方式，而不是照搬旧教程中的遗留字段。遇到旧分享内容时，需要确认其含义是否仍被当前内核接受；客户端成功保存旧字段，不保证内核会按原有方式处理。

VLESS 的方向更精简，减少代理协议本身的职责，把传输保护交给配套安全层或其他受控环境。精简不等于自动安全，也不等于任意情况下都比 VMess 快。公网部署时必须结合明确的传输保护设计。常见的 VLESS 配置会同时涉及用户标识、传输方式、安全层和可选流控；其中任何一个字段改变，都可能使它与服务端不再兼容。用户应选择服务端实际提供的组合，而不是单独追逐协议名称。

两者都可能在客户端中显示用户 ID，但相似字段不代表二者可互换。将一条 VMess 记录的类型改成 VLESS，通常只改变了本地如何生成配置，服务端不会随之改变认证协议。协议迁移需要服务端建立对应入口，再通过新的配置分发给客户端。对于已有稳定连接的用户，如果没有明确的功能需求或兼容问题，维持双方一致的配置往往比只改一个下拉框更合理。

Trojan 与 SS：安全依赖与算法约束

Trojan 的常见设计依赖 TLS 提供传输保护，并通过密码进行代理认证。它把成熟的 TLS 能力与较直接的代理请求组织结合起来，但这不意味着只填密码就够了。地址、端口、服务器名称、证书信任以及实际传输配置必须一致。证书验证失败时，应检查名称、系统时间和服务端证书链；把验证关掉虽然可能改变报错，却同时撤掉了重要的身份确认步骤，不应作为常规连接方案。

SS 是 Shadowsocks 的常见简称，采用预共享密钥及明确的加密方法组织代理连接。它的配置常看起来较少，但算法名称本身就是协议兼容条件。不同算法家族的密钥格式、认证方式和实现要求可能不同，不能只核对密码而忽略方法字段。客户端与内核还必须支持服务端采用的具体方法。对已有 SS 服务，先确认算法和密钥格式，比笼统判断“支持 SS 所以都能连”更有效。

选择完整组合，不选择孤立名称

协议的背景解释了它为什么有这些字段，却不能替代实际环境中的验证。例如，较少的协议头可能减少某些处理开销，但一次访问还包含解析、握手、远端出口和目标响应。用户看到的差异可能主要来自部署位置和网络质量。对不同服务器做一次下载测试，再把结果归因于 VMess 或 VLESS，缺少必要的控制条件，也无法推广到其他设备。

面向客户端选型，更可靠的判断顺序是：服务端是否提供完整配置，当前内核是否支持这组参数，订阅能否完整表达，目标应用是否需要特定的流量能力。前三项有一项不满足，理论性能优势也无法兑现。不要依靠手工猜测补齐缺失的流控、安全层或算法；应向配置提供方确认原始参数，再在客户端中逐项核对。协议选择首先是一项兼容性决策，其次才是性能优化决策。

REALITY 与 XTLS Vision：安全层和流控的边界

REALITY 不是与 VLESS 并列的代理协议

REALITY 是 Xray 生态中的传输安全机制，常与 VLESS 一起出现，因此分享内容经常把整套组合简称为一个名称。配置时仍须分层理解：VLESS 负责代理请求与认证，REALITY 处理相应的握手和身份验证，Vision 则是另一项流控选择。三者相互配合，但不是三个必须永远捆绑的同义词。客户端显示 REALITY 选项，并不表示任意协议与传输方式都可以组合使用。

常见的客户端配置涉及服务器地址、端口、用户 ID、服务器名称、指纹、公钥以及短标识。地址指向实际连接入口；服务器名称参与握手配置，不一定与地址文本相同；公钥用于相应的服务端身份验证；短标识需要匹配服务端允许的值。不要从名称的字面意思推导其内容，也不要把可解析的域名任意填进服务器名称栏。参数应来自同一份有效配置，而不是从数篇教程中拼合。

PublicKey、ShortId 与 Fingerprint 各自解决什么

PublicKey 是客户端使用的公开验证材料，与服务端对应的私钥有关，但它不是用户 ID，也不是可以任意替换的备注。客户端只能获得连接所需的公开参数，不需要也不应接收服务端私钥。ShortId 是服务端识别配置的一部分，允许值、长度与格式受实现约束；某些配置可以使用空值，但不能据此推断其他服务也允许留空。导入时若缺失该字段，应先核对提供方的原始记录。

Fingerprint 用于选择相应的客户端握手指纹行为，不代表设备系统，也不是越特殊越好。它需要落在当前实现支持的范围内，并与部署要求相容。选项不可用时，先检查运行内核与客户端支持情况，而不是自行输入一个看似合理的名称。服务器名称也不等同于 WebSocket 的 Host 字段；即使两者在某套部署中取值相同，它们仍位于不同层次，排错时需要分别检查。

传输层安全选 REALITY 时，需按服务端配置核对 PublicKey 与 ShortId。不要用关闭身份验证、随机填写名称或混用其他服务器参数的方式处理握手失败。

Vision 优化的是特定数据路径

XTLS Vision 通常在客户端流控栏以 xtls-rprx-vision 表达。它针对特定的流量与传输组合优化处理路径，其中包括减少部分重复处理的机会。它不是通用的下载加速开关，也不是简单取消加密。实际效果取决于流量特征、内核实现与所用安全和传输方式。只有服务端配置与当前实现允许时，客户端才应选择对应流控；不能把它机械添加到所有 VLESS 记录。

常见部署采用 TCP 类底层传输配合相应安全层，但判断能否使用 Vision 应以实际内核支持和服务端要求为准。WebSocket、gRPC 等传输具有不同的数据组织与连接管理方式，不能因为它们也能承载 VLESS，就认为可直接套用同一流控。若导入后客户端出现流控不支持或组合无效的错误，应回到原始配置确认组合，而不是先删掉报错字段让配置勉强通过。

核对顺序与收益预期

手工添加时，先确认运行内核，再选 VLESS 和正确传输，随后设置安全层与流控，最后补齐服务器名称、指纹、公钥和短标识。保存后重新打开记录，检查字段是否被客户端保留。若某项在重新打开后消失，可能是编辑界面的组合限制、导入器未识别或版本能力差异，需要进一步查阅客户端日志，而不能只依据列表中仍有一条服务器记录判断成功。

评价这套组合时，应把正确握手放在第一位，把稳定访问放在第二位，再看长连接负载下的资源表现。短时测速可能主要反映服务器带宽，无法证明流控收益；偶发首包等待也可能来自 DNS 或移动网络恢复。需要进一步理解原理时，可阅读REALITY 与 XTLS Vision 技术科普。实际操作仍以配置双方一致为前提，不应为了套用某个技术名称而改变已经明确的服务端参数。

V2Fly 与 Xray：家族关系和配置兼容

共同来源不等于能力始终相同

Project V 提供了以模块化方式组织代理能力的生态背景，V2Fly 持续维护 V2Ray 相关实现，Xray 则在相关代码和配置传统之上独立发展。两者共享部分概念和配置习惯，例如入口、出口、路由与 DNS 模块，因此许多字段看起来相近。但它们是各自演进的项目，支持的协议扩展、传输细节、默认行为以及配置检查方式可能不同，不能把家族关系理解为所有配置永久双向兼容。

对一般用户，内核差异最直观的影响是某组参数能否运行。REALITY 与 XTLS Vision 是选择 Xray 时的重要功能依据；针对特定实现编写的配置，也应优先使用其目标内核。V2Fly 适合与其支持范围相匹配的现有部署。这里不存在仅凭项目名称就能决定的普遍优劣：服务器采用什么功能、客户端能完整生成什么配置，比抽象比较哪个内核“更先进”更直接。

三款客户端如何对应到内核

桌面端首推 v2rayN，覆盖 Windows、macOS 与 Linux，便于统一理解服务器记录、订阅分组和路由配置。具体可切换的内核范围，以安装环境和客户端当前支持为准。Android 端通常优先选择使用 Xray 的 v2rayNG；需要与 V2Fly 配套部署时，可考虑 v2flyNG。选择客户端时，先看平台和服务端要求，再看订阅格式，不要因为界面相近就假设两款移动客户端的能力完全一致。

图形客户端会把服务器记录转换成内核能够读取的配置。这个转换层可能补充默认值、重排结构或过滤不支持的字段，因此服务器编辑窗口并不是内核配置的逐字呈现。某个选项保存成功后仍无法运行，要结合启动日志确认客户端实际调用了哪个内核、生成配置是否被接受，以及错误发生在启动还是连接阶段。直接在内核层排错与在订阅层排错，是两个不同的问题。

迁移时逐项检查，而不是直接换名称

配置兼容需要分成语法、字段和行为三层。语法兼容表示文件能够解析；字段兼容表示相应模块识别这些选项；行为兼容才表示它们实际按预期工作。例如，同名的路由设置可能受到默认解析策略影响，同样的出口标识也必须被规则正确引用。内核能够启动，是必要条件，却不是所有路由、DNS 和传输组合均已验证的充分条件。

迁移前保留原客户端导出的配置和必要的界面截图，截图中应遮挡订阅地址、密码及用户信息。先只迁移一条服务器，关闭额外的复杂规则，在明确的本地代理入口中测试。随后逐步恢复域名规则、DNS 策略和 TUN 接管。若一次同时更换内核、协议、解析与运行模式，出现异常后很难定位变化来源，也可能把本地路由问题误认为内核不兼容。

更新内核也需要保留回退思路。新实现可能增加支持，也可能严格检查以前被忽略的字段；旧配置因此报错时，应先看具体字段说明，不要立即判断服务器失效。反过来，长期不更新也可能导致新订阅参数无法识别。安装入口和平台架构可参阅客户端下载中心，三款客户端的使用定位则可对照选型指南。本页关注能力边界，不把某次更新等同于所有环境下的性能提升。

连接速度与资源：哪些比较才有意义

区分首包等待、吞吐与连接稳定性

连接速度至少包含三类指标。第一类是发起请求到获得响应的等待，容易受 DNS、底层连接与握手往返影响。第二类是持续传输的吞吐，更多受到链路容量、拥塞、服务器负载和出口限制影响。第三类是连接能否持续保持，以及中断后多久恢复。一个组合可能首包较快但持续下载一般，也可能长连接稳定而首次访问稍慢，不能只用一个测速数字概括。

协议开销存在，但其影响需要放进整体链路观察。用户到服务器的路径、服务器到目标的路径以及目标服务本身，都可能成为瓶颈。不同服务器间的比较无法隔离协议差异；不同时间段的比较又可能混入负载变化。若要判断传输组合的影响，应尽量固定设备、入口位置、目标文件、测试工具和接管方式，多次交替测试，避免把某一次短暂波动写成稳定结论。

握手层数与连接复用各有代价

TCP、TLS 以及应用层传输可能带来不同的建立过程。WebSocket 和 gRPC 还涉及各自的协议封装，部署灵活性与连接管理方式也不同。额外封装通常意味着更多处理，但是否成为实际瓶颈，要看服务器部署、连接复用和流量特征。不能只数协议名称的数量，就推断某个组合必然慢；也不能因为经过同一个端口，就认为不同组合具有相同的握手成本。

复用能够在适用场景中减少重复建连，但会改变多个请求共享底层连接的方式。共享连接出现拥塞或异常时，多个请求可能一起受到影响；某些应用原本已经维护了自己的长连接，额外复用未必提供明显收益。调整复用应以所用内核、协议和流量需求为边界，不要把它作为所有服务器的默认提速开关。修改后需要同时观察短请求体验和持续连接表现。

CPU 与内存不能脱离工作负载比较

加密算法、硬件指令支持、协议封装和数据复制都会影响 CPU。较老的处理器可能在高吞吐下先达到计算上限，较新的设备则可能主要受网络限制。此时相同协议在两台设备上的表现并不矛盾。观察时应记录客户端与内核进程的持续占用，注意单个核心是否已接近饱和，而不是只看系统总体占用很低就排除计算瓶颈。短时峰值也不等于长期负担。

内存使用则与并发连接、缓冲、路由数据、DNS 缓存和日志有关。客户端图形界面的占用与内核的占用需要分开看；TUN 等接管组件也可能增加独立的工作量。把完整桌面客户端和单独的后台内核比较，没有相同的功能边界。对于资源有限的设备，可以先减少不必要的并发测速与详细日志，再观察正常业务下的基线，避免把测试行为本身误认为日常消耗。

建立可复现的本地记录

测试记录至少写下运行模式、内核、完整协议组合、网络类型和目标任务。先用同一服务器重复验证，再改一个选项；如果改变选项需要服务端同步配合，应确保两端确实一致。不要把连接失败时的自动重试、后台订阅更新或持续测速混入正常访问数据。比较结果只适用于当前测试条件，不能推广成某个协议对所有地区、设备和应用的固定排名。

对多数用户，稳定连接、配置可维护和参数来源明确，比理论上更少的几个处理步骤更重要。已经能够满足任务时，不必频繁变更传输组合。只有确认瓶颈位于本地计算、握手或连接管理，而非链路和目标服务之后，调整协议相关选项才更有针对性。把性能优化放在功能正确之后，可以减少为追求不可复现差异而引入的新问题。

移动端电量：协议之外的持续开销

耗电来自整条运行链路

移动端电量不能只根据协议名称判断。CPU 加密、虚拟网络接口、数据转发、无线网络活动以及应用后台请求都会消耗资源。即使代理本身没有大量业务，频繁心跳、重连和后台测速也可能让设备难以进入较深的休眠状态。因此评价某套配置是否省电，应同时观察真实传输量、连接重建频率和屏幕关闭后的后台行为，而不是只比较客户端电量页面中的一个百分比。

无线网络的工作状态尤其重要。移动数据和无线局域网具有不同的连接维护与省电机制，小流量但高频的请求，也可能带来持续唤醒。某些长连接会定期发送保活数据，目的是让连接在设备、路由器或网络中间设备上继续有效；缩短保活间隔可能改善特定环境的在线体验，却增加活动频率。延长间隔又可能让连接更容易失效，需要按应用需求权衡。

全设备接管与按应用接管的差异

Android 客户端通过系统提供的 VPN 接口建立本地流量接管后，可以覆盖不遵循普通代理设置的应用。接管范围扩大，意味着更多后台任务可能经过同一数据路径。某个应用原本只在局域网通信，错误路由后可能开始重试远端地址；某个同步应用持续失败，也可能不断建立新连接。这些行为在统计中会与客户端关联，但真正原因未必是加密或代理协议本身。

若客户端支持按应用接管或排除，可根据实际需求缩小覆盖范围，但应明确哪些应用将绕过代理。分流规则还要与 DNS 处理一致，否则应用虽然走直连，名称解析仍可能进入另一条路径，引起等待或重复请求。对于依赖局域网发现、打印或家庭设备控制的应用，应单独验证其访问行为，而不是用更宽泛的规则反复试错。减少无效请求往往比替换协议更有效。

后台限制与持续连接需要平衡

系统电池优化可能限制后台进程，客户端停止后，应用的请求可能超时或触发频繁重连。为保持持续连接而放宽后台限制，有时是功能所需，但它不会自动降低耗电。应先确认问题是进程被暂停、系统回收，还是网络切换导致旧连接失效。只要看到断开就取消所有省电限制，会扩大后台运行范围，却不一定解决真正的握手或解析错误。

v2rayNG 通常作为 Android 上使用 Xray 配置的优先入口，v2flyNG 则用于与 V2Fly 配套的场景。两者的界面和实现差异可能影响可用功能，但不能据此承诺固定的续航排名。若要比较，应保持同一设备、相同网络、相近信号、相同应用任务与接管范围。屏幕亮度和其他后台应用也要尽量一致，否则它们的耗电变化可能远大于代理路径的差别。

先排除持续测速、详细日志、失效连接重试和不必要的应用接管，再比较协议。能够解释的后台行为，比一次电量百分比更有诊断价值。

用对照观察定位异常

建议先观察客户端关闭时的待机情况，再观察客户端开启但没有主动传输时的表现，最后执行相同的浏览或下载任务。每一轮都记录网络是否切换、连接是否重建、是否出现持续错误。电量统计通常有延迟，也会受到系统归因方式影响，不适合用很短的窗口下结论。设备发热时还可能发生降频，使速度下降，看起来像协议变慢，实际却是散热与负载共同作用。

如果后台日志持续出现超时，应优先修正参数、DNS 或路由；如果只有切换网络后失效，则观察客户端是否重建连接与重新解析地址；如果只有某个应用引起异常，应缩小到该应用的访问行为。需要理解虚拟网卡接管范围时，可以阅读TUN 模式原理与开启步骤，但移动端具体权限和后台策略仍以设备系统与客户端界面为准。协议选择应服务于稳定任务，而不是代替系统层面的电量诊断。

订阅与配置：格式兼容不等于参数完整

订阅是配置分发方式，不是连接协议

订阅地址用于获取服务器记录，其内容可能是分享链接集合、编码后的文本，或客户端约定的结构化配置。订阅的获取过程与代理服务器的连接过程彼此独立：更新失败不一定表示已有服务器失效，已有服务器能连接也不保证订阅地址仍然有效。排错时应先区分获取失败、内容解析失败、字段转换失败以及连接失败，避免把所有问题都归为订阅不可用。

分享链接把参数放进不同位置，例如地址部分、查询字段或编码结构。不同协议的用户标识、密码、算法和传输字段，并不存在统一的逐字映射。即使两个客户端都显示支持同一种分享格式，对扩展字段、默认值与名称编码的处理也可能不同。较简单的记录容易互通，涉及 REALITY、流控或较新传输选项时，则必须进一步确认导入器是否完整保留关键字段。

导入后重新打开记录核对

最小核对清单应包含地址、端口、协议、认证信息、传输方式和安全层。对于 WebSocket，继续检查路径与相关主机设置；对于 gRPC，检查服务名及部署要求；对于 REALITY，核对服务器名称、指纹、公钥、短标识和流控。别名只是本地识别信息，名称相同不表示配置相同。订阅更新后也应注意选中记录是否仍然存在，以及客户端是否切换到了另一条同名记录。

订阅提供方可能调整参数或替换服务器，所以手工修改的订阅记录在后续更新时可能被覆盖。若需要临时实验，先复制为本地记录并注明用途，避免在原分组中混入无法追溯的变更。实验成功后，仍应确认参数是否来自服务端要求，而不是偶然绕开某一段路由。分组管理的价值在于明确来源和更新边界，不是简单把所有链接合并成一个很长的列表。

认识客户端生成的内核配置

下面是一份仅用于本地理解入口与出口关系的最小配置：它在回环地址监听 SOCKS 端口，并将接收到的请求直接交给系统网络。该结构采用两类内核共有的常见模块，运行环境仍需具有对应支持且端口未被占用。它不包含远端代理，不应拿来替代订阅配置；若通过图形客户端管理连接，也不必为了阅读本页而单独运行内核。

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

这个示例中，入口标识用于区分本地接入，监听地址限制了可连接范围，端口用于让应用找到入口，出口则决定数据如何离开内核。真实客户端还会生成代理出口、路由和 DNS 等内容。不要为了让其他设备访问而随意把监听地址改成所有接口；那会改变暴露范围，需要另行考虑认证、防火墙与使用边界。理解配置结构的目的，是看懂数据路径，不是扩大入口权限。

安全分享与解析排错

订阅地址本身可能携带访问授权，导出的配置也可能包含密码、用户标识或其他连接材料。请求帮助时，只保留协议类型、传输方式、内核名称和经过遮挡的错误摘要。不要公开整份订阅，也不要把完整配置粘贴到不明确的在线转换工具。即使某些字段是公开验证材料，混合在同一记录里的其他字段仍可能具有敏感性，分享前需要逐项检查。

遇到更新失败，可先确认地址是否仍然有效、系统时间是否正确、获取过程是否报连接或证书错误，再检查返回内容是否确实为订阅而非提示页面。若更新成功但字段缺失，则转向格式与导入器兼容性排查。配置模块的进一步说明见JSON 配置结构解析；首次导入操作仍按配置教程的主线完成，不要在尚未验证基础连接时同时加入复杂自定义配置。

场景选型与排错：从完整配置走到稳定连接

先按平台和服务端能力缩小范围

桌面使用优先选择 v2rayN，再根据 Windows、macOS 或 Linux 选择相应安装入口与架构。Android 使用 Xray 配置时优先考虑 v2rayNG，与 V2Fly 部署配套时再评估 v2flyNG。接下来确认服务器提供的协议、安全层和传输组合。客户端选择不是从空白列表中挑一个理论最强的协议，而是在平台可用、内核支持、订阅完整和服务器匹配的交集中做决定。

已有稳定 VMess 或 Trojan 服务时，保持正确的现有配置通常比自行改为 VLESS 更合适。若服务端明确提供 VLESS 与 REALITY、Vision 配套配置，则选择能够完整承载这组参数的内核和客户端。只有 SS 配置时，应核对具体算法和密钥要求，而不是改用相近名称的类型。协议迁移需要新的服务端入口和完整参数，无法由本地界面的类型切换单方面完成。

按任务理解接管方式

浏览器和遵循系统代理的应用，可以先用系统代理验证基础访问；需要覆盖其他应用时，再评估 TUN。TUN 改变的是本地流量接管范围，不会自动修复远端认证或安全层错误。启用前应先证明服务器在普通代理入口下能够使用，再处理权限、虚拟网卡、路由和 DNS。这样即使出现全设备访问异常，也能知道问题主要发生在本地接管层，而非重新猜测所有远端参数。

开发与局域网协作场景还需要确认本机服务、内部域名和私有地址如何分流。规则顺序可能决定先匹配到哪个出口，DNS 策略又会影响按域名或地址作出的判断。不要只增加一条宽泛规则就结束测试，应分别验证公网访问、内部服务和名称解析。关于字段关系，可继续阅读DNS 分流解析说明，并在每次修改后保留明确的测试结果。

用错误阶段替代反复重装

内核启动失败时，先处理配置语法、未知字段、缺少支持或本地端口占用。此时远端服务器是否在线并不是首要问题。底层连接超时，则优先核对地址、端口与当前网络；连接被拒绝通常需要检查目标监听与访问条件。握手失败才进一步关注用户信息、安全层、服务器名称和配套参数。错误阶段可以缩小范围，但单条日志仍需结合上下文，不能机械地一一对应唯一原因。

若只有部分网站或应用失败，先确认它们是否进入客户端，以及被哪条规则送往哪个出口。域名解析错误、目标服务限制和应用自己的代理行为，都可能造成局部异常。此时更换协议未必改变问题，反而会丢失原来的对照条件。临时关闭自定义规则进行验证之前，应保留原设置；确认基础路径正常后，再逐条恢复规则，找到实际影响访问的那一项。

推荐核对顺序：配置能加载 → 远端能建立连接 → 握手与认证完成 → 目标能访问 → 分流符合预期 → 再优化速度与电量。

保留可维护的最终配置

完成验证后，记录客户端、运行内核、服务器来源、协议组合和必要的本地规则，不记录公开传播的凭据。保留一条已确认可用的基线，后续更新或调整只改一个维度。遇到问题时可回到这条基线比较，而不是把客户端重装、内核切换、协议修改和路由重置合并成一次操作。可回退、可解释的配置，比参数最多的配置更容易长期维护。

新手可回到快速配置教程按步骤完成导入与验证，也可查阅V2Ray 新手十问定位常见连接问题。需要更换平台安装包时，使用下载中心，不要在订阅记录中寻找客户端安装入口。本手册的选型结论始终围绕同一原则：让平台、内核、协议、传输、安全层和参数来源相互一致，再用实际任务验证稳定性，而不是仅凭名称决定连接质量。