外观
流量特征与识别：协议伪装的原理与边界
代理流量可能被识别，是因为加密保护的是内容而不是形态：一条连接的目标地址、握手阶段的明文字段、数据包长度序列、时间间隔与总量，都是观察者不需要解密就能看到的特征。
协议伪装的目标是让这些可观察特征与常见应用（主要是浏览器访问网站）一致，它在握手层面可以做到相当接近，但无法改变连接的宏观行为——目标地址的信誉、长时间大流量的单一连接、与同网络其他用户不同的访问模式。理解这个边界，是看懂协议标注、解释节点表现波动的前提。
核心结论与适用条件
- 如果你想知道“为什么加密了还会被识别”，答案是识别依据的是形态特征而不是内容，加密与识别处理的是两个不同层面的问题。
- 如果你想知道协议伪装能做到什么，答案是它能处理握手层面的特征（证书、指纹、嵌套 TLS 模式、对主动探测的回应），处理不了行为层面的特征（流量总量、持续时间、目标地址信誉）。
- 如果你在比较品牌的协议标注，需要知道协议名称只反映内层封装，决定可观察特征的是传输层方案，而本站所有标注 VLESS 的品牌都没有写明传输方案，待核实。
- 如果你在解释某个节点为什么时好时坏，流量分类是可能原因之一，但线路拥塞与服务端负载同样可能，不应把所有波动都归结为识别。
- 本文只讨论公认的通用原理，用于理解协议设计与形成合理预期，不涉及任何具体网络的策略，也不提供任何针对性的操作方法。
本文是协议与安全专题中偏认知的一篇，它为协议选择文章提供背景：为什么协议不是越新越好、传输方案为什么比协议名称更重要，可以在读完本文后转到协议选择文章看具体的判断框架。专题总览见回到协议与安全专题查看两个集群的分工。
观察者的视角：不解密能看到什么
讨论流量识别，先要换到观察者的位置。观察者是任何处于你与服务端之间、能看到数据包经过的设备：家庭路由器、运营商的网络设备、企业网关、各类流量管理与安全设备。它们对流量做分类的用途很多——带宽管理、QoS 优先级、安全策略、计费——分类本身是网络运营的常规组成部分。
一个不持有密钥的观察者，对一条加密连接能看到以下几类信息。
| 指标 | 具体内容 | 是否需要解密 | 伪装能否处理 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|---|
| 网络层 | 源与目标 IP 地址、端口、传输协议（TCP/UDP） | 否 | 部分：端口可选，地址信誉无法改变 | — | 协议栈公开结构 | 通用技术资料 | 2026-10-18 |
| 握手明文 | TLS 客户端握手中的服务器名（SNI）、支持的加密套件与扩展列表、ALPN | 否 | 可以：服务器名可选，指纹可模拟 | — | 协议栈公开结构 | 通用技术资料 | 2026-10-18 |
| 服务端证书 | 证书中的域名、签发机构、有效期（较旧 TLS 版本中明文传递） | 否 | 可以：使用真实域名证书或借用真实网站 | — | 协议栈公开结构 | 通用技术资料 | 2026-10-18 |
| 包长序列 | 握手阶段与数据阶段每个数据包的长度及其变化模式 | 否 | 部分：握手阶段可处理，数据阶段受限 | — | 被动观测可得 | 通用技术资料 | 2026-10-18 |
| 时序 | 包间隔、连接建立到首个数据的时间、往返节奏 | 否 | 有限：受应用行为与线路决定 | — | 被动观测可得 | 通用技术资料 | 2026-10-18 |
| 连接宏观行为 | 持续时间、总流量、并发连接数、单连接内多目标复用 | 否 | 基本不能：由使用方式决定 | — | 被动观测可得 | 通用技术资料 | 2026-10-18 |
| 对探测的回应 | 服务端对非协议格式输入、重放输入的反应 | 否（主动） | 可以：转交真实网站回应 | — | 主动探测可得 | 通用技术资料 | 2026-10-18 |
| 载荷内容 | 应用层数据本身 | 是 | 不适用：正确实现的 TLS 下不可读 | — | 需密钥 | 通用技术资料 | 2026-10-18 |
表中“伪装能否处理”一列是本文的核心。它显示伪装能力从上到下递减：越靠近握手层面，协议设计越有发挥空间；越靠近行为层面，越取决于用户怎么用、线路什么状态，协议设计无能为力。
两个容易混淆的概念：识别与解密
识别是对连接做分类，输出“这像什么”；解密是读取内容，输出“这是什么”。正确实现的 TLS 之下，不持有密钥的观察者做不到后者。两者的后果也不同：解密意味着内容泄露；识别意味着连接可能被区别对待——限速、中断、记录。
这个区分决定了安全工作的优先级。内容泄露的真正风险来自别的环节：关闭证书校验让中间设备得以冒充服务端、DNS 请求绕过代理直接暴露访问的域名、客户端本身被篡改。这三项处理不好，再精巧的伪装也没有意义，因为数据在伪装之前就已经漏出去了。
特征是如何产生的：三类典型模式
模式一：缺少外层的加密流
早期的代理协议直接在 TCP 上传输加密后的数据，没有 TLS 握手。这类流的特征是：从第一个字节开始就是高熵的随机数据，没有任何可识别的协议头。问题在于“没有协议头”本身就是一种特征——几乎所有正常的互联网应用在连接开始时都有可识别的明文协商阶段，一条从头到尾全是随机字节的连接，在统计上与它们不同。这类协议后来普遍加上了混淆层，把流量包装成 HTTP 或 TLS 的样子，但包装的保真度取决于实现。
模式二：TLS 中的 TLS
当代理用 TLS 封装用户流量，而用户访问的网站本身也用 TLS 时，外层加密里面还有一层完整的 TLS 握手。内层握手的数据包长度序列有相对固定的模式：客户端握手包、服务端证书与密钥交换包、完成消息，各自的长度范围与先后顺序在不同网站间差别不大。外层加密不改变这些包的长度（只增加固定的开销），因此从外层包长变化中可以辨认内层握手的存在。
普通浏览器访问网站时不会出现这种嵌套结构，所以它成为区分代理连接与直接连接的一个依据。XTLS Vision 这类流控方案的设计目标之一正是改变这一模式：对内层 TLS 握手做填充使长度模式不再规律，并在内层握手完成后让加密数据直接通过而不再二次加密——后者同时减少了重复加密的开销。其原理见了解 XTLS Vision 流控如何处理嵌套 TLS 的问题。
模式三：握手不像浏览器
即使没有嵌套结构，TLS 客户端握手本身也携带指纹。握手包中列出的加密套件顺序、扩展类型与顺序、支持的协议版本，由客户端使用的 TLS 库决定。主流浏览器的 TLS 库各有特定的组合，而代理客户端常用的编程语言自带 TLS 库产生的组合与任何浏览器都不同。观察者比对这个组合，就能区分“浏览器在访问网站”与“某个非浏览器程序在访问网站”。uTLS 一类的库通过模拟主流浏览器的握手组合来处理这个问题，详细讨论见理解 TLS 指纹为什么会影响连接以及 uTLS 的作用。
模式四：对主动探测的回应
前三种模式都是被动观察。观察者还可以主动出手：向可疑的服务端发起连接，发送不符合协议格式的数据，看它怎么回应。一个真实的网站服务器会返回 HTTP 错误页或按 TLS 规范中止连接；一个只接受特定协议的代理服务端可能直接断开、超时、或返回某种特定的响应。不同实现的反应不同，反应本身就成为识别依据。
REALITY 对此的处理方式是：服务端在收到握手时先验证客户端是否持有正确的密钥，持有则进入代理逻辑；不持有（包括探测者）则把连接完整地转交给一个真实的第三方网站，由它来完成握手与回应。探测者看到的是一个真实网站的真实行为，而且证书也是那个网站的真实证书。其机制见理解 REALITY 如何借用真实网站的握手与证书。
伪装的边界：什么是设计无法改变的
把上述四种模式都处理好之后，一条代理连接在握手层面可以与浏览器访问某个真实网站高度一致。但观察者还有一类依据，与握手无关。
行为特征
浏览器访问网站的行为有典型模式：连接数多、每条连接短、流量集中在页面加载的几秒内、目标分散。代理连接的行为则由用户的实际使用决定：如果用户在看长视频，就是一条持续数十分钟、流量稳定的大连接；如果用户在用多个应用，就是一条连接内复用了大量不同目标的流量。这些行为特征与“访问某个网站”的典型模式不符，而协议设计无法改变它们——它们是用户在做什么的直接反映。
地址信誉
伪装可以让握手像某个网站，但服务端的 IP 地址是固定的。一个地址如果长期承载大量用户、呈现出不像网站的宏观流量模式，地址本身就会积累特征。这与协议无关，与线路、与服务端部署方式有关。为什么同一品牌不同节点表现不同、为什么节点地址会更换，部分原因在此。相关的线路侧因素见了解中转架构如何影响落地地址的暴露面。
统计层面的不一致
即使单条连接处理得很好，一个用户所有连接的集合仍可能与同网络其他用户不同：长期只访问一两个目标地址、所有流量都走 TLS 且目标集中、几乎没有 DNS 查询（因为解析走了远程）。这些是群体统计层面的差异，单个协议设计无法覆盖。
边界的意义
认识边界不是为了悲观，而是为了形成合理预期。伪装能做的是消除“明显的、设计层面的”差异，让分类设备在握手层面没有简单依据；它做不到的是让一条承载全部流量的长连接看起来像在刷网页。因此协议与传输方案是选型中的一个维度，不是全部；把所有希望寄托在“更新的协议”上，与把所有希望寄托在“更贵的线路”上一样片面。协议选择的完整框架见看协议选择文章中“为什么不是越新越好”的讨论。
这如何解释节点表现的波动
用户最常见的疑问是：同一个节点，为什么昨天好今天差、在家好在外差、晚上差白天好。流量识别是可能的原因之一，但要与其他原因区分。
| 现象 | 识别相关的可能解释 | 非识别的可能解释 | 区分方法 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|---|
| 同节点在不同接入网络表现不同 | 不同网络的分类设备与策略不同 | 不同网络到入口的路由与拥塞不同 | 同时段切换网络对比；多节点对比 | — | 排查逻辑归纳 | 通用技术资料 | 2026-10-18 |
| 晚高峰变差 | 策略在高峰时段收紧 | 线路与服务端在高峰拥塞（更常见） | 看同品牌其他节点是否同步变差 | — | 排查逻辑归纳 | 通用技术资料 | 2026-10-18 |
| 连接能建立但很快中断 | 握手通过但行为特征触发处理 | 服务端负载、客户端保活设置 | 换传输方案节点对比；看中断是否有规律 | — | 排查逻辑归纳 | 通用技术资料 | 2026-10-18 |
| 握手阶段直接失败 | 握手特征触发处理 | 证书、服务器名、系统时间问题 | 先按证书排错流程排除配置原因 | — | 排查逻辑归纳 | 通用技术资料 | 2026-10-18 |
| 特定目标变慢而其他目标正常 | 通常与识别无关 | 目标站点自身、落地地址对该站点的表现 | 换落地地区节点对比 | — | 排查逻辑归纳 | 通用技术资料 | 2026-10-18 |
| 所有节点同时不可用 | 地址段或品牌级别的处理 | 品牌服务端故障、订阅失效 | 查品牌公告；看订阅是否能正常更新 | — | 排查逻辑归纳 | 通用技术资料 | 2026-10-18 |
表中“更常见”一词是对一般经验的归纳，不是对任何品牌或网络的判断。实际排查时，先排除配置与线路原因，再考虑识别原因，因为前者可以由用户直接验证，后者只能间接推断。线路侧的波动机制见了解晚高峰拥塞与 QoS 对节点表现的影响。
为什么“识别”不应成为万能解释
把所有问题归结为“被识别了”有一个实际危害：它让用户放弃排查。证书没配对、服务器名填错、客户端内核不支持某传输方案、系统时间不准——这些都会表现为“连不上”，而且都能自己解决。节点质量下降也可能是品牌运维层面的问题，与识别无关，相关信号见观察节点质量下降的早期信号。先走完可验证的排查，再把剩余的归入不可验证的原因，是更有效率的顺序。
决策树：怎样把协议标注翻译成特征处理能力
Decision Path
从品牌标注推断可观察特征的处理情况
text
品牌资料中的协议标注是什么？
├─ 待核实（本站 5 个品牌）
│ └─ 无法推断任何特征处理情况 → 向客服确认协议与传输方案后再判断
├─ Shadowsocks / VMess（本站无品牌标注）
│ └─ 自带加密，外层是否有 TLS 或混淆插件？
│ ├─ 无 → 模式一：高熵流，无握手特征处理
│ └─ 有 → 取决于插件实现的保真度
└─ VLESS（本站 12 个品牌）
└─ 传输方案字段（订阅中查看）？
├─ 待核实（资料中全部如此）→ 导入订阅后查看节点字段
├─ tls（普通）
│ ├─ 处理：模式四以外的证书层面
│ ├─ 未处理：模式二（嵌套 TLS）、模式三（取决于客户端指纹选项）
│ └─ 行为特征：不处理
├─ tls + XTLS Vision
│ ├─ 处理：模式二
│ ├─ 模式三取决于客户端指纹选项
│ └─ 行为特征：不处理
└─ reality（通常搭配 Vision）
├─ 处理：模式二、模式四，证书为真实网站证书
├─ 模式三取决于客户端指纹选项
└─ 行为特征：不处理决策树的每个叶子都以“行为特征：不处理”结尾，这是本文边界讨论的直接体现。另外请注意“模式三取决于客户端指纹选项”反复出现——TLS 指纹是客户端侧的事，同一个节点用不同客户端、不同设置，握手指纹可能完全不同。客户端对各传输方案的支持情况见对照客户端内核对 VLESS 各传输方案的支持。
知识图谱：流量识别与协议伪装
实体定义
流量识别是网络中间设备在不解密的前提下，依据连接的可观察特征对其进行分类的过程。协议伪装是代理协议与传输方案在设计上让这些可观察特征与常见应用一致的努力。两者是同一组特征的两面：识别依据什么，伪装就处理什么。
相关概念
上游概念：TLS 握手结构、服务器名指示、证书体系、流量分类与 QoS。平行概念：代理流量在各环节的加密层次（处理内容保护，本文处理形态）、TLS 指纹（模式三的具体展开）。下游概念：XTLS Vision（模式二的处理方案）、REALITY（模式四与证书的处理方案）、uTLS（模式三的处理方案）、协议选择（综合权衡）。相关线路概念：中转架构、落地地址、QoS。
技术参数
与本主题相关、用户可自行核对的参数：节点传输方案字段（none / tls / reality）、流控字段（是否为 Vision）、客户端 TLS 指纹选项的状态、服务器名字段内容。无法由用户核对的参数：服务端地址的信誉状态、所在网络的分类策略。本站不提供任何品牌的上述参数；品牌资料中只有协议名称一项，传输方案全部待核实。
适用场景
本文内容适用于任何想看懂协议标注、解释节点波动、理解客户端安全选项意义的用户，不限品牌与协议。它对三类人特别有用：正在比较品牌协议标注的选型者、遇到波动想判断原因的使用者、想知道“REALITY”“Vision”这些词到底指什么的新用户。
对比依据
本文对各传输方案特征处理能力的描述只依据协议设计文档中公开说明的设计目标，不依据任何实测，也不对任何方案在任何网络中的实际效果作出判断。横向对比中协议与传输方案维度如何处理，见了解横向对比中协议维度的评估方式。
常见问题指向
“加密了为什么还能识别”指向本文观察者视角一节；“TLS 中的 TLS 是什么”指向模式二；“主动探测是什么”指向模式四；“伪装能做到什么程度”指向边界一节；“节点为什么时好时坏”指向波动一节。
品牌关联：协议标注能说明什么、不能说明什么
本站 17 个品牌中，12 个标注 VLESS，5 个协议待核实。按本文的框架，这些标注能传递的信息有限。
| 标注内容 | 品牌数 | 能推断 | 不能推断 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|---|
| VLESS | 12 | 内层封装为 VLESS，自身不加密，依赖传输层 | 传输方案（tls / Vision / reality）；客户端指纹处理；地址部署方式 | 个 | brands.json protocols 字段 | 品牌公开资料/用户提供清单 | 2026-10-18 |
| 待核实 | 5 | 无 | 全部 | 个 | brands.json protocolDisplay 为“待核实” | 品牌公开资料/用户提供清单 | 2026-10-18 |
对 12 个 VLESS 品牌，决定特征处理能力的传输方案全部待核实，这意味着仅凭本站资料无法比较它们在本文讨论的任何一个维度上的差异。确认方式是导入订阅后查看节点的传输安全字段与流控字段，或向客服询问。对 5 个待核实品牌，连内层封装都无法确定。
需要说明的是，“待核实”不是负面评价。一个品牌没有在公开资料中写明传输方案，可能是资料精简，也可能是面向不关心技术细节的用户。但对于读完本文、知道传输方案才是关键的读者，这一字段应当在付费前确认。确认待核实字段的一般方法见学习处理资料中待核实字段的流程；品牌的协议字段可在品牌库中按协议筛选查看。
5 个协议待核实的品牌中，灵猫网络与星岛梦标注的线路为企业级内网专线、仅支持第三方客户端导入，这意味着用户在确认协议前无法知道自己的客户端能否使用。相关详情见查看灵猫网络的线路与客户端标注。
Infrastructure Service Snapshot
唯兔云 /weituyun
- 入门价格
- 14.9 元/月
- 价格类型
- 月付 月付价
- 入门流量
- 100GB
- 线路
- 60+节点、三网优化、智能负载均衡
- 协议
- VLESS
- 运营年份
- 2023
- 客户端
- 根据官方订阅格式使用对应客户端
- 支付方式
- 支付宝 / 微信 / USDT
所有品牌均为 Vendor Data。本站未查看任何品牌的订阅内容，未对任何品牌的节点做任何形式的特征观察或测试。
优点、限制与风险提示
理解流量识别原理的优点
- 能把协议标注翻译成具体的特征处理能力，不被名词误导，也不会因为某品牌没有标注某个名词就直接否定它。
- 在节点表现波动时有一个排查框架，先处理可验证的配置与线路原因，再考虑不可验证的原因。
- 理解客户端中 TLS 指纹、传输方案这些选项为什么存在，从而愿意去检查它们。
本文内容的限制
- 本文只描述协议设计文档中公开说明的设计目标，不对任何方案在任何网络中的实际效果作判断；设计目标与实际效果之间的差距取决于实现质量与网络环境，本站无法评估。
风险提示
- 把“被识别”当成万能解释会让用户放弃排查，错过那些可以自己解决的配置问题。
- 协议与传输方案只是选型的一个维度；线路质量、运营主体、付费周期对使用体验的影响可能更大。选型时如何在多个维度之间分配权重，见回到选型框架看协议维度在清单中的位置。
- 内容泄露的风险不来自识别，而来自证书校验、DNS、客户端来源三个环节；在关心伪装之前，应先确认这三项已经处理。客户端层面的检查入口见从客户端专题进入各平台的安全设置项。
常见问题
流量已经加密了，为什么还能被识别？
加密保护的是内容，不是形态。一条加密连接仍然暴露目标地址与端口、握手阶段的明文字段、每个数据包的长度、包与包之间的时间间隔、连接持续时间与总量。流量分类设备正是依据这些不需要解密就能观察到的特征来判断一条连接“像什么”。加密让内容不可读，但没有让连接不可见。
流量识别和解密是一回事吗？
不是。解密需要密钥，在正确实现的 TLS 下中间设备做不到。识别是在不解密的前提下对连接做分类，输出的是“这条连接属于哪一类”的判断，而不是连接的内容。两者的后果也不同：解密意味着内容泄露，识别意味着连接可能被区别对待，例如限速、中断或记录。
什么是 TLS 中的 TLS，它为什么是一个特征？
当代理用 TLS 封装用户流量，而用户访问的网站本身也用 TLS 时，外层加密里面还有一层完整的 TLS 握手。内层握手的数据包长度序列有相对固定的模式，在外层加密后仍然可以从包长变化中辨认出来。普通浏览器访问网站时不会出现这种嵌套结构，因此它成为区分代理连接与普通连接的一个依据。XTLS Vision 这类流控方案的设计目标之一就是改变这种模式。
主动探测是什么意思？
指观察者不满足于被动看流量，而是自己向可疑的服务端发起连接，看它如何回应。例如发送一个不符合协议格式的请求，看服务端是返回正常网站的响应、断开连接、还是出现某种特定的错误行为。不同实现对异常输入的反应不同，这些反应差异本身就是识别依据。REALITY 的设计把这类探测转交给一个真实网站来回应。
协议伪装到底能做到什么程度？
它能在握手层面让连接的可观察特征与常见应用一致：使用真实域名的证书或借用真实网站的握手、让客户端握手指纹与主流浏览器一致、消除嵌套 TLS 的长度模式。它做不到的是改变连接的宏观行为：目标地址的信誉、长时间大流量的单一连接、与所在网络中其他用户明显不同的访问模式。伪装处理的是“像不像”，处理不了“合理不合理”。
为什么同一个节点在不同网络、不同时段表现不一样？
因为流量分类不是一个全局统一的开关，而是分布在不同网络的不同设备上，各自的规则、更新频率与处理方式都不同。同一条连接在家庭宽带、移动网络、企业网络下遇到的分类设备不同；同一网络在不同时段的策略也可能变化。这是节点表现波动的原因之一，但不是唯一原因，线路拥塞、服务端负载同样会造成波动。
协议名称能告诉我伪装程度吗？
只能告诉一部分。协议名称（VLESS、Trojan、Shadowsocks）决定了内层封装方式，而可观察特征主要由传输层方案决定：是否使用 TLS、使用哪种 TLS 变体（普通 TLS、XTLS Vision、REALITY）、客户端是否模拟浏览器指纹。本站 12 个标注 VLESS 的品牌都没有写明传输方案，这一项待核实，而它恰恰是决定特征表现的关键。
伪装得更好的协议一定更稳定吗？
不一定。伪装处理的是被分类的风险，而稳定性还取决于线路质量、服务端负载、客户端实现的成熟度。一个使用较新传输方案但线路拥塞的节点，体验可能不如一个使用普通 TLS 但线路充裕的节点。另外较新方案对客户端内核的要求更高，兼容性问题本身也会表现为“不稳定”。
作为普通用户，了解流量识别有什么实际用处？
三个用处。一是看懂品牌的协议与传输方案标注，知道它们分别对应什么特征处理能力，不被名词误导；二是在节点表现波动时能区分可能的原因，而不是一律归结为品牌不行；三是理解为什么客户端的 TLS 指纹选项、传输方案字段这些设置值得检查。它不是用来对抗任何人的知识，而是用来做出合理选择与合理预期的知识。
流量识别会导致我的数据泄露吗？
识别本身不会导致内容泄露，因为它不涉及解密。但识别的结果可能带来其他后果：连接被限速或中断是最常见的；连接被记录是另一种可能。内容泄露的风险来自别的环节，例如关闭证书校验、DNS 请求绕过代理、客户端被篡改，这些才是需要优先处理的泄露路径。
Cluster · security
安全与隐私
- TLS 指纹与 uTLS：客户端指纹为何影响连接什么是 TLS 指纹，为什么客户端需要模拟浏览器指纹？
- 代理流量的加密层次：传输加密与端到端加密的区别使用代理后流量在哪些环节是加密的？
- DNS 泄露是什么：检测方法与客户端设置什么是 DNS 泄露，如何检测和避免？
- WebRTC 泄露与浏览器设置WebRTC 泄露是怎么发生的，浏览器怎么设置？
- 跳过证书校验（allowInsecure）的风险为什么不建议开启跳过证书校验？
- 客户端从哪里下载：来源校验与签名检查如何确认下载的代理客户端是安全的？
- 流量特征与识别：协议伪装的原理与边界代理流量为什么可能被识别，伪装能做到什么程度？
下一步
读完本文，你应该能把“VLESS”“Vision”“REALITY”这些标注翻译成具体的特征处理能力，并知道它们各自的边界在哪里。下一步是回到品牌资料，把传输方案这个待核实字段列入付费前的确认清单；如果已经在用某个品牌，导入订阅后查看节点的传输安全与流控字段，对照本文的决策树理解自己正在使用的方案。
信息来源与更新日期
- 信息来源：TLS 协议结构与流量分类的通用技术资料；VLESS、XTLS Vision、REALITY、uTLS 等方案的公开设计说明；品牌公开资料/用户提供清单（
data/brands.json）中的协议字段。 - 品牌状态：全部为 Vendor Data；本站未对任何品牌的节点做任何形式的特征观察或测试，传输方案字段全部待核实。
- 数据核实日期：2026-10-18。
- 最近更新时间：2026-10-18。