Shadowrocket 协议详解
类型选择与参数核对

先确认连接的两端

在 Shadowrocket 中选择协议，实质是让客户端使用服务端能够理解的通信格式。Type 不是速度档位，服务器提供 Shadowsocks 时，不能仅把客户端改成 Trojan 就获得另一种连接。地址、端口、身份凭据、加密方式和传输条件共同构成一个可用条目，缺少其中任何关键条件，都可能在连接建立之前失败。已有订阅通常能携带这些信息，但导入成功只表示资料被解析，不等于服务端当前可达。

理解连接时，可以把一次请求拆成三个对象：应用希望访问的目标、Shadowrocket 连接的服务器，以及把请求送往该服务器的本地网络。目标网站的 HTTPS 与客户端到服务器之间的 TLS 不是同一层。浏览器显示安全连接，只能说明目标连接中的证书验证结果，不能由此推断所选代理协议的外层也启用了加密。反过来，外层使用 TLS，也不能替代应用对目标证书的检查。

协议类型不等于承载方式

Shadowsocks、VMess、VLESS 和 Trojan 描述的核心机制并不相同；TCP、UDP 则是底层传输概念；WebSocket、HTTP/2、QUIC 又有各自的会话和封装方式。某个协议支持一种传输，不代表服务端已启用它，更不代表任意客户端组合都能互通。阅读资料时应把协议类型、传输类型、TLS 条件分别记录，不能把一长串名称理解成可以自由替换的同义词。

用完整任务衡量速度与电量

速度至少包含建立连接的等待、首个响应到达的时间、持续传输吞吐和中断后的恢复。一次轻量探测只覆盖其中一部分。TCP 建连快，不保证大文件传输快；下载吞吐高，也不保证频繁的小请求响应及时。移动设备还会受到无线信号、运营商调度、服务器负载与目标站点限制影响，因此本手册不按协议名称给出固定速度排名，也不把某次测试数字当作长期能力。

电量取决于完成同一任务所需的总工作量。加密计算、封装、重传、连接保活和无线模块唤醒都会消耗资源；网络信号很弱时，无线部分的开销可能比协议差异更明显。比较时应固定设备、网络、服务器与测试任务，观察一段时间的完成情况，而不是看连接开关打开后电池立刻变化。持续保活能够缩短部分恢复等待，却可能增加后台唤醒，这是需要按使用方式权衡的取舍。

路由则发生在另一条判断链上：即使服务器资料完全正确，请求也可能由 Direct 直接发出。排查前先确认 Global Routing 的姿态与实际规则命中，再讨论协议是否工作。配置、代理、直连分别对应界面中的 Config、Proxy、Direct；它们决定请求采用哪条路径，不会把服务器转换成另一种协议。

设计背景与主要取舍

Shadowsocks 的设计重点是提供相对轻量的加密代理转发机制，让客户端把目标请求封装后交给服务端，再由服务端连接目标。它不是完整的虚拟网卡协议，不负责为设备分配一整套远端局域网身份。对用户来说，最直接的配置通常是服务器地址、端口、加密方法和密码。字段数量看起来较少，但这并不意味着可以省略加密方法，或者把所有名称相近的实现都视作同一种兼容模式。

不同代际的方法有不同的密钥处理和数据格式。采用 AEAD 的方法会同时关注机密性与消息完整性，而较新的方法还可能改变密钥材料的格式与长度要求。因此，资料里的方法名称必须逐字对应客户端实际支持项。不要看到名称中都有 AES 就随意替换，也不要为了“更强”而换成服务端未配置的方法；两端格式不一致时，通常无法正确解释彼此发送的数据。

四个核心字段如何核对

Server 可以是域名或 IP 地址，填写的是代理服务器，不是希望访问的网站。Port 应使用该服务端提供的监听端口，而不是依据协议名称自行猜测。Method 指定双方约定的加密方法，Password 则必须保持原始内容。复制密码时要留意首尾空格、换行和相似字符；某些方法使用规定格式的密钥材料，不应先做一次自行编码，再把结果填入字段。

分享链接中的编码只是资料的表达方式，并不改变底层协议。链接可能把方法与凭据编码在一起，也可能带有附加参数。能从剪贴板解析出名称，不表示每个扩展参数都得到了完整还原。导入后应打开条目，重点核对 Type、Server、Port、Method 和 Password。若资料额外声明插件或特殊承载条件，还必须确认双方都支持；仅保留四个基础字段可能不足以复现原配置。

TCP 正常而 UDP 异常的原因

Shadowsocks 可以用于转发 TCP，也可以在匹配的实现与配置下处理 UDP。两条路径需要分别验证：服务端开放了 TCP 端口，不代表同一端口的 UDP 也已开放；网络允许网页请求，不代表允许所有 UDP 数据。出现网页可用而某些实时任务失败时，先确认任务实际使用的传输，再检查 UDP 条件，不要立即更换密码。DNS 的解析路径也可能与其他流量不同，应独立观察。

在 iOS 上，Shadowsocks 的资源表现会受所用方法、数据量和处理器能力影响。硬件对某些算法的加速可能降低计算开销，但这不是所有设备、所有方法都成立的结论。轻量封装有利于减少部分额外处理，却不能消除弱信号下的重传或服务端拥塞。如果任务持续传输，应比较完成同一文件所需的时间和稳定程度，而不是仅根据“层数少”推断一定更省电。

排错时先检查地址解析和端口可达，再核对方法与凭据。基础通信成功后仍有特定应用异常，应检查规则、DNS 与 UDP，而不是反复修改加密字段。一次只更改一个条件，并保留可工作的原条目，能够避免把路径故障和认证故障混在一起。

两个协议的职责并不相同

VMess 在协议中包含认证与数据保护机制，使用 UUID 等信息识别客户端，并存在不同代际的认证方式。VLESS 则采用更精简的协议结构，本身不提供与 VMess 相同的内建数据加密机制，通常需要依赖所配合的安全传输来保护客户端到服务端的通信。两者都可能出现 UUID 字段，但 UUID 相同并不意味着协议可以互换；Type 必须与服务端一致。

VLESS 的精简目标并不等于“任何情况下都比 VMess 快”。实际连接可能同时包含 TLS、不同传输、复用与服务端转发，最终开销由整个组合决定。VMess 的某些历史配置还涉及额外的兼容参数，已有资料如果保留这些信息，应按服务端实际要求核对，而不是套用某个统一数值。遇到不认识的字段时，先确认其适用代际，避免把旧参数强行加到新的认证方式里。

UUID、时间与安全层

UUID 是身份凭据，不是服务器地址，也不是任意备注。粘贴时应保持连字符和全部字符完整；若客户端自动规范大小写，不代表能够自动修复遗漏字符。对于依赖时间窗口的 VMess 认证，设备时间明显偏差可能导致认证失败，所以应先启用系统自动日期与时间。时间正确之后仍失败，再检查 UUID、协议代际及服务端状态，不能把所有认证异常都归结为网络不可达。

VLESS 配置中的 Encryption 若由资料指定为 none，不能直接理解为整个连接一定没有保护，也不能因此忽略外层 TLS。应分别检查协议层字段和安全传输字段。相反，如果外层并未建立安全通道，不能仅凭协议名称就认定内容受到同等保护。是否使用 TLS、采用何种服务端身份验证、是否存在特定 Flow，都是需要与原始资料逐项对应的条件。

WebSocket、Host 与 Path 的关系

当已有资料使用 WebSocket 时，客户端会先按对应的 HTTP 升级流程建立连接，再在其中承载协议数据。Path 是服务端或反向代理用于识别请求的路径，通常需要保留开头的斜杠以及大小写。Host 是 HTTP 请求语义中的主机信息，可能参与虚拟主机选择；它与实际连接地址可以不同，但这种不同必须有服务端配置依据，不能为了尝试连接随意填入一个常见域名。

SNI 则发生在 TLS 握手中，用于帮助服务端选择证书与站点配置。它和 WebSocket 的 Host 分属不同层，很多常见配置会使用相同域名，但并非一个字段自动代表另一个字段。若 Server 填写 IP，而证书签发给域名，通常仍需正确的服务端名称来完成身份核对。仅改 Host 而没有检查 SNI，可能让 HTTP 层正确、TLS 层却仍然失败。

在 iOS 上，外层 TLS 和承载层可能增加握手步骤；频繁重建短连接时，这些步骤更容易体现在等待上。连接复用可以减少部分重复建立的成本，也可能让多条请求共享同一传输连接，放大某些拥塞影响。没有固定最优开关，应以已有服务端的兼容条件为起点，再观察实际应用，而不是同时开启所有看起来能提速的选项。

导入长链接后，建议先截图之外另做字段文字记录，特别保存 Transport、TLS、Host、Path、SNI 与 Flow 的原始关系。订阅更新可能重新生成条目，直接修改订阅派生项未必会长期保留；需要实验时可复制为独立测试条目，并明确标记用途，避免下一次更新后误以为设置自行失效。

Trojan 为什么依赖 TLS 配置

Trojan 的基本设计是在 TLS 安全连接内完成认证和代理请求传递。TLS 承担客户端到服务端链路的加密与服务端身份验证，Password 用于协议认证，两者并不是互相替代的关系。密码正确但证书名称不匹配，连接仍可能在 TLS 阶段停止；证书完全正常但密码不正确，也可能在后续认证中失败。因此，检查时应先确认安全通道，再核对协议凭据。

Server 决定实际连接到哪里，SNI 提供 TLS 握手所需的服务端名称，证书则用来证明对端身份。若已有资料使用域名，通常应保留该域名，而不是随意换成解析得到的某个 IP。域名可能承担地址调度和证书识别作用，固定 IP 后即使暂时能连接，也可能在服务端迁移后失效。自有测试环境采用特殊证书时，应按明确的信任关系配置，而不是把跳过验证作为常规排错步骤。

HTTP 代理与 HTTPS 目标不是同一概念

HTTP 代理通常按请求目标转发 HTTP 流量，也可以通过 CONNECT 方法建立到目标的字节隧道。访问 HTTPS 网站时，常见方式是先向代理请求 CONNECT，再在隧道里与目标建立 TLS。这里的目标 TLS 与客户端到代理之间是否使用 TLS 是两回事。如果代理本身使用明文连接，不能因为目标网址以 HTTPS 开头，就认为代理认证信息所在的外层连接也获得了同样保护。

在 Shadowrocket 的条目中，Type、TLS 以及相关认证字段应按现有资料分别核对。Username 与 Password 可能属于代理身份认证，不应填成目标网站账号。传统 HTTP CONNECT 主要面向 TCP，不能由此推断任意 UDP 任务都会被代理。某些扩展机制能处理更丰富的流量，但只有客户端、服务端及配置都明确支持时才成立，普通 HTTP 代理资料不应默认具备这些能力。

SOCKS5 提供什么、不提供什么

SOCKS5 是面向通用代理请求的协商协议，可以表达连接目标、认证方式以及 UDP 关联等操作。它的基础协议本身不负责为数据提供加密。用户名与密码认证也不等于加密传输，选择它时需要明确所处网络和外层安全条件。适合受管理网络或已有明确用途的代理接入，不应把“通用”理解为能够自动适应任何服务器或者自动保护所有链路。

SOCKS5 的 UDP 转发还涉及 UDP ASSOCIATE、服务端返回的中继信息及后续数据路径。TCP 控制连接建立成功，并不能单独证明 UDP 中继可用。服务端权限、网络地址转换和端口放行都可能影响结果。域名由哪一侧解析也需要区分：请求携带域名与先在本地解析后提交 IP，会产生不同的解析路径；实际行为仍取决于客户端路由、DNS 配置与请求类型。

移动设备上的 TLS 握手需要网络往返和证书处理，已有连接的复用可以减少重复成本，但弱信号、频繁切换网络或服务端主动断开仍会触发重建。不能根据协议“看起来像普通 HTTPS”就断言电量更低。应比较同样任务下的连接完成率、后台恢复速度和设备温度变化，并排除屏幕亮度及应用自身活动的影响。

选型时无需把三种协议排成高低等级。已有服务端明确提供 Trojan，就完成 TLS 与密码的配套核对；已有受管理的 HTTP 或 SOCKS5 接口，就先确认权限、外层保护和目标流量范围。正确匹配服务端，比仅凭协议名字追求更复杂的组合更有意义。

从代理请求转向 IP 数据包

WireGuard 以加密 IP 隧道为主要模型，使用固定的现代密码算法组合和公钥身份，而不是让用户从大量加密方法中挑选。与以目标连接请求为中心的代理协议相比，它更接近把 IP 数据包交给指定对端处理。这样的模型适合已经部署相应网络、地址和路由的环境，但配置中必须同时考虑本地隧道地址、对端身份以及哪些目标允许通过隧道，不能只填一个服务器地址。

WireGuard 通常以 UDP 承载通信，避免把整个 IP 隧道固定包在一条可靠字节流里。协议的精简有助于降低部分实现复杂度，但在 Shadowrocket 中的实际性能还取决于客户端集成、系统网络扩展、服务器处理能力及网络路径。不能直接把其他操作环境中的测试结果搬到 iPhone，也不能仅凭算法固定就推导出所有任务都会比其他协议省电。

Private Key 与 Public Key 的对应关系

Private Key 属于本地身份秘密，不能放进公开截图、日志或求助消息。Public Key 用于识别对端，两端要建立正确的密钥对应关系：客户端保存服务端公钥，服务端登记客户端公钥。把两者填反，或者复制了另一台设备的配套资料，都会造成握手问题。Preshared Key 是可选的额外共享秘密，只有双方配置一致时才能使用，不能单边随意添加。

Address 是分配给隧道接口的地址，Endpoint 是实际联系对端的公网或可达地址与端口，二者用途完全不同。把隧道内部地址填到 Endpoint，通常无法从外部网络建立初始连接。IPv4 与 IPv6 也应分别核对；已有配置仅提供某一地址族时，不要为了补齐字段擅自编造另一组地址。DNS 配置则决定域名如何解析，不是用来替代 Endpoint 的地址栏。

Allowed IPs 不替代全局规则

Allowed IPs 在 WireGuard 模型中参与对等方的数据包范围判断，也常用于确定哪些目标应交给该对端。它并不等于 Shadowrocket 的全部规则系统。应用请求能否进入这一条目，还要看 Global Routing 与配置策略。若隧道握手正常但内网目标不可达，应同时检查目标地址是否属于允许范围、远端是否具备转发能力，以及返回路由是否知道如何回到客户端的隧道地址。

MTU 过大可能使某些较大的数据包在路径上无法顺利通过，出现小请求正常、加载较多内容却卡住的现象。调小 MTU 有时能帮助定位，但不是数值越小越好；过小会增加分包和处理开销。应先按已有配置使用，再在可复现的大包异常下小幅调整，并记录前后差异。若真正的问题是 DNS 或远端路由，改 MTU 通常不会产生稳定改善。

Persistent Keepalive 用于在需要时维持网络地址转换映射，常见于客户端位于 NAT 后而远端需要主动联系的情形。更频繁的保活会增加无线活动，可能影响移动设备待机电量；完全关闭也可能让闲置后的首次通信等待变长。是否需要保活，应由网络拓扑和使用需求决定，不应把某个间隔作为所有设备的固定推荐值。

排查 WireGuard 时，握手与有效数据必须分别看待。握手表示密钥和部分基础路径已经工作，不代表 DNS、Allowed IPs、远端转发和目标返回路径都正确。切换 Wi-Fi 与蜂窝网络后若恢复慢，可先观察对端更新和 UDP 可达性，再检查保活策略；避免在尚未确认身份字段时同时调整地址、路由与 MTU。

为什么采用 QUIC

Hysteria2 使用基于 QUIC 的传输，QUIC 运行在 UDP 之上，提供安全连接与多流等机制。它的设计关注有延迟、丢包或带宽变化的网络中的传输表现，并配合相应的拥塞控制策略。这里的 UDP 并不意味着把可靠性全部交给应用用户处理：QUIC 自身会完成需要的确认、丢包检测和重传。不能把“使用 UDP”简单理解为数据可以任意丢失，或者一定比 TCP 更快。

QUIC 的独立流机制能够减少不同流之间由可靠字节流顺序交付带来的部分阻塞，但同一流仍然存在顺序要求，所有流也仍受可用带宽与拥塞影响。如果本地网络限制 UDP，或者对 UDP 有严格的速率与映射规则，协议优势可能无法体现。服务端提供 Hysteria2 也不代表当前网络一定允许建立连接，首要检查仍然是端口、UDP 路径与身份参数。

认证、安全与附加条件

Server 与 Port 指向实际服务端，认证字段必须与现有资料保持一致。TLS 相关的服务端名称与证书验证仍需正确配置，不能因为底层是 QUIC 就省略身份核对。若资料中包含混淆条件，应同时核对是否启用及对应秘密；两端不一致时，通信可能在更早阶段就失败。不要把混淆密码、认证密码和证书名称互相代填，它们属于不同职责。

Hysteria2 与旧协议代际不能只靠名称接近就混用。导入后应查看 Type 是否正确，确认分享链接解析结果对应的是当前资料中的协议类型。服务端要求的 ALPN、证书条件或其他扩展如果没有在客户端中正确还原，也可能导致握手失败。遇到无法识别的链接，应先查阅资料来源的字段说明，而不是删除无法理解的参数后反复导入。

带宽参数不是速度承诺

部分配置会提供上行和下行带宽提示，用于影响特定拥塞控制模式的行为。它们表达的是算法参考条件，不是向网络申请带宽，也不是把数值调高就能得到对应吞吐。填写远高于实际链路能力的值，可能增加排队、丢包和重传，使交互请求反而更慢。填写过低也可能限制可利用的吞吐，因此应按客户端与服务端所用模式的含义核对，不能照抄另一条网络的数值。

单位同样重要。每秒兆比特与每秒兆字节不是同一个量，运营商标注的接入速率、系统下载显示和配置字段可能采用不同单位。还要区分上行与下行，移动网络往往并不对称。仅测一次下载峰值，不足以推断持续上行能力；若任务包含视频通话或文件上传，上行排队可能影响其他请求。调整前应先保存原始值，避免失去可以回退的基准。

iOS 上持续高吞吐会让无线与处理器保持活跃，基于 UDP 的传输、用户态处理和丢包恢复也会增加工作量。但更快完成同一任务，有时能缩短无线活动时间，因此不能只按瞬时功耗判断总能耗。应分别观察短任务、连续下载和后台待机，避免拿满速传输与空闲状态直接比较，再据此断定协议的电量表现。

若网络对 UDP 的支持不稳定，应保留已有的另一种可用组合用于核对，而不是反复提高带宽参数。网络路径不通、证书不匹配和算法参数不合适是三类问题，需要分层处理；先建立正确连接，再讨论吞吐优化，能够减少无效尝试。

用字段职责检查导入结果

订阅导入能减少手动填写，但不会消除核对的必要。建议按四组检查：地址组包含 Server 与 Port，身份组包含 Password、UUID 或密钥，承载组包含 Transport、Host 与 Path，安全组包含 TLS、SNI 与证书验证。不同协议不会同时出现所有字段，没有出现的项目不必为了“完整”而添加。字段名称相同也应按当前协议理解，尤其是 Password 与各类附加秘密不能混用。

地址里的域名可能先由本地 DNS 解析，也可能受客户端的 DNS 策略影响；目标网站域名又可能走另一条解析流程。服务器域名解析失败，会导致根本无法联系代理；目标域名解析异常，则可能表现为代理可连接但特定网站打不开。两种情况不能混为一谈。先确认失败对象是哪一个域名，再检查相应解析路径，比直接更换所有 DNS 设置更容易定位。

三种姿态决定请求是否经过条目

Global Routing 的 Config 按当前配置中的规则处理请求，Proxy 用于让可处理的请求采用代理路径，Direct 则采用直连路径。中文说明中的配置、代理、直连分别对应这些界面词。这里的“代理路径”仍然需要有效条目与策略选择，不是只切到 Proxy 就会自动找到服务器。Config 下请求可能被分流到 Direct，因此“网站能打开”本身不足以证明选中的协议已经参与通信。

规则一般按顺序匹配，较具体的条件应放在能够正确表达意图的位置。DOMAIN-SUFFIX 匹配域名后缀，GEOIP 根据地址归属数据库判断，IP-CIDR 匹配地址范围，FINAL 处理前面未命中的请求。域名规则与地址规则使用的信息不同，某些地址判断需要解析结果。数据库范围、IPv6、目标实际地址和解析时机都可能影响命中，不能把规则关键词当作协议字段。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

这段示例展示 Shadowrocket 配置中规则行的结构，不是可直接替换全部配置的成品。PROXY、DIRECT 是这里使用的策略标识，实际配置还需要有效的代理选择与其他必要部分。第一行让示例域名后缀采用代理策略，第二行给指定私有地址范围直连处理，第三行根据地址归属判断，最后一行提供兜底。不要把仅用于说明顺序的片段覆盖到尚未备份的个人配置。

配置文件与订阅资料各管一部分

订阅通常更新服务器条目，配置文件则可以承载规则与其他设置，两者不是同一种对象。已有订阅更新后条目可用，但 Config 仍指向旧策略，也会造成使用结果与预期不一致。相反，规则文件正确而条目凭据过期，同样无法代理请求。排查时分别记录“当前使用哪个条目”和“当前使用哪个配置”，不要只保存一个显示名称，因为相同名称可能被更新内容复用。

IPv6 需要特别留意。服务器域名可能同时返回 IPv4 和 IPv6 地址，目标网站也可能双栈可达。如果本地网络的某一地址族不完整，就可能出现时好时坏或部分目标等待很久。不要先把问题归因于协议不支持；应查看实际连接所选地址，分别验证两条路径。规则中的 IP-CIDR 与 IP-CIDR6 也应按地址族使用，不能期待一条 IPv4 范围规则同时覆盖 IPv6。

验证协议时应使用一个明确会进入该策略的测试请求，再结合连接记录确认路径。完成这一步后恢复日常 Config，并重新测试常用应用，避免把临时测试姿态误当成最终配置。协议连通只是基础，路由和解析正确才是完整的使用结果。

先列约束，再比较组合

选型的第一问不是“哪个协议最快”，而是已有服务端实际提供哪些完整组合。把可用协议、UDP 条件、证书要求和目标用途列出来，再排除不兼容的项。若只有一种明确可用配置，优先把它正确使用起来；若有多种组合，比较时尽量使用相同服务器区域、同一时间段与相同任务，避免把服务器性能差异误写成协议性能差异。

稳定 Wi-Fi 下的网页浏览通常更关注短请求、DNS 和连接建立，长时间文件传输更关注持续吞吐与拥塞；频繁切换 Wi-Fi 与蜂窝网络时，要关注恢复所需时间和应用是否能重新建立连接；访问已有内部网络时，还需要考虑地址规划、返回路由与权限。WireGuard 的 IP 隧道模型、通用代理的请求模型和 QUIC 的传输特点各有适用条件，不应只按名称进行统一排名。

按六个阶段缩小故障范围

第一阶段检查本地基础网络。在 Direct 下确认网络本身具备必要的连接能力，查看是否存在需要完成的网络登录。第二阶段检查 Server 的域名解析与端口条件，尤其区分 TCP 与 UDP。若服务器根本无法联系，修改 UUID、Password 或规则顺序通常不会改善。此时应保留错误现象，并在另一个已知可用网络做对照，而不是连续尝试大量字段组合。

第三阶段检查 TLS 与证书，包括系统时间、SNI、证书域名及证书链。第四阶段检查协议认证，按 Type 分别核对方法、密码、UUID 或密钥配对。握手错误与认证错误可能在界面上都表现为连接失败，因此要结合日志中明确的阶段信息判断；日志没有给出足够证据时，应说明不确定性，不要仅凭“超时”就认定密码一定正确或一定错误。

第五阶段检查路由和 DNS。确认测试请求进入所选策略，目标域名能够得到合理结果，相关地址族也可用。第六阶段再检查持续传输问题，例如 MTU、UDP 中继、拥塞参数、服务端负载或大流量限制。只有在前面阶段通过后，调整性能字段才有可解释的意义。若小请求正常、大请求失败，要尝试可复现任务，而不是只重复一次 Connectivity Test。

怎样做有意义的电量与速度对照

同一设备保持相近信号条件，关闭与测试无关的大流量任务，分别完成相同网页集合或相同大小的文件传输。记录任务开始到完成的时间、失败次数、切换网络后的恢复，以及系统电池统计中的一段时间变化。不要用不同亮度、不同信号和不同前台应用的结果比较协议。瞬间温度变化和单次电量百分比跳动都可能有其他原因，需要重复观察才有参考价值。

对待 On Demand 也应区分“按条件触发连接”与“保证所有应用始终保持会话”。系统切换网络、应用暂停、远端关闭连接都可能触发新的建立过程。更频繁保活能改善某些闲置恢复，却可能增加待机活动；长连接复用减少部分握手，但也可能让多个请求共享一条拥塞路径。先按原配置运行，只有出现明确、可重复的问题时才改变这些条件。

最终保留一份已验证可用的基准配置，再逐项尝试优化。协议参数需要回到本页对应章节核对，首次连接流程回到使用说明，重复出现的使用问题查疑难解答，获取与首次安装问题查安装放行说明。正确的结论通常是“这组配置在这个网络下完成了这个任务”，而不是给所有设备和网络指定一个永久最优协议。