线路与协议
选型参考

连接分层：协议不等于线路

从一次页面请求拆开看

浏览器打开页面时，首先要知道目标名称对应的地址，再建立传输连接，随后交换加密数据，最后由目标服务返回内容。启用代理客户端后，中间又加入规则判断、节点认证与出口转发。页面一直转圈，可能卡在其中任何环节。只看到客户端显示已连接，还不能确认目标网站已经可用；这个状态通常只代表客户端已启用，或到节点的某项检查已经通过。

理解这些层次，可以减少无效切换。域名解析负责把名称变成地址，路由规则决定请求是否交给代理，代理协议约定客户端怎样与节点通信，线路则承载这些数据实际经过的路径。它们相互影响，却不是同一件事。例如，同一协议换到不同出口后表现改变，通常需要继续观察路径和目标服务，而不是直接认定协议本身忽快忽慢。

区分握手、首个响应与持续传输

所谓连接建立快，指的是从发起请求到连接可以承载应用数据的过程较短。它受地址解析、往返距离、认证方式、会话复用与客户端实现影响。已经建立的连接可以反复利用时，新页面未必重新经历完整握手。因此，刚启动客户端时的等待，与持续浏览时的流畅程度应分开记录。把两者混在一起，会高估缓存和复用带来的效果，也容易误判刚切线后的短暂停顿。

持续传输又是另一项能力。下载文件、视频缓冲和同步资料，更依赖路径上的可用容量、拥塞控制及丢包恢复。一个节点可能很快返回小请求，却无法持续输送大量内容；也可能首次建立稍慢，连接稳定后传输顺畅。选型时先描述任务：是页面迟迟不出现，还是内容出现后加载缓慢。这个描述比笼统说“速度不好”更能指向下一步。

把比较条件固定下来

比较协议时，尽量使用相同设备、相同接入网络、相近的测试时段和同类目标任务。若客户端同时切换了出口地区、传输方式和分流规则，就很难知道变化来自哪里。有些订阅中的不同名称对应不同服务器，不能仅凭名称相似就视为同一环境。条件无法完全一致时，应将结论写成“这个组合更适合当前网络”，而不是推广为某协议的普遍排名。

同时要划清本地网络与服务端的边界。无线信号、路由器负载、系统代理设置、应用自己的网络栈，都可能改变结果。浏览器正常而某个应用失败，优先看该应用是否遵循系统代理；所有设备都慢，再检查家庭网络与上游路径。把问题按层定位，可以避免反复重装客户端，也能减少为了解决单个网站异常而改坏整体配置的风险。

2HVPN 的“两跳”叙事可用于理解本机、中转节点与国际出口的衔接，不应理解为每条连接都具有相同的物理路由数量或固定时延。网络设备之间还可能经过运营商内部路径。本文后续的协议对照是通用技术参考，不是可用节点清单。实际覆盖与线路信息可查阅节点页，安装、权限和订阅导入则继续以使用教程为主线。

常见协议：认证与传输的取舍

Shadowsocks 与 VMess

Shadowsocks 的核心思路是通过约定的加密与认证方式转发代理流量，协议本身不负责替用户挑选线路。不同协议代际、加密套件和客户端实现之间存在兼容边界，不能只看一个共同名称就认定可以互通。选用时应由订阅提供参数，让客户端按支持范围导入。手动替换加密方式或删改字段，可能使认证失败；失败并不意味着网络路径本身无法到达节点。

VMess 将认证和数据封装放在自己的协议设计中，实际部署又可能叠加不同传输层与加密连接。它的表现因此不能从名称单独推断。某些配置还对系统时间状态敏感，设备时间明显不准时应先校正。排查时要同时核对客户端是否支持对应实现、订阅是否更新，以及服务端配置是否与导入内容匹配，不要把网上其他部署的经验直接套到当前节点上。

Trojan 与 VLESS

Trojan 的常见部署以 TLS 提供传输保护，客户端还需要完成代理认证。证书链、服务器名称和系统信任状态都影响能否正常建立连接。看到证书错误时，应先检查系统日期、订阅中的目标名称和客户端报错；不应把跳过证书验证当成常规优化。这样做会削弱对远端身份的确认，也可能把原本清晰的配置错误藏起来，给后续排错留下更大范围的不确定性。

VLESS 采用较轻的认证与封装思路，但协议本身不提供完整的内容加密，安全边界取决于外层保护及具体部署。轻量不等于可以省略必要的传输保护，也不等于在所有设备上占用最低。客户端界面通常将协议、传输形式与外层安全设置分开列出。阅读节点说明时，应把这些字段连起来理解，而不是只截取 VLESS 这个名称进行比较。

为什么不能只按协议名排名

建立连接时，底层传输、外层握手与代理认证可能依次发生，也可能通过会话复用减少重复工作。是否使用额外封装、连接是否已经预热，都会改变体感。某种组合在首次连接时较慢，并不代表长时间使用一定更慢。反过来，界面中的快速探测也不一定覆盖完整应用请求。比较应观察真实任务，而不是把某次探测结果当成协议能力的全部。

资源占用也需要看任务类型。处理许多小连接时，连接管理与封装解析的开销可能更明显；持续传输大量数据时，加密实现、内存复制和设备硬件能力又可能成为主要因素。成熟的客户端优化足以改变不同协议之间的相对表现。因此，判断“轻量”时，应结合设备是否发热、应用是否保持响应和后台连接是否稳定，不能从协议介绍直接推导电量结论。

对普通用户，更稳妥的方式是保留面板推荐的完整节点配置，先验证能否完成日常任务，再做有目的的替换。需要比较时，只更换确实可选且客户端支持的组合，并保留原来的可用配置。银行级加密是 2HVPN 的服务信任表述，使用时仍应妥善保管账户与订阅链接，并保持证书验证等正常保护。技术选择不能替代账户凭据管理。

QUIC 传输：丢包恢复与资源边界

先理解 UDP 与 QUIC 的关系

UDP 提供的是数据报传输基础，它本身不保证数据按序送达，也不替应用完成可靠重传。QUIC 在 UDP 之上加入连接管理、加密、流控制和可靠流等机制。因此，“使用 UDP”不等于“丢了就不管”，也不等于“必然更快”。需要看上层协议如何组织数据、怎样响应拥塞，以及接入网络是否允许这类流量顺畅通过。

传统 TCP 连接要求按序交付字节，前面的数据尚未补齐时，后面的字节可能无法交给上层。QUIC 可以在传输层管理独立的流，减轻不同流之间因丢失数据而相互等待的情况。但同一流内仍有顺序和可靠性的要求，各流也共享网络容量及拥塞状态。它改善的是特定等待关系，不会消除链路上的容量不足，更不会让所有应用都自动获得同样收益。

Hysteria2 与 TUIC 的选型重点

Hysteria2 基于 QUIC 构建代理传输，其实现通常提供与带宽估计或拥塞控制有关的选项。参数意义应结合当前客户端文档和服务端要求理解。把期望带宽填得很大，并不能创造更多链路容量；过于激进的发送可能让本地队列堆积，影响其他应用。若没有明确的配置要求，优先使用订阅与客户端给出的设置，避免把调参变成新的故障来源。

TUIC 同样利用 QUIC 承载代理连接，连接复用、数据报处理和拥塞控制等行为取决于具体实现与配置。它与 Hysteria2 有共同的传输基础，但不能因此认为参数可以直接互换。节点认证方式、客户端支持和服务端匹配仍然是前提。界面里出现协议名称，通常只说明客户端具备相应能力，并不证明当前订阅或当前网络一定提供可用入口。

重连、网络切换与实际限制

QUIC 的连接标识与路径管理机制为网络变化提供了灵活性，但代理会话能否平滑延续，还取决于客户端实现、服务端策略和应用自身行为。设备从无线网络切到其他接入方式时，地址、路由和可达性都可能变化。即使传输连接能够恢复，目标应用也可能主动重建会话。所以更合适的观察方式是记录任务能否继续，而不是要求所有切网都完全没有感知。

有些接入网络对 UDP 的处理较差，可能限制流量、缩短空闲状态保留时间，或让数据报更容易丢失。这时 QUIC 类节点可能表现为建立失败、空闲后断开或持续传输不稳定。应先在其他接入网络验证，再与可靠的 TCP 类配置对照。如果问题只发生在特定网络，优先保留兼容的替代连接，不必反复更改账户信息或重新导入全部订阅。

资源方面，QUIC 常由用户态实现管理加密、定时器、重传和连接状态。在某些设备上，这些工作会形成明显开销；在另一些设备上，实现优化和较少的等待又可能改善整体体验。没有统一的电量排名。下载任务结束后能否及时空闲、后台是否持续保活、设备是否频繁重连，往往比协议名称更值得观察。比较时还要把屏幕亮度、视频解码等耗电来源分开。

因此，QUIC 类协议适合作为按网络条件验证的选项，而不是默认替代所有连接。先确认客户端和订阅支持，再验证常用网页、长连接与持续传输，最后观察切网和待机表现。若当前网络对数据报不友好，回到可用的 TCP 类方案是合理选择。真正需要的是可重复完成任务的组合，而不是为了使用新协议而牺牲日常连接的可预期性。

线路拓扑：直连、中转与专线

直连的路径短，不代表等待少

直连通常表示客户端直接连接指定的远端节点，没有额外安排的代理中转入口。它的结构较容易理解，维护环节也较少，但实际路径由本地接入与运营商路由共同决定。地理距离近，不一定意味着网络路径短；看起来相邻的地区，也可能因互联关系而绕行。选择时应同时观察目标任务的响应与持续传输，不能只根据地图上的位置判断体验。

直连的另一项边界是接入差异。同一个出口，在不同运营商或不同接入网络上可能表现不同。家庭网络流畅，换到公共无线网络后变慢，并不矛盾，因为入口之前的路径已经改变。若准备把设备带到多个场所使用，应分别验证常见接入环境，并保存可用的备用线路。线路名称只能帮助分类，不能代替实际环境下的可达性确认。

中转把路径拆成可管理的段落

中转线路先将流量送到入口节点，再由入口送往国际出口。它增加了一个可管理的转发环节，可能改善原本不理想的跨网连接，也可能因为入口负载或后段容量不足而增加等待。中转的价值在于路径安排与资源管理，不在于“多经过节点必然更快”。评价时应把到入口的质量、中转到出口的质量，以及出口到目标服务的质量分别考虑。

两条线路如果共用同一入口，换出口后仍然卡顿，问题可能仍在共同经过的前段。相反，入口访问顺畅而特定目标缓慢，可能涉及后段或目标服务。普通用户未必能够直接看到内部拓扑，但可以通过对照不同入口、不同出口和不同目标缩小范围。记录哪些组合同时异常，比连续切换后只记住“有时好用”更有参考价值。

专线描述承载方式，不是整段保证

IEPL 专线通常指特定承载段使用以太网专线资源。用户设备到入口，以及国际出口到目标服务，仍可能经过公共网络。因此，专线标签不等于从本机到每个网站都处在独占通道中，也不自动说明端到端容量。应关注服务提供的线路说明与实际任务表现，避免把承载段的名称扩大理解为整个互联网访问过程的绝对保证。

专线也需要容量规划、入口调度和出口管理。多人同时进行高流量任务时，共享资源仍可能出现排队；远端目标负载较高时，专线无法替目标加快响应。对于会议和远程操作，平稳的到达节奏可能比一次大文件下载的峰值更重要。对于资料同步，则还要看长时间传输是否持续。评价标准应跟随任务，而不是只跟随线路标签。

出口地区决定请求从哪里访问目标服务，也会影响内容分发节点、账户验证和地区规则。为了减少变量，长期工作通常适合保持相对固定的出口，只有在故障或任务确有需要时切换。频繁更换地区可能使某些平台触发额外验证。线路能够连接，与目标平台允许该账户使用，并不是同一个层面的判断，平台规则仍需单独遵守。

2HVPN 提供 90+ 国家 / 250+ 线路，覆盖数量用于说明选择范围，不应被当成每条线路质量相同的证据。查阅线路与地区说明时，可以先按目标地区缩小范围，再按接入网络与任务验证。选择合适线路后保留备用入口，比不断追逐更远或名称更复杂的节点更实用。协议与拓扑应一起看，但比较时尽量只改变一个因素。

丢包与拥塞：晚高峰为何波动

先区分容量、排队与丢失

带宽可以理解为路径能够承载数据的能力，延迟则包含传播、处理与排队产生的等待。链路尚有余量时，小请求可以很快通过；当发送需求超过某段承载能力，数据就会在设备队列里等待。队列装不下时，还可能发生丢弃。因此，下载能跑起来却让通话和网页变迟钝，往往不只是“带宽不够”，也可能是队列管理让交互请求排在大量数据后面。

丢包并不都来自拥塞。无线干扰、信号衰减、设备故障与路径变化，也会使数据无法正常送达。传输协议需要判断是否重传、何时重传，以及是否降低发送强度。不同实现的反应方式会改变体感，但无法消除丢失本身。若接入网络持续不稳定，优先改善信号与本地连接，往往比在远端协议之间不断切换更直接。

为什么晚高峰更容易暴露问题

晚高峰意味着更多任务同时竞争接入网络、跨网互联、中转资源或出口容量，瓶颈可能出现在路径的不同位置。某条线路平时顺畅，集中使用时等待变长，并不一定是服务器处理器不足。若同一接入网络中的普通网站也变慢，应先检查本地与运营商接入；若只有特定入口异常，则继续对照其他入口与出口。用现象定位比凭时段直接下结论更可靠。

也要注意目标网站本身的负载和内容分发策略。出口改变后，目标可能分配不同的内容服务器；账户状态、缓存命中和文件来源也可能不同。看同一个页面不代表实际下载了同样内容。为了减少干扰，可以重复使用同类任务，并记录是否登录、是否已有缓存、是否后台同步。无需追求实验室条件，但应知道哪些条件会让结果看起来更好或更差。

怎样解释探测结果

客户端的延迟探测可能采用不同方法：有的只检查到节点的连接，有的请求某个网址，有的复用已有连接。它们测到的路径与工作量并不相同。某个节点不回应特定探测，也未必意味着实际代理请求不可用；探测顺畅，同样不证明目标应用顺畅。阅读数值前先看测试方法，并把数值当作筛选线索，而不是最终体验判定。

路径诊断工具显示的中间设备丢失响应，也需要谨慎解释。路由设备可能降低诊断响应的优先级，却继续正常转发业务数据。如果后续路径和目标仍然能稳定回应，不能仅凭中间某一段的显示就认定那里正在丢弃业务。普通用户更适合优先记录端到端任务是否成功、是否出现停顿，以及问题是否随接入网络或线路变化，而不是把每个中间响应都当成故障证据。

处理拥塞时，应先减少本地竞争，再比较不同入口或承载路径。若只是把同一服务器上的协议名称换掉，瓶颈仍可能完全相同。若换到独立入口后改善，则值得保留该组合继续观察。不要同时开启多个客户端进行竞争测速，这会让它们相互影响，也可能改变系统路由。每次完成对照后恢复常用配置，让测试结果能够复现。

稳定性应按任务描述：会议是否连续、远程操作是否可控、文件是否完整、页面是否能持续打开。这样的记录能体现真实需求，也避免用某次峰值替代长期体验。如果问题集中出现在相似时段，记录当时使用的入口、出口、接入网络和目标类别，通过面板工单提交。信息完整比反复发送“很慢”更有助于定位，且无需附带完整订阅链接。

平台与电量：设备端的实际开销

系统代理与虚拟网卡不是同一入口

系统代理通常把代理地址提供给愿意遵循该设置的应用，虚拟网卡模式则在更靠近系统网络路径的位置接收流量。前者配置较轻，但某些应用可能不采用系统代理；后者覆盖范围通常更广，却需要处理路由、权限与地址解析等细节。遇到浏览器可用而其他应用失败时，应先确认流量进入客户端的方式，不要立刻更换远端节点。

桌面系统还可能同时运行企业网络工具、其他代理软件或安全软件。它们都可能修改系统代理、虚拟网卡和路由优先级，形成互相覆盖。退出其中一个程序后，残留设置也可能继续影响访问。排查时先确认当前由哪个客户端接管网络，再按该客户端的正常退出方式关闭。不要直接删除不认识的网络适配器，以免影响原本正常的工作环境。

移动端耗电来自多处

移动设备的耗电不仅包括加密计算，还包括网络模块保持活跃、后台保活、重传、应用同步和屏幕显示。协议带来的差异只是其中一部分。连续播放视频时，屏幕与解码会占用明显资源；待机时仍发热，则更值得检查重复重连、频繁保活或后台大量传输。比较前先让任务类型保持一致，否则很容易把视频画质差异误认成协议耗电差异。

保活可以帮助连接在空闲时维持网络设备中的状态，但过于频繁的保活也可能增加唤醒和网络活动。不同接入环境对空闲连接的处理不同，不能把别人的保活设置直接当作最佳值。若出现待机后无法恢复，可以先观察客户端日志和后台权限，再按产品说明调整。将间隔一味缩短，可能改善某个症状，却让电量和网络资源付出更多代价。

权限与恢复比反复重装更值得先查

Android 的后台限制可能让客户端在屏幕关闭后无法按预期维持活动，iOS 的连接状态则受系统网络扩展和应用会话共同影响。先按客户端说明授予必要权限，再观察是否仅在待机后发生问题。权限并非越多越好，应只开放功能确实需要的部分。若前台使用正常而后台恢复失败，提交问题时明确说明这个分界，比只描述“经常断开”更有帮助。

macOS 用户需要留意网络扩展授权是否完成，以及系统设置中的相关状态是否与客户端一致。Linux 用户则要注意桌面环境代理、命令行程序环境和系统解析服务未必采用相同配置。一个终端程序正常，并不能证明浏览器也走同一路径。更详细的安装顺序可查阅macOS 从零开始配置教程，本章只负责解释差异与排查方向。

内存与处理器占用也会随规则数量、连接数量和日志等级变化。大量详细日志适合短期排错，不适合长期保持；复杂规则若与其他工具重复处理，也会增加维护成本。应先使用可理解的默认配置，再根据明确需求增加规则。设备资源较紧张时，减少同时运行的网络工具、关闭不必要的调试输出，往往比盲目追求某个“最低占用协议”更有效。

2HVPN 支持 Windows / macOS / iOS / Android / Linux，同时在线不限台数，但设备不限不代表每台设备都应套用同一套系统参数。订阅可以统一管理，权限、分流和后台策略仍需按平台核对。客户端从用户面板获取，订阅需登录后取得；iOS 下载入口按有效套餐状态提供。保留每台设备的可用基线，后续调整会更容易恢复。

按场景选型：先定目标再做对照

网页、文档与 AI 工具

网页浏览与在线文档通常包含许多不同来源的小请求，域名解析、首次连接和规则匹配对体感影响较大。适合先选一个接入顺畅、地区合适的出口，观察常用页面是否完整加载，再判断是否需要换协议。页面文字出现而附件或图片失败时，可能只有部分资源走错路径。此时优先检查请求范围与分流规则，不要把整个网站的异常都归结为节点不可用。

AI 工具还可能使用持续返回内容的长连接。页面能登录，不能代表生成过程一定能持续完成。应观察请求发出后是否正常返回、长回复是否中断，以及上传资料是否受影响。平台的账户资格、地区政策和自身服务状态也会参与结果判断。协议只负责连接过程中的一部分，不应被描述为能够保证任意账户或功能可用。更多场景说明可查阅AI 工具专题。

视频、会议与远程操作

视频观看更关注持续传输与缓冲恢复，会议和远程操作则更关注交互等待及到达节奏。视频已有缓存时，短暂停顿可能不明显；会议没有足够缓存掩盖波动，同样的路径就会显得更敏感。因此，不要用视频能播放来证明会议一定稳定。会议前先停止竞争性下载，固定已验证的出口，并保留在当前接入网络中可用的备用线路，比临场尝试陌生参数更稳妥。

流媒体还涉及账户、版权地区与平台对出口的判断。连接成功与内容可观看应分开验证；某条线路能够打开平台首页，也不代表所有内容都适用。选择出口时先遵循平台规则，再观察实际播放与缓冲。不要为了短时间改善清晰度而频繁更换地区，导致账户触发额外检查。相关边界可继续阅读流媒体专题，这里不提供平台可用性的固定承诺。

多设备与流量安排

家庭共享时，每台设备的任务不同，合适的连接也可能不同。桌面电脑同步文件，平板播放视频，移动设备处理消息，不能只拿其中一台的体验代表全部。2HVPN 同时在线不限台数，但这些设备仍会竞争家庭网络和套餐流量。可以先把高流量任务错开，再按设备保存稳定配置。设备数量限制的理解可参考多设备与家庭共享选购说明。

套餐选择应按实际用量和使用频率，不应把价格档位理解成协议性能排名。月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。若使用时间不固定，可以对照用完为止、永久不过期的流量包：¥158/300GB、¥358/1000GB、¥658/3000GB。完整计费说明见套餐页。

决定协议时，可以先以客户端支持且当前网络可用的配置作为基线，再对照另一个确实不同的传输组合。比较同类任务是否完成、空闲后能否恢复、设备是否明显发热。若差异并不稳定，保留更容易维护的方案即可。不要为了找到理论上的最佳组合而反复修改所有参数，配置复杂度本身也会增加出错机会，并让后续故障难以复现。

最终可以把选型结果写成简短的使用安排：常用接入网络对应哪条入口、工作任务使用哪个固定出口、切网后优先尝试哪个备用组合。这里不需要永久排名，只需要可执行的顺序。2HVPN 提供 60 天无理由退款，支持支付宝 / 微信 / USDT；这些是服务与计费事实，不应被当成技术效果保证。连接表现仍应通过自己的设备与日常任务确认。

排错与记录：每次只改一处

先保留可恢复的基线

排错前先记下当前客户端、所用线路名称、接入网络和异常任务，保留一套此前可用的配置。若刚更新订阅或修改规则后出现问题，优先检查最近的改动。没有明确原因时，不要同时重装、重置路由器和更换协议，这会让原有线索消失。每次调整后都验证同一任务，确认结果再进入下一步；即使没有改善，也能排除一个具体方向。

完全无法连接时，先确认不使用代理的基础网络是否正常，再核对账户与套餐状态、订阅是否成功导入、节点是否仍在当前列表中。认证失败、证书错误和超时属于不同分支，处理方式也不同。认证失败先核对订阅更新与账户状态；证书错误先看时间和名称；超时再比较接入网络与其他入口。不要通过关闭验证来掩盖错误，也不要把凭据贴到公共讨论区。

部分应用失败与持续传输异常

如果只有部分应用异常，先确定这些应用是否进入客户端管理的路径，再看它们是否使用自己的解析方式或持续保留旧连接。修改规则后，可以正常退出并重新打开目标应用，避免旧会话继续使用原来的路径。若浏览器页面正常但上传失败，要分别观察权限、目标服务限制和传输过程。把“登录正常、上传失败”写清楚，比只说应用不能用更容易定位。

如果小请求正常，大文件或长连接经常停住，可以检查本地竞争任务、无线质量和接入网络变化。数据报路径上的分片或路径最大传输单元问题，也可能使某类传输异常，但这需要更具体的证据。不要从网络文章复制任意参数直接套用；先使用客户端默认设置，再根据日志与产品支持建议调整。改动后保留原值，方便验证失败时恢复。

日志怎样看，工单怎样写

日志先读错误类别与发生阶段，不必逐行追踪所有内部细节。名称解析失败说明请求可能还没进入节点连接阶段；连接超时说明需要进一步确认地址可达性与路径；握手或认证错误则更接近协议参数和身份核对。日志中的单个警告不一定对应用户可见故障，应把它与异常发生时的任务对齐。仅有截图而缺少复现步骤，通常无法判断错误是不是主要原因。

需要协助时，可通过用户面板工单提供设备平台、客户端名称、线路名称、接入网络类型、异常发生的时段和目标任务类别，再附上脱敏后的错误摘要。说明换过哪些入口、是否在其他网络复现、关闭竞争任务后是否改善。若涉及单位或学校网络，还应遵守当地网络使用规则，不要擅自修改受管理设备的安全策略。

订阅导入异常则单独处理：确认复制的是面板提供的订阅入口，导入方式与客户端支持的格式一致，并在更新后查看节点列表是否正常出现。不要将浏览器打开链接的结果直接等同于客户端能否解析。若怀疑链接泄露，应从面板查找可用的重置或更新方式，并同步更新受影响设备。关于链接的作用与保管方法，可阅读VPN 订阅链接新手指南。

排错结束后，把临时详细日志、测试规则和额外客户端恢复到日常状态，确认系统代理与网络路径没有残留冲突。记录最后有效的改动，以及哪些操作没有作用，便于下次快速回到基线。2HVPN 无需邮箱地址，用户名+密码即可注册；账户凭据仍需妥善保存。理解协议与线路的目的，是让连接选择有依据、问题描述更明确，而不是让每次使用都变成调参任务。