线路与协议技术参考

协议、传输与分流的边界

先把连接拆成可观察的环节

打开网页时，浏览器先获得目标地址，再建立连接，随后发送请求并接收内容。启用网络代理后，中间增加了客户端判断规则、连接入口、封装请求、由出口访问目标等环节。页面迟迟没有显示，可能发生在其中任意位置。协议名称只是封装约定，不能同时说明入口质量、出口位置、域名解析方式和目标站响应速度。把这些层次分开，排查才有明确方向。

可以沿着“应用请求 → 规则判断 → 入口连接 → 传输链路 → 出口访问”理解整个过程。规则决定哪些请求进入代理，入口是设备实际连接的位置，出口是目标服务看到的访问来源。入口与出口可能位于不同地区。客户端显示的地区标签通常描述出口用途，不应直接当作设备到入口的物理距离，更不能据此推导所有网站的响应时间。

协议支持与服务支持不是同一回事

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 与 TUIC 都有各自的客户端实现和部署要求。本页讨论的是这些技术的通用设计，并不表示 F4VPN 的每条线路都提供全部协议。实际可选项应以面板下发的订阅和客户端兼容情况为准。若订阅没有某项，不应手动改写协议字段尝试连接，因为认证、传输与服务端监听必须相互匹配。

同样的协议可以搭配不同传输，同样的传输也能运行在不同线路上。看到某个名称后，应继续确认连接是否依赖可靠字节流、是否使用数据报、加密由哪一层承担、是否存在额外转发。只比较协议缩写，容易把线路的容量优势误认为协议优势。可复现的比较应尽量保留相同出口、相同应用和相近网络环境，再单独改变需要观察的条件。

规则模式改变路径，不改变账户权限

规则模式按域名、应用类别或地址范围分配路径，全局模式则让更广泛的请求尝试经过选定出口。两种模式不是速度档位。某个应用在全局模式下恢复，说明规则、解析或流量接管值得检查，并不证明全局模式始终更好。长期把本地资源也送往远端，可能增加绕行、消耗套餐流量，并使原本就近的服务选择较远的内容节点。

域名解析也参与路径选择。应用可能自行解析地址，客户端可能使用独立解析器，系统还可能保留旧缓存。如果规则依赖域名，但请求进入客户端时只剩地址，就需要核对客户端是否能正确识别目标。不要只清空浏览器缓存后便认定解析已刷新；应用连接复用、系统缓存与客户端缓存属于不同位置，应按照客户端说明分别检查。

安全能力也需要按层理解。代理连接加密保护的是设备到相应服务端之间的传输，目标网站的加密连接仍然重要。F4VPN 的信任话术为“量子加密”，但这个名称不能替代对具体协议、证书和实现方式的核对，也不能据此推导所有协议都采用后量子算法。阅读下文时，重点是识别各层责任，而不是给协议排一个脱离环境的总榜。

Shadowsocks、VMess 与 Trojan

Shadowsocks：关注加密方法与实现匹配

Shadowsocks 的基本思路是把应用流量交给代理端处理，使用约定的加密与认证方式传输。它的配置通常较直接，但“配置字段少”不等于所有实现都一样。加密方法、数据报处理、地址解析与插件需求都可能影响兼容性。导入订阅后若提示方法不支持，应先确认客户端能力，而不是自行选一个名字相近的方法替换；名称接近不代表密钥格式或数据格式一致。

评价 Shadowsocks 的资源占用，需要结合设备处理器、加密实现与流量形态。支持相应硬件加速的设备，执行某些加密操作可能更轻松；另一些设备则可能在持续传输时受到处理能力限制。短网页请求与长时间文件传输的负担也不同。看到桌面端表现良好，不应直接推断移动设备在后台、低电量或散热受限时也有完全相同的结果。

它对应用数据的承载还受底层传输影响。可靠字节流连接会负责有序交付与重传，数据报则有不同的处理方式。某个网页可以打开，只能说明相应请求链路可用，不能证明实时语音或其他依赖数据报的业务同样正常。遇到应用部分功能可用、部分不可用时，要检查客户端是否接管了对应流量，以及出口是否支持该类转发。

VMess：认证、时钟与额外封装

VMess 将用户认证与代理请求封装结合起来，实际部署还可能叠加不同传输方式。它不是一条固定的网络路径，也不能仅凭名称判断是否适合某个地区。排查认证失败时，客户端与服务端能力、订阅完整性以及系统时钟都值得检查。设备时间明显偏离真实时间，既可能影响相关认证机制，也可能引起其他加密连接的证书校验异常。

如果 VMess 叠加了额外传输层，连接建立需要完成相应协商，故障位置也会增加。基础连接成功但后续认证失败，与根本无法连接入口，是两类问题。日志中应区分解析错误、连接超时、握手失败和认证拒绝。把这些错误全部称为“节点慢”，会掩盖真正原因；反复更换出口也未必能修复本地时间或客户端兼容问题。

Trojan：依托 TLS 的连接约定

Trojan 通常依托 TLS 建立加密传输，再按协议约定进行认证与转发。证书校验、服务器名称与服务端部署因此成为排查重点。客户端能够连接到地址，不代表 TLS 协商一定成功；证书过期、名称不匹配或本地信任环境异常，都可能使连接在业务请求发出前结束。此时应检查订阅与系统环境，不应把关闭证书校验当作常规修复方式。

TLS 提供的是连接层的安全能力，并不会让线路自动具备更大的容量。一个部署正确的 Trojan 连接，仍然可能受到入口拥塞、出口回程或目标站响应的限制。连接复用和会话恢复可能减少后续请求的建立成本，但效果取决于客户端、服务端和中间设备的共同支持。不能把一次热连接的快速响应，与另一个协议首次连接的等待直接比较。

基础协议之间怎样作选择

对普通网页和常规应用而言，优先选择客户端原生支持、订阅字段完整、实际网络表现稳定的方案，比追逐协议名称更有意义。如果不同协议使用了不同入口或出口，观察结果只能代表整条连接方案，不能拆出纯粹的协议排名。记录比较时应写清线路标签、传输方式、应用场景和异常类型。需要进一步理解订阅、节点与协议的关系，可查阅新手名词速查，再回到本章对照具体字段。

VLESS 与传输层的组合取舍

轻量协议不等于完整安全方案

VLESS 将代理请求与认证信息的表达做得相对精简，但它本身不负责提供完整的传输加密。实际安全性依赖搭配的传输保护与正确部署。因此，“使用 VLESS”仍然是一个不完整的技术描述，还应知道它承载在哪种传输上、连接如何校验、客户端是否支持该组合。只看协议名称便宣称加密更强，或者直接认定资源占用更低，都缺少必要条件。

这种分工让实现具有组合空间，也使兼容性检查更重要。订阅里的传输类型、服务名称、路径、服务器名称与相关参数应作为整体读取。用户不需要逐项手填，但应知道随意删除字段会改变连接行为。导入后出现“协议支持但无法连接”的情况，可能是客户端只支持 VLESS 的部分组合，而不是账户、密码或套餐本身有问题。

可靠字节流与应用层传输

基于 TCP 的传输提供可靠、有序的字节流，适合承载网页和文件等常见业务。发生丢包时，缺失内容需要重传，后续字节可能等待前面的缺口补齐。对交互应用而言，等待比平均吞吐更容易被感知。若代理在同一连接内承载许多请求，底层链路的波动还可能同时影响这些请求，因此需要结合复用方式理解短暂卡顿的范围。

WebSocket 在连接建立后提供双向消息通道，便于在相应应用层环境中转发数据，但额外封装与转发环节并非免费。连接是否经过反向代理、是否存在空闲超时、上游能否持续转发，都影响实际体验。它可以解决部署适配问题，却不会凭空增加可用带宽。比较时应把整个传输链路纳入，而不是只按封装名称判定快慢。

gRPC 等应用层传输还涉及流、会话和中间转发设备的行为。某些环境能够有效复用连接，另一些环境则可能受到代理超时或实现差异影响。客户端成功识别节点并不代表每种业务都适合该传输。若长连接容易断开，而重新发起短请求又正常，应重点检查空闲连接管理、网络切换与中间设备行为，而不是直接增加应用并发量。

连接复用是条件选择，不是固定加速开关

复用让多个业务请求共享已有连接，可以减少重复握手和连接管理成本，尤其在频繁打开小资源时具有意义。但共享也意味着相互影响：某个底层连接发生阻塞或重建，可能牵连更多请求。是否应该启用，应以服务端配置与客户端默认策略为起点。不要同时调整复用、解析、出口和传输，再凭主观感觉判断是哪项产生了作用。

观察连接建立速度时，还应区分冷启动与持续使用。冷启动可能包含解析、建连、加密协商和认证，持续使用则可能复用已有连接。浏览器刷新页面时，缓存内容和连接池会进一步改变结果。合理的方法是分别记录首次打开、正常浏览与闲置后恢复的行为，保留环境说明。它们回答的是不同问题，不能压成一个“连接速度”结论。

如果某个组合在桌面上可用、在移动端失败，先检查两端使用的核心与传输支持，而不是照抄所有高级选项。不同客户端的同名开关也可能存在语义差异。优先重新导入面板提供的订阅，并保留默认值；仍有问题时，把失败发生在连接前、握手时还是业务传输中写清。这样的描述比发送大量配置截图更有效，也更容易避免暴露订阅凭据。

Hysteria2、TUIC 与 QUIC 传输

数据报基础与可靠传输并不矛盾

Hysteria2 与 TUIC 都利用 QUIC 相关机制构建代理传输，但它们不是同一个协议，也不能互换配置。QUIC 通常在 UDP 数据报之上实现加密连接、流管理与拥塞控制。底层使用数据报，不意味着应用数据必然不可靠；可靠流与数据报转发可以有不同语义。理解这一点，才能避免把“使用 UDP”直接等同于低延迟，或者把丢包恢复能力误读成不需要重传。

QUIC 的流机制能够减少不同流之间因缺失数据造成的直接顺序等待，但底层拥塞仍会共享网络容量。无线信号变差、链路排队或出口繁忙时，所有业务依然会受到影响。它解决的是特定传输问题，不是绕开带宽约束。若应用自己只有一个串行请求链，即使底层支持独立流，也不一定能感受到多流并发带来的好处。

Hysteria2：拥塞策略需要合理输入

Hysteria2 的性能表现与拥塞控制策略、带宽设置以及网络条件密切相关。在需要手动声明带宽的配置中，参数应反映可持续承载能力，而不是接入套餐宣传的理论峰值。填写过高可能造成排队和额外丢包，填写过低又可能限制传输。若面板已下发相应配置，应先保持原值；没有可靠依据时，不应照搬他人环境里的激进参数。

对于链路存在波动、但仍有可用容量的环境，合适的策略可能改善持续传输体验。不过，这不等于它在所有情况下都更省流量或更省电。重传、保活、加密和用户态处理都需要资源。若下载速度提升但其他设备的交互明显变慢，应同时观察本地排队与共享网络负担。单个任务占满链路，并不是整体网络体验改善的充分证据。

TUIC：会话、转发与客户端实现

TUIC 同样需要客户端与服务端在认证、会话和转发行为上保持兼容。实际体验取决于实现质量、数据报转发方式与拥塞控制设置，不能仅根据同样使用 QUIC 就推断它与 Hysteria2 表现一致。导入时应使用订阅给出的完整配置；如果客户端不能识别相关字段，先确认支持范围，不要只把协议名称替换成另一个相近选项。

连接复用与会话保持可以减少部分建立成本，但也会受到网络变化影响。设备在无线网络与移动网络间切换时，源地址、端口映射和路由可能改变。QUIC 在机制上具备处理连接迁移的能力，实际代理是否能平滑恢复，还取决于客户端、服务端及网络设备。不能因为底层具备能力，就承诺应用长连接一定不中断。

从可用性开始，再比较效率

某些接入网络对数据报设置了不同的转发、限速或空闲超时策略，因此 QUIC 类协议可能表现为连接失败、短时间正常后失去响应，或只在切换网络后恢复。排查时先在其他接入环境做对照，确认现象是否跟随网络。若问题只出现在特定环境，可保留兼容的备用线路，不必把所有应用都固定在同一个传输方案上。

数据包尺寸也是边界因素。封装会占用额外空间，路径对较大数据报的处理若不理想，可能出现小请求正常、大传输异常的现象。但这只是排查方向，不是确定诊断。应结合日志、不同应用与不同接入网络交叉验证，再按客户端说明调整。随意修改底层尺寸参数，可能把原本局部的问题扩展到全部连接，并使之后的对照失去基线。

最终选择应综合成功率、稳定性、交互响应和设备负担。持续下载适合观察吞吐与拥塞恢复，聊天、网页和远程操作则更关注响应是否连贯。若某种协议只在测速时突出，却在常用应用中频繁重连，它未必适合作为日常默认项。有关记录方法，可继续阅读VPN 速度实测方法，把主观印象转为可复查的条件说明。

直连、中转与专线的路径差异

先识别入口与出口之间的关系

直连通常表示设备直接连接远端服务入口，中间不再安排服务方的额外中转环节。但互联网本身仍由许多网络组成，所谓直连并不是一根专属物理线缆。实际经过的网络与回程可能随运营商调度变化。它的优点是结构较直接，排查环节相对少；边界是体验更依赖接入网络到远端入口的公共路径，晚高峰时可能出现不同于平峰的表现。

中转是在设备与最终出口之间增加入口或转发节点，让请求先到一个更适合接入的位置，再送往远端。增加环节可能带来处理和传播成本，也可能因为路径更合适而改善整体体验。不能只数经过多少个节点就判断延迟高低。较短的地图距离可能配上绕行路由，较长的逻辑链路也可能经过质量更合适的互联路径，关键在实际路径而不是名称。

专线描述链路组织，不是无限容量

IEPL 专线通常用于描述通过专门组织的以太网链路连接不同位置的网络方案。它有助于控制相关链路的交付和路径，但完整访问仍包括设备到入口、出口到目标服务等部分。即使中间采用专线，本地无线网络拥塞或目标站响应缓慢也不会自动消失。线路标签应作为理解拓扑的线索，而不是对任何应用、任何时段结果的保证。

专线也有容量规划、共享使用和设备处理方面的约束。用户通常无法仅从线路名称获知全部带宽分配方式，因此不应把“专线”等同于独享。选择时观察长期使用中的波动、故障范围与恢复情况更有价值。如果只有某个目标站异常，而其他服务均正常，应先考虑出口到目标的路径或平台策略，不能立即认定整条专线失效。

地理邻近不等于业务邻近

选择出口还要看目标服务部署在哪里。设备到出口很快，出口到目标很慢，最终响应仍然可能不理想。对于全球分布的内容服务，不同出口可能被分配到不同内容节点，账号地区和平台规则也会参与决定。因此，地区选择应围绕实际应用进行，不必一味追求列表中看起来最近的位置。需要特定地区的业务，应先满足业务地区要求，再比较合适线路。

来程与回程也可能不同。去往目标的数据经过某条路径，返回的数据不一定沿原路回来，所以单向观察不足以解释全部问题。路径探测中的中间设备还可能降低对诊断请求的响应优先级。某一跳显示等待，并不能单独证明业务流量在该位置发生同等损失。应结合终点表现、应用日志和其他目标的对照，避免从局部探测得出过强结论。

如果本地访问正常、所有远端线路都波动，先检查接入网络与客户端；如果只有共享入口的线路异常，则入口或共同路径更值得关注；如果只有特定出口上的目标应用异常，再检查出口与业务服务。按故障影响范围划分，比不停切换国家更高效。切换线路时保留原标签与发生时段，避免换过之后再也无法还原当时的路径条件。

F4VPN 的覆盖事实为 90+ 国家 / 220+ 线路，覆盖范围用于提供地区选择，不意味着每个地区拥有相同协议、拓扑或业务适配。具体条目请查看线路列表，不要从总体数量推导单个地区的容量。建立日常默认线路与用途明确的备用线路，通常比收藏大量未验证出口更便于维护，也能降低故障时临时搜索的成本。

连接建立、丢包与晚高峰诊断

把“慢”改写成可以定位的现象

“慢”可能表示点击后很久才开始加载，也可能表示开始很快但内容持续停顿，还可能是大文件传输正常、网页交互却迟缓。前者需要检查解析、连接与服务端等待，持续停顿更应关注丢包、排队和应用缓冲。先写出异常出现在哪个阶段，再选择工具。否则，测速页面给出的吞吐结果可能很好，却完全没有测到真正影响工作流程的那段等待。

连接建立涉及解析、传输握手、加密协商和认证，业务首字节还包括目标服务处理。首次访问往往比已有连接上的请求更复杂。对照时应区分首次启动、连续使用与闲置后恢复，不要混在一起取主观平均。若闲置后首个请求经常失败，而重新连接便正常，可能与空闲连接回收、地址映射或客户端恢复机制有关，并不一定是出口持续拥塞。

丢包会触发恢复，也会改变发送节奏

丢包不仅意味着某些数据没有抵达，还可能触发重传与拥塞控制，使发送方降低发送节奏。可靠传输最终可能补齐内容，但用户仍会感到卡顿。无线干扰、队列溢出、设备负载和路径问题都能造成相似结果。不能仅凭一次探测就断言某条线路质量不佳；应查看异常是否持续、是否影响业务终点，以及换接入网络后是否仍然存在。

晚高峰的典型问题是多个环节同时接近容量上限。家庭接入、无线环境、入口聚合、互联链路和出口都可能形成队列。队列增长时，吞吐未必立刻下降，但交互等待可能明显增加。持续大流量任务还会掩盖其他业务的需求。排查时先暂停本地占用明显的任务，再观察网页与实时交互是否恢复，避免把家庭内部竞争全部归因于远端服务。

使用可重复的对照顺序

建议先验证本地普通网站和系统网络，再确认客户端连接状态，随后用相同应用比较不同线路。如果所有线路都有同样问题，增加另一台设备或另一种接入网络作对照。每次只改变一个主要条件，记录应用、出口标签、连接模式与错误信息。这样得到的结论可以指导下一步，而同时更换客户端、解析与协议只会制造难以解释的差异。

工具应回答具体问题。域名查询用于检查解析是否成功，连接日志用于观察建连与握手，浏览器网络面板用于区分等待和下载。路径探测可以辅助理解路由，但中间节点可能不响应诊断请求。测速工具主要观察所选测试端点，不代表所有应用。测试流量也会计入实际使用，应避免为了重复确认一个已明确的现象而持续运行大流量任务。

按失败位置缩小范围

如果入口无法建立连接，先检查解析、接入网络与服务可达性；如果握手阶段失败，检查时间、证书与传输兼容；如果认证被拒绝，确认订阅是否更新及账户状态；如果连接成功但特定业务异常，再检查规则、出口与目标服务。错误信息不是最终诊断，却能帮助区分下一步方向。把不同阶段的故障都用重装客户端处理，通常成本高且信息损失大。

延迟稳定但内容加载慢时，应观察目标响应和吞吐，而不是继续寻找更低延迟的线路。吞吐正常但操作迟缓时，检查并发任务、排队和应用自身串行请求。只有某个地区异常时，可以选择业务允许的备用出口；所有地区异常时，优先回到共同的本地环节。这样的分支能减少无效切换，也使工单描述更容易被复查。

需要反馈时，通过面板工单提交可复现步骤与已经完成的对照，不必上传包含私人内容的完整页面。记录应说明“做了什么、发生什么、换了什么后是否改变”，而不只是“线路不稳定”。常见连接问题可在帮助中心继续查阅；希望建立长期比较记录时，可结合测速文章安排不同使用时段，避免把单次结果当作长期结论。

移动端电量与客户端资源占用

耗电来自整条处理链

移动设备运行代理时，消耗不仅来自加密计算，还包括无线收发、数据复制、用户态网络处理、连接保活与重连。后台应用持续同步，也可能通过代理产生流量。因此，同一协议在不同设备上的耗电不能直接比较；同一设备在不同信号强度、屏幕状态和应用负载下，也会出现明显差异。先确认是否存在持续传输，再讨论协议开销，通常更接近问题本身。

弱信号环境会增加无线链路的工作负担，网络反复切换又会触发恢复和重新建连。此时看起来像客户端一直耗电，实际可能由接入环境主导。可在信号稳定、应用负载相近的条件下观察，再与原环境对照。不要一边进行持续下载，一边用待机经验评价电量；不同任务产生的收发量与计算量本来就不在同一个比较条件里。

平台机制决定后台行为

iOS 的网络扩展受系统生命周期管理，应用界面与后台连接并不总是同一个状态。切换网络、系统资源紧张或扩展异常时，可能需要重新建立连接。应从系统提供的连接状态与客户端日志一起判断，而不是只看应用首页的图标。描述文件、客户端导入和系统权限属于不同环节，首次设置仍应按快速上手教程完成，避免把权限缺失当成协议兼容问题。

Android 的后台限制、电量优化与不同系统的进程管理策略会影响连接维持。若熄屏后连接容易中断，应先查看客户端是否获得其正常运行所需的系统许可，再检查后台网络是否被限制。放宽限制可能改善持续连接，但也可能增加后台运行时间，应按实际需要选择。不能把所有省电选项全部关闭作为通用答案，更不应假定同名设置在不同系统中行为一致。

保活与自动检测需要适度

保活有助于维持连接状态，但频繁保活可能增加无线唤醒与后台流量。自动测速和健康检查也会主动发起请求，检测过密会让设备持续工作。普通使用应先采用客户端默认策略，确认存在可复现问题后再调整。不要因为某个高级开关标有“稳定”便全部启用；多个检测机制同时运行，反而可能增加切换次数并使异常更难追踪。

规则分流有助于让本地请求直接访问，减少不必要的绕行与代理处理，但规则数量并不是越少越省电，也不是越多越准确。规则更新、匹配实现和应用请求模式都会影响开销。应采用来源明确、用途清楚的规则组，避免重复叠加同类规则。若某个本地应用出现异常，先核对规则命中与解析结果，不必立刻将所有流量改为全局代理。

虚拟网络接口模式可以接管更广泛的应用流量，也会增加与系统路由、解析和其他网络工具的交互。桌面系统中同时运行多个接管工具，可能出现请求循环、出口不一致或解析混乱。出现问题时应保留一个明确的流量接管入口，再逐项恢复其他工具。全局接管与系统代理的覆盖范围不同，不能只看开关名称判断应用是否实际经过客户端。

F4VPN 支持 Windows / macOS / iOS / Android / Linux，并提供不限台数的使用方式，但设备性能与网络条件仍各自独立。不限台数不代表共享网络容量无限，也不代表所有平台使用相同核心。客户端下载统一进入面板客户端入口。比较资源表现时，记录平台、接入方式、应用负载与后台状态，比仅写协议名称更能帮助判断；有关账户与订阅保管，可继续阅读安全使用指南。

按应用场景选择协议与线路

网页与 AI 工具：先看请求是否连贯

日常网页包含许多小资源，请求建立、解析与连接复用常常比持续吞吐更影响感受。AI 工具还可能使用持续返回内容的连接，短时中断会表现为输出停止或需要重试。应优先选择常用时段响应连贯、客户端恢复正常的线路，再考虑协议组合。出口地区也要符合目标服务的使用规则；网络连通不能替代平台账户资格、业务权限或地区政策。

针对这类业务，可先保持规则模式，确认目标域名正确进入代理，再观察登录、页面加载与持续会话是否一致。如果页面能开而提交请求失败，应检查应用返回信息、关联域名与长连接行为，不要直接把问题归为带宽不足。协议切换只能处理传输层差异，无法修复目标服务的账户状态。保留业务允许的稳定备用出口，比频繁更改地区更便于复现问题。

流媒体与大文件：持续吞吐之外还有边界

流媒体需要持续传输，也受到平台对出口、账户与内容地区的判断影响。线路能连接并不等于目标内容一定可用，缓冲顺畅也不等于所有清晰度都能长期维持。选择时先核对平台与出口的实际表现，再观察连续播放过程。有关内容地区、平台提示和出口选择，可阅读流媒体专题；不要把通用协议介绍当作特定内容的可用性承诺。

大文件任务更容易暴露持续吞吐、设备处理能力和共享链路竞争。测试时注意其他应用是否同时变慢，以及暂停任务后是否恢复。如果下载占满本地接入，换协议可能改变拥塞行为，却未必解决排队根因。适度安排任务并发与传输时机，往往比单纯寻找峰值更高的线路实用。协议没有替代容量规划的作用，测试结果也需要与常用业务一起评价。

实时交互与网络切换：稳定优先

远程操作、语音与实时协作对抖动和中断敏感，较高吞吐不一定有价值。先确认应用是否依赖数据报、客户端是否正确接管，再比较相同场景下的连贯程度。对移动办公而言，还要测试离开无线网络后的恢复行为。支持连接迁移的底层机制只能提供条件，不能保证所有应用会话都保留；重要操作应遵循应用自身的保存与重连机制。

可以把日常方案整理为“默认线路、用途明确的备用线路、数据报受限时的兼容方案”。这里的分类是维护方法，不要求订阅必须具备特定协议。每个方案写明适用应用、出口要求、客户端支持与已知边界即可。不要保存大量未经验证的高级配置，也不要为了看起来完整而手动补写订阅没有提供的选项。实际可用性应始终高于名称偏好。

将网络选择与套餐选择分开

协议决定连接行为，套餐决定可用流量与计费安排，二者不应混为速度等级。F4VPN 月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB；流量按开通日每月重置，中途升级差价折算成剩余天数。流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止，永久不过期。完整说明见套餐页，不要根据某次测速推算未来全部业务的流量需求。

本服务提供 60 天无理由退款，支持支付宝 / 微信 / USDT，无需邮箱地址，用户名与密码即可创建账户。这些是服务事实，不是协议性能指标。比较前先确认自己的平台、常用应用和主要接入网络，再选择合适的流量方式。有关付费前核对退款、线路信息与售后入口的方法，可查阅订阅服务避坑清单，把承诺与可核查条款分开阅读。

最后保留一份简短记录：使用的平台、客户端提供的协议组合、线路标签、主要应用、异常发生阶段与已经完成的对照。订阅更新后先确认旧方案仍然适用，出现变化再回到相应章节。这样维护的是可解释的连接方案，而不是不断堆叠开关。需要重新完成导入时回到快速上手教程，需要核对实际出口时查看线路列表；本页则用于理解这些选择背后的技术边界。