V2Ray 协议与内核

连接层次：客户端、内核与协议

先确定每一层负责什么

图形客户端负责保存配置、导入订阅、切换出口和呈现日志；内核负责执行连接、解析协议、处理路由以及建立实际的数据通道。两者并不是同一件软件的不同名称。客户端可以包含内核，也可以启动独立的内核进程，因此界面已经成功保存一条配置，只说明管理层接受了这些字段，不代表运行中的内核一定认识全部选项。判断兼容性时，需要同时确认客户端能否表达该配置，以及当前内核能否执行该配置。

一条连接可以拆成代理协议、传输方式与安全层来理解。代理协议描述认证信息、目标地址和数据的组织方式；传输方式决定这些数据如何承载，例如直接使用流式连接或封装在另一种应用传输中；安全层负责相应的加密与身份验证。VMess、VLESS、Trojan 和 Shadowsocks 属于代理协议范畴，但各自与加密机制的结合方式不同。REALITY 是安全机制，不是导入时可以任意替换上述协议的通用协议名称。

配置名称不是兼容性证明

服务提供方可能把一条配置命名为“高速”“移动”或“备用”，这些名称只是备注。真正决定连接的，是地址、端口、认证信息、传输类型及安全设置。即使两条配置的协议栏都写着 VLESS，只要其中一条使用不同的安全机制或传输参数，就可能需要不同的内核能力。反过来，界面上出现相似名称，也不意味着两个项目使用完全一致的配置字段。应读取实际参数，而不是根据备注猜测底层组合。

检查参数时，先记录服务端要求的组合，再核对客户端。地址决定连接到哪里；端口指向对应监听服务；用户标识或密码用于认证；服务器名称通常参与安全握手；传输路径和主机名则可能属于应用层转发条件。它们可能在同一页设置中出现，却不承担相同职责。把服务器名称填进连接地址，或把网页路径填进主机名，都可能造成能够建立底层连接、却无法完成后续握手的现象。

从应用流量到远端出口

应用还需要有办法把流量交给客户端。系统代理通常是向遵循相关设置的应用提供代理地址，并不保证接管所有程序。TUN 则通过虚拟网络接口接收流量，还会涉及系统路由、权限和域名解析。两者属于流量入口，不是远端协议。开启 TUN 不会自动把 VMess 改成 VLESS，也不会补齐服务端缺失的安全参数。讨论连接故障时，应先说明流量有没有进入客户端，再检查出口连接。

推荐建立一份不含敏感认证值的参数清单，按上述层次注明配置来源与预期用途。首次连接只保留必要设置，完成验证后再增加分流、复用或虚拟接口功能。这样发生异常时，可以区分是入口、规则还是远端握手的问题。需要快速理解术语可查概念速查；需要按现象定位问题可查常见问题。选型的起点始终是服务端提供的完整组合，而不是先选一个名称再补参数。

VMess：认证、加密与时间条件

设计背景与使用定位

VMess 是 Project V 生态较早采用的代理协议，将用户认证、请求信息和数据保护纳入协议设计，长期出现在客户端配置与订阅中。它的常见使用场景是接入已经部署好的服务，而不是让用户自行拼装一套新的安全组合。理解它时，应区分协议自身的数据保护和外部叠加的安全层：配置使用了 VMess，不表示所有传输都必须再套同一种安全机制，也不能据此省略服务端明确要求的设置。

用户标识是识别认证身份的重要字段，常见表示形式为 UUID。它不是订阅备注，也不是远端服务器的机器编号。复制时应保留完整内容，不额外添加引号、空格或换行。连接地址可以是域名或地址文字，能否解析与用户认证是否正确是两条独立检查线。遇到连接失败，先确认域名解析与端口连通，再检查认证及安全握手，比反复更换用户标识更容易缩小范围。

旧字段与现代认证方式

历史 VMess 配置中常见额外标识数量字段，部分分享格式将其写为 aid。现代 AEAD 使用方式通常不再沿用旧式额外标识的工作路径，常见配置值为零，但不能把修改这个字段当成万能修复办法。旧服务端、旧导入器和当前内核之间可能存在兼容边界；如果来源仍提供历史参数，应向配置提供方确认服务端实际支持方式，而不是照着不同年代的界面截图逐项改写。

时间同步是 VMess 排查中值得单独检查的一项。认证机制涉及时间条件，系统时钟明显偏离可能导致认证失败。这里需要检查的是实际时间和自动同步状态，不能仅凭时区显示判断：时区不同不必然代表时间错误，手工把显示小时改成另一个地区的时间反而可能破坏正确时钟。桌面系统从休眠恢复、虚拟机暂停后继续运行，以及移动设备关闭自动时间之后，都应重新确认时间是否准确。

加密选项与传输参数

客户端可能提供自动或具体的数据加密选项，其可用范围由双方实现和内核支持决定。硬件加速能力、处理器架构及连接负载，会影响不同算法的实际成本，因此不能用某种算法名称直接推导吞吐排名。对于现成配置，优先保留提供方给出的参数；如果需要评估算法差异，应固定服务端、传输方式与测试负载，再比较处理器占用和持续传输表现，而不是同时调整多个字段。

VMess 可以搭配不同传输，但地址、路径、主机名和安全名称依然必须符合服务端部署。以经过反向代理的连接为例，底层端口能够建立连接，并不表示应用层路径也正确。路径大小写、前导斜杠或转发条件不一致，都可能在后续阶段被拒绝。安全层的服务器名称也不应直接照抄备注。导入后若客户端显示的传输类型与原配置不同，应先检查分享格式是否被完整识别，再尝试连接。

选用 VMess 的合理依据，是已有服务支持明确、参数可确认、当前客户端和内核能够完整执行。它并不因为出现较早就自动成为不可用方案，也不因为兼容条目多就必然适合所有设备。若现有连接稳定，升级或迁移应围绕具体需求展开，例如需要新的安全机制或减少维护分支。迁移时保留原条目，新增配置并单独验证，避免覆盖后失去可对照的基线。关于认证失败与日志读取的常见分支，可继续查阅故障排查问答。

VLESS 与 REALITY：协议和安全层组合

精简协议不等于省略安全设计

VLESS 的设计方向之一，是减少协议层自身承担的工作，将数据保护交给合适的外部安全机制。它负责表达认证和代理请求，但不应被理解为单靠协议名称就已经完成链路保护。界面中出现的加密选项 none，通常是在描述 VLESS 这一层的设置，不表示整条连接一定没有加密。实际安全性还取决于外部配置，例如是否正确使用 TLS 或 REALITY，以及身份验证是否按要求完成。

这一分层让配置更容易按职责解释，也带来更严格的组合检查要求。用户标识属于协议认证；服务器名称、相关公钥参数属于安全握手；传输类型决定承载方式；某些流控选项则受协议、安全层和内核实现共同约束。不能因为某个界面允许填写所有字段，就认为这些字段可以任意组合。对于不熟悉的选项，应先查清其适用条件，不要把另一条配置的值复制过来当作补全。

REALITY 的参数边界

REALITY 是与特定实现能力有关的安全机制，常见于 Xray 的 VLESS 配置。客户端通常需要连接地址、端口、用户标识，以及服务器名称、公钥和短标识等相关参数。不同界面可能改变字段显示名称，但这些信息的职责不会因此互换。公钥用于对应的握手验证，不是订阅地址；短标识也不是用户备注。缺失参数时，应回到可信配置来源获取完整内容，不能通过随机生成一个值来修复远端认证。

服务器名称必须符合服务端配置允许的条件，不宜随意替换为常见网站域名。连接地址和服务器名称可能不同：前者用于建立网络连接，后者参与安全握手。把两者统一成相同内容未必正确。公钥、短标识和名称之间也不是任选其一的替代关系。排查时应整组核对，确认导入器没有遗漏或错误映射，而不是只检查协议栏是否已经显示 VLESS。

流控、指纹与传输兼容

某些配置使用特定的流控方式，例如界面中的 Vision 相关选项。它不是所有 VLESS 连接都必须启用的通用加速开关，是否适用取决于服务端、传输和安全组合。其他配置没有提供该字段时，不应自行照搬。类似地，客户端指纹选项会影响安全握手行为，但更改指纹不等于提升带宽。先使用服务端要求或客户端明确支持的组合，再判断是否有调整必要，能避免把兼容问题误当成性能问题。

当客户端支持导入，却启动后立即报不支持安全类型或未知字段时，应优先核对运行内核。图形界面认识 REALITY 的链接参数，不代表所选内核也具备对应能力。切换到另一内核后，同一条记录可能仍保留原字段，但生成的实际运行配置发生变化。因此切换前应备份，切换后应查看启动结果与日志，确认参数确实进入内核，而不是仅观察卡片上的协议标签。

选择这一组合的前提，是服务端明确提供支持、客户端能够保存完整字段、所用内核能够执行相应实现。它不自动保证比其他组合更快，也不替代证书体系之外的全部运维检查。移动设备还需要考虑网络切换、长连接和后台运行行为。若只是日常接入现成订阅，完整导入并保持参数一致通常比手工追逐选项更可靠。协议与内核的分工可结合Xray 与 V2Fly 内核差异继续阅读。

Trojan 与 Shadowsocks：安全边界与方法标识

Trojan 与 TLS 的配合

Trojan 将代理认证和请求承载放在 TLS 连接之内，常见配置以密码作为认证信息。它的设计取舍与 VLESS 不同，不能只比较字段数量就判断哪一种实现更轻。用户看到的地址、端口和密码只是连接的一部分，服务器名称、证书验证及传输方式同样需要满足服务端条件。导入后能够显示密码，不代表证书链已经可信；底层端口能够连通，也不等于安全握手与代理认证都已通过。

证书验证用于确认对端身份。出现名称不匹配、证书过期或信任链异常时，应先检查配置中的服务器名称、系统时间和服务端证书部署。直接关闭验证会改变连接的安全边界，不能把它当成长期解决方式。企业网络中的自定义信任环境也需要按实际管理规则处理，而不是在所有配置上统一跳过验证。排查目标应是找到为何无法验证，而不是仅让错误提示消失。

Shadowsocks 的方法就是兼容条件

Shadowsocks 通常以较精简的代理与加密组合提供连接，配置核心包括地址、端口、加密方法和密码。这里的加密方法不是可以任意替换的本地偏好，而是双方协议协商之外必须预先一致的重要条件。不同代际的方法可能在密钥要求、会话处理和实现支持上存在明显差异。客户端列出的方法比服务端实际支持的多，并不意味着可以在本地选择其中任意一项。

较新的方法可能对密钥格式有严格要求，不能一概把人类可读的短口令当作可用密钥。历史分享链接还可能采用不同的编码形式；有的把方法与密码编码在一起，有的分别表示认证部分和地址。解析成功后，仍应核对方法名称与密码是否完整，尤其注意特殊字符在链接编码中是否被正确还原。对于来源明确的订阅，优先让客户端导入，不宜自行多次解码、拼接再重新编码。

扩展字段与数据报支持

部分 Shadowsocks 配置依赖额外扩展，而某些图形客户端或其当前内核并不提供对应实现。此时只有基础协议被识别，连接仍可能失败。不能看到同样的协议名称就判断配置完整兼容；应进一步核对是否需要扩展、扩展参数由谁执行，以及当前软件是否实际支持。本文只讨论站内三款客户端的选择，不建议为了追随某个分享链接而随意安装来源不明的附加程序。

需要语音、游戏或其他数据报业务时，还必须检查完整链路对 UDP 的支持。客户端入口能否接收数据报、协议实现能否承载、服务端是否允许转发，以及应用流量是否真的进入该入口，缺少任何一项都可能导致网页正常而特定应用异常。不要把这种现象直接归因为协议“不够快”。先通过日志和应用行为确认流量类型，再检查客户端的入口模式与服务端能力。

这两类协议的选用仍然服从已有服务的部署条件。具备规范证书运维的现成 Trojan 服务，可以按其参数使用；已有受支持方法且配置清晰的 Shadowsocks 服务，也有明确适用位置。不要通过关闭身份验证、替换加密方法或删去扩展字段，强行把不兼容配置改成“能导入”的配置。若需要迁移，应让服务端提供新的完整入口，并以独立记录进行验证，保留原有条目作为回退路径。

内核家族：Xray、V2Fly 与客户端适配

共同来源不等于持续互通

Project V 是理解这一生态的背景，V2Fly 维护 V2Ray 相关实现，Xray 则沿分支路线发展各自的功能。共同来源使部分概念和配置结构相近，但两个项目并不是同一程序的不同皮肤。分叉之后，功能、安全机制、传输实现和字段定义都可能分别演进。对某种协议的支持，也不能直接推导出对该协议所有扩展组合的支持。比较内核应围绕具体配置需求，而不是把项目名称当作性能等级。

需要 REALITY 或特定流控能力时，应确认所用 Xray 实现和客户端适配；已有 V2Fly 服务和配置时，则应检查对应内核的实际支持。常见基础协议可能在两边都能使用，但相同名称下的参数、默认值和约束仍需核对。对于较新的传输，尤其不能只依据旧教程判断另一内核是否支持。更准确的问题是“这份配置中的这些字段，当前运行环境能否完整执行”，而不是笼统询问哪一个内核更先进。

三款客户端的职责

桌面端首推 v2rayN，它用于 Windows、macOS 和 Linux 的配置管理，但不同界面形态、系统集成和发行包的具体能力应以实际界面为准。Android 端可优先考虑使用 Xray 内核的 v2rayNG，需要 V2Fly 路线时再评估 v2flyNG。三款客户端不应被视为同一个应用的三个平台名称，导入器、路由编辑方式和设置入口可能不同。迁移时应迁移配置含义，而不是逐字寻找完全相同的菜单名称。

客户端展示的内核切换能力也有边界。界面能够选择内核，不代表所有配置都会自动转换为语义相同的另一份配置。某些字段可能只在一边有效，另一些设置可能由客户端根据不同内核生成不同结构。使用自定义配置时，这种差异更加直接：一份可以被某内核读取的完整配置文件，不应原封不动地交给另一个内核并假设结果一致。保留原始文件和运行日志是迁移前的基本准备。

切换内核的检查顺序

先备份订阅来源、手工条目与自定义路由，再选择一条参数清晰的配置作为基线。暂时关闭与验证无关的复用或复杂分流，使用新内核启动并查看错误。启动阶段报未知字段，应检查配置结构；握手阶段报认证或安全错误，应核对远端参数；网页可用但应用异常，则继续检查流量入口、域名解析与数据报支持。不同阶段的错误对应不同层次，不适合统一用“换内核”反复尝试。

路由规则也需要单独核对。域名列表、地址列表及资源文件的格式和加载位置可能受客户端与内核共同影响。切换后如果连接本身正常，却出现本应直连的流量进入代理，应先查看实际生成的规则顺序和默认出口，而不是修改协议认证。规则文件缺失、分类名不同或域名解析策略变化，都可能改变匹配结果。内核迁移不仅是连接层兼容，还包含路由行为的复核。

长期维护时，建议记录哪些配置依赖特定内核、哪些规则由客户端生成，以及哪些设置来自手工修改。升级前保留可恢复的配置副本，升级后先做小范围连接验证，再恢复日常分流。下载入口集中在客户端下载页，不要把内核家族科普理解成需要单独获取额外程序的操作指引。生态关系可参阅Project V 生态全景，平台与界面选择则见三款客户端对比。

性能与电量：区分握手、吞吐和后台开销

“速度”至少包含三类问题

协议比较里最容易混淆的是连接建立时间、请求响应时间和持续吞吐。建立连接涉及域名解析、底层连接、安全握手与认证；响应时间还受到远端目标和链路往返影响；持续吞吐则取决于带宽、拥塞、服务端负载和本地处理能力。某种组合首次打开页面更快，不代表它在长时间传输中一定吞吐更高。协议名称只能解释部分结构成本，不能替代对具体链路的观察。

短请求反复建立连接时，握手成本更明显；长连接传输大量数据时，稳定吞吐和加密处理成本更值得关注。额外封装可能增加处理步骤和数据开销，但服务部署、转发链路及连接复用方式也会改变结果。不能脱离这些条件，给 VMess、VLESS、Trojan 和 Shadowsocks 排出恒定速度顺序。相同协议在不同设备、传输和服务器上的表现，可能比不同协议之间的差异更大。

资源占用要看负载结构

处理器开销与加密算法、硬件加速、数据拷贝和并发连接数有关。内存占用还受到规则数据、缓存、缓冲区和客户端界面的影响。打开完整图形界面时看到的总占用，不能全部归因于协议。比较时应让两组配置使用相近规则和流量入口，观察空闲与负载状态的差异。如果一组启用复杂规则和虚拟接口，另一组只开启简单系统代理，得到的结果并不是单纯的协议性能对比。

多路复用可以减少部分连接建立成本，但并非所有场景都受益。在存在丢包、服务端限制或不同业务相互影响时，额外集中连接可能带来等待和恢复问题。某些流控与复用组合还有实现约束，应以双方支持为前提。不要将复用线程数或连接数持续增大当作通用提速方式。先保留默认或来源明确的设置，确认存在可复现问题后，再一次只调整一个变量。

移动端电量主要受运行方式影响

移动设备耗电不仅来自加密计算，还来自无线网络唤醒、后台保活、频繁重连、域名解析和数据转发。一个空闲时仍持续通信的配置，可能比计算稍重但连接稳定的配置更耗电。网络在无线局域网和移动数据之间切换时，旧连接失效后的恢复行为也会影响体验。屏幕亮度、信号强弱和其他后台应用都能掩盖协议差异，因此不宜凭一次电量下降就认定某内核更省电。

测试 v2rayNG 或 v2flyNG 时，应使用相似网络和应用负载，分别观察前台使用、锁屏空闲及切换网络后的表现。系统电池管理可能限制后台活动，表现为锁屏后断连或恢复较慢；是否放宽限制应根据实际需求和耗电情况决定，而不是一律关闭所有节电措施。还应检查是否存在订阅频繁更新、自动测试或异常重试，这些后台工作往往比协议之间的小幅差异更容易造成额外消耗。

实际选择应优先消除明显不兼容和异常重连，再比较性能。记录测试条件、配置组合和问题发生阶段，比保存一个孤立的延迟数值更有用。结果只对相应设备与网络成立，不应推广为协议的永久排名。如果正常网页和持续传输均稳定，而某个应用独有异常，应先回到入口与路由检查；如果所有配置同时变慢，应检查公共网络条件，而不是连续更改协议参数。

订阅兼容：分享链接、编码与字段保留

链接外观不等于内容格式

单条分享链接描述一份连接配置，订阅地址则用于获取一组可能更新的配置。两者都可以被复制到剪贴板，但管理方式不同。分享链接通常带有协议前缀；订阅地址一般是可请求的网络地址，返回内容可能是链接列表、经过编码的文本或其他结构。地址以安全网页协议开头，只能说明请求入口的形式，不能说明返回内容一定被当前客户端识别。导入前应先确认来源给出的用途。

VMess 分享格式常见编码后的结构化内容；VLESS 和 Trojan 常见将认证、地址与查询参数组合在链接里；Shadowsocks 则存在不同的认证编码表达。这些形式在生态中被广泛使用，但并不代表每个导入器都支持全部变体。出现无法解析时，可能是链接被截断、编码损坏，也可能是来源使用了客户端尚未适配的字段。先判断错误属于格式层还是运行层，可以减少无效修改。

导入成功之后还要核对

客户端通常先把链接转换为内部记录，再根据记录生成内核运行配置。这个过程可能丢失不认识的字段，也可能给缺失字段补上默认值。因此“导入成功”只是第一步。应核对协议、地址、端口、认证、传输、安全层及相关附加参数，尤其关注 REALITY 参数、流控、服务器名称与传输路径。如果原链接中存在某项设置，界面却完全没有对应内容，应确认其是否被保留，而不是立即开始调整远端服务。

特殊字符是常见问题来源。密码中的分隔符、路径中的查询内容，以及备注中的非拉丁文字，可能需要正确的百分号编码。反复通过聊天窗口转发，或把整段内容当作普通网页地址处理，都可能造成截断或错误还原。不要在不清楚编码层次时对整条链接反复解码；应优先重新复制原始内容，使用客户端对应的导入入口，并检查粘贴时是否包含额外说明、空格或换行。

订阅更新与本地修改的冲突

订阅更新通常以远端返回内容为依据，客户端如何识别重复项、保留备注和覆盖设置，各有自己的规则。手工修改订阅内的条目，可能在更新后被恢复或替换。需要长期保留的测试配置，可在客户端支持的情况下复制为独立条目，并清楚标记用途；但独立副本不会自动获得远端的地址或认证更新，仍需定期核对。订阅管理和手工配置各有成本，不宜混成一组无法追溯来源的记录。

订阅地址本身可能包含访问凭据，应按敏感信息保存。提交截图、日志或问题描述时，隐藏完整地址、用户标识、密码和相关私有参数。排查下载失败时，记录连接错误、返回类型和解析提示通常已经足够，不需要公开整条订阅。若内容意外变成登录页面、错误页面或空文本，客户端可能报告解析失败；这不一定意味着协议不支持，而是请求拿到的内容根本不是预期的配置列表。

迁移客户端时，优先使用提供方明确支持的订阅格式，并选择一条代表性配置交叉核对。只对比条目数量不足以证明迁移完整，因为相同数量的记录也可能遗漏关键字段。批量导入后先验证一条，再确认不同协议和传输的代表条目。具体复制、添加订阅和更新操作见入门指南；格式差异与导入路径见分享链接与订阅地址的区别。只有字段被正确保留，后续性能与稳定性比较才有意义。

场景选型：建立最小配置与验证顺序

从约束条件筛选组合

面对现成服务，第一步不是评选协议，而是列出服务端提供的组合、设备平台和实际业务。桌面使用优先选择 v2rayN，再核对配置要求的内核与传输；Android 使用可从 v2rayNG 开始，需要 V2Fly 路线时再看 v2flyNG。如果服务端只提供一种完整且受支持的组合，客户端应按该组合配置，不必为了追逐另一个名称而改变认证或安全参数。若能够自行选择服务端方案，则应把维护能力和更新成本纳入决策。

需要频繁切换网络的移动使用，应关注重连与后台行为；长时间桌面传输，应关注吞吐稳定性和处理器负载；需要多个应用分别走不同出口，应关注路由表达和流量入口；涉及数据报业务，则先确认完整链路支持。协议负责的只是其中一部分。把所有需求都归入“哪种协议最快”，容易忽略真正的约束，例如应用根本不读取系统代理，或域名解析没有按预期进入分流逻辑。

先做一条最小可验证路径

首次验证时，只启用一条参数明确的远端配置，保持简单的路由模式，并让一个已知应用使用客户端入口。确认内核启动正常，再请求常用的普通网页，随后检查日志中的连接与出口。网页能打开只能证明该请求的路径可用，不代表所有应用、所有域名和全部数据类型都已经通过。接下来再逐步恢复规则、虚拟接口与其他功能，保证每增加一项都有可对照的结果。

路由问题可先用范围很小的规则验证语义。下面是一个 Xray 或 V2Ray 风格配置的路由片段，要求完整配置中已经存在标签为 direct 的直连出站；它不是可以单独启动的完整文件。示例只把保留示例域名的完整匹配交给该出口，其余请求仍按完整配置的其他规则或默认出口处理。客户端的图形路由编辑器可能使用另一种界面表达，不能把片段直接粘贴到分享链接输入框。

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

按失败阶段排查

若内核无法启动，先看字段、配置结构和内核支持，不必测试远端带宽。若域名解析失败，先检查地址拼写与解析路径。若连接超时，检查网络可达性、端口和服务端监听。若安全握手失败，检查系统时间、服务器名称、证书或公钥参数。若认证失败，检查用户标识、密码和双方协议。若连接成功但部分应用异常，检查入口模式、路由和数据报支持。这样的顺序能让每次修改都有明确目的。

恢复复杂分流时，需要理解规则通常按顺序匹配，前面的广泛规则可能遮蔽后面的精细规则。域名规则与地址规则能否命中，还受到解析策略和数据集的影响。不要把地域分类视为永远准确的业务分类，同一应用可能访问多个域名与地址段。应先确定希望走哪个出口，再核对实际命中的条件。相关原理与规则冲突的检查方法，可参阅geosite 与 geoip 分流配置思路。

保留回退点，再做长期调整

一次调整只改变一个层次：先换远端条目，或先改入口，或先换内核，不同时改动协议、路由与解析。记录原始配置来源、修改目的和观察结果，不记录可公开泄露的认证值。确认新组合稳定后再替换日常使用项，旧配置保留到新路径完成验证。升级后出现问题，也应优先回看变更边界，而不是重新导入所有订阅。日常操作回到快速上手主线，具体故障回到常见问题；本手册提供的是判断依据，不是替所有服务端规定同一套参数。