完整使用手册
订阅交付全流程

认识订阅服务与完整交付流程

先区分账户、套餐、订阅与线路

第一次使用跨境网络加速服务时，最容易混淆的不是按钮位置，而是几个看起来相近的对象。账户用于识别购买记录与订阅归属；套餐决定流量额度、计费方式和有效状态；订阅是客户端读取线路资料的入口；线路则是客户端连接时实际选择的网络路径。四者彼此关联，但不能互相替代。仅创建账户不会自动获得可用线路，仅把客户端安装完成也不会自动出现订阅内容，付款后还需要进入用户面板取得订阅并导入客户端。

完整流程可以理解为一张交付单：先根据使用频率选择月订阅或流量包，再以用户名和密码创建账户，随后完成付款并等待订单状态写入账户。订单生效后，用户面板会提供订阅资料与客户端入口。把订阅导入对应平台后，客户端才会读取线路列表、规则模式和全局模式等配置。最后还要执行连接验证，确认当前应用确实通过预期线路访问，而不是只看客户端界面显示了连接状态。

服务覆盖与设备边界

35VPN 覆盖 120+ 国家 / 250+ 线路，支持 Windows / macOS / iOS / Android / Linux，并允许不限设备同时在线。这里的“不限台数”解决的是同一账户在多台设备上的同时连接需求，不表示所有设备必须使用完全相同的线路或模式。工作电脑可以使用规则模式，影音设备可以按内容地区选择线路，Linux 主机也可以只为命令行工具配置代理。合理拆分场景比把所有设备强制设成同一种模式更容易维护。

线路数量与可见线路并不是同一个概念。客户端中展示的内容可能受订阅更新状态、线路分组、当前套餐状态和客户端兼容方式影响。如果刚完成付款却只看到旧列表，优先更新订阅，而不是反复卸载客户端。如果某个平台正常、另一个平台为空，则应从该平台的订阅导入方式、权限和缓存开始检查。完整覆盖列表与线路类型说明可查阅全球节点页面。

规则模式与全局模式的职责

规则模式会根据客户端内的匹配规则决定哪些请求进入加速线路，适合日常长期启用。它能让本地服务继续走原连接，同时把需要跨境访问的应用交给订阅线路。全局模式则让更多请求统一经过当前线路，适合临时验证线路、排除规则未命中的情况。两种模式没有永久的优劣关系，选择标准是当前任务是否需要精细分流，而不是简单地把全局模式理解为更快。

当某个网站在规则模式下未按预期连接，可以临时切换全局模式复测。如果全局模式正常，说明线路与订阅大体可用，问题更可能位于规则匹配或应用自身代理设置；如果两种模式都不正常，则应继续检查订阅状态、当前线路、系统权限和本地网络。这样的分层判断比连续更换线路更有效，因为每次只改变一个变量，结果才有可比性。

开始前应准备什么

操作前只需准备稳定的本地网络、可记住的用户名与密码，以及计划使用的平台。注册无需邮箱地址，用户名+密码即可注册。建议先决定主要设备，再在该设备上完成首次导入和验证；确认流程跑通后，再扩展到其他平台。不要在多个设备上同时尝试不同配置，否则一旦出现问题，很难判断是账户状态、订阅缓存、客户端权限还是线路选择导致。

本手册按线性顺序编排，但已经完成部分步骤的用户不必从头重做。可以通过顶部目录直接进入对应章节。无论从哪一步开始，都应保留一个稳定的参照：已确认可用的账户、已更新的订阅、明确的连接模式和一个用于复核的应用。后续每次调整只改其中一项，就能把复杂问题拆成可核对的交付环节。

选择套餐与理解计费口径

先按使用节奏选计费方式

选择套餐时，先判断流量是持续发生还是阶段性发生。月订阅适合日常办公、开发、影音与多设备长期使用，额度按开通日每月重置；流量包适合使用间隔不固定、希望剩余额度继续保留的场景，购买后用完为止，永久不过期。二者最重要的差异不是单次价格，而是流量是否按周期重置。只比较标价、不比较使用节奏，容易出现额度不合适或长期剩余过多的问题。

月订阅包含三档：¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB。三个档位使用相同的平台范围与设备规则，主要区别是每月流量额度。流量按开通日每月重置，因此应把开通日视为自己的账期边界，而不是默认按自然月理解。开通日附近出现额度变化通常是正常重置，不应仅凭日历月份判断套餐是否提前结束。

流量包适合非连续需求

流量包提供 ¥158/300GB、¥358/1000GB、¥658/3000GB 三种选择，额度用完为止，永久不过期。它更适合工作项目集中发生、设备长期闲置或流量消耗波动较大的情况。因为流量不会按月清空，购买时无需把短期峰值机械放大成长期需求；但也应考虑自己是否需要持续有效的月度服务节奏。套餐页会把月订阅与流量包分别列出，正式选择前可前往套餐页面逐项核对。

判断额度时，不建议只按“是否观看视频”粗略分类。同样是影音使用，清晰度、播放时长、后台预载和多设备并行都会影响消耗；同样是开发工作，依赖下载、镜像同步和远程资源读取也可能造成明显差异。更稳妥的方法是先选择与日常强度相符的档位，使用过程中观察账户面板里的剩余流量，再决定是否调整，而不是在首次购买时依靠猜测一次性放大额度。

理解中途升级的处理方式

月订阅支持中途升级，差价会折算成剩余天数。这意味着升级不是简单地把原套餐整单作废后重新计算，也不应把显示的剩余期限与完整新周期混为一谈。操作升级前，应在面板中同时核对当前套餐、剩余状态、目标档位和结算结果，确认无误后再提交。升级主要解决当前额度不足的问题；如果只是某个应用突然消耗异常，应先检查后台同步或错误重试，避免用升级掩盖配置问题。

付款方式为支付宝 / 微信 / USDT。进入结算环节后，以页面当次展示的订单内容为准，重点核对套餐名称、计费方式、金额和账户归属。不要同时打开多个结算页面，也不要在订单状态尚未回写时连续重复提交。若付款已完成但面板仍停留在原状态，先返回订单或概览区域刷新确认，保留当前账户登录状态，再通过工单入口提交订单信息。

退款承诺与选择边界

本服务提供 14 天无理由退款。退款承诺用于降低首次判断套餐是否适合的成本，但不应代替购买前核对。平台支持、流量额度、线路覆盖、支付方式和使用模式都可以在付款前确认。若核心需求依赖特定地区或特定应用，先查看全球节点与相关说明，再决定套餐，比付款后盲目尝试更节省时间。

选择套餐的最终判断可以压缩为三项：使用是否连续、每月大致消耗是否稳定、剩余流量是否需要长期保留。持续使用且节奏稳定，优先比较月订阅三档；间隔明显且希望额度永久保留，重点比较流量包；已经处于月订阅且额度不足，则按中途升级规则核对差价与剩余天数。完成选择后再进入注册和付款，可以让后续每一步都有明确目标。

注册下单与付款状态核对

创建一个可长期维护的账户

35VPN 注册无需邮箱地址，使用用户名+密码即可完成。用户名承担账户识别作用，密码用于保护订单、订阅和工单内容。注册前应先确定一个不容易与其他服务混淆的用户名，并使用独立密码。由于无需邮箱地址，账户凭据需要自行妥善保存；如果在多个浏览器或设备上使用，建议先在主要设备完成注册、登录和购买，再逐步扩展，避免误把不同用户名当成同一账户。

提交注册后，应先确认已经进入用户面板，而不是立即重复点击。面板中的账户概览、套餐、客户端和订单区域分别承担不同职责：概览用于确认当前服务状态，套餐区用于选择计费方式，客户端区用于取得安装入口，订单区用于核对付款结果。建立这套位置认知后，后续遇到问题可以直接回到对应区域，不必在多个页面间来回猜测。

下单前执行四项核对

进入套餐区后，先核对登录用户名，再确认选择的是月订阅还是流量包。月订阅应继续核对 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB 中的目标档位；流量包则核对 ¥158/300GB、¥358/1000GB、¥658/3000GB。最后确认支付方式为支付宝 / 微信 / USDT 中准备使用的一项。只有账户、计费方式、额度与付款入口都一致时，才进入下一步。

多个页面同时保持结算状态容易造成判断混乱。较稳妥的做法是只保留一个有效订单页面，完成支付后回到同一账户查看状态。如果临时改变套餐，应先退出旧结算流程，再从套餐区重新选择，不要对两个订单同时操作。订单记录不仅用于付款核对，也决定后续订阅归属；发现账户不一致时应停止付款，返回登录区域确认用户名。

状态未更新时如何处理

付款完成后，若概览仍显示原状态，先刷新用户面板并重新进入订单区域。确认当前登录用户名与下单时一致，再查看订单是否已经显示完成。不要立即卸载客户端或删除旧订阅，因为付款状态属于账户与订单层，客户端操作不会让订单更快更新，反而可能丢失原本可用的配置。把问题留在正确层级处理，是整个排错体系的基本原则。

如果订单状态已经完成，但客户端仍看不到新增额度或新线路，说明付款环节大体结束，下一步应更新订阅。订阅更新是把账户中的最新交付内容同步到本地客户端，不是重新购买。反之，如果订单本身仍未完成，则反复更新订阅不会产生变化。通过“先订单、后订阅、再客户端”的顺序，可以避免把不同阶段的问题混在一起。

账户安全与退出习惯

在共享设备上使用用户面板后，应主动退出账户，不让浏览器长期保留登录状态。订阅资料属于账户交付内容，不应复制到不受控制的公开环境，也不应把完整订阅地址放进截图、公开文档或代码仓库。需要在自己的另一台设备上使用时，应从用户面板重新取得，而不是通过公开聊天记录转发。这样既方便后续更新，也能减少旧资料长期散落。

如果怀疑密码已经泄露，应先修改账户凭据，再检查当前套餐与订单记录，随后在各设备更新订阅。仅修改客户端名称或删除某条线路不会改变账户访问权限。账户层、订阅层和线路层必须分别处理：账户负责身份，订阅负责交付，线路负责连接。明确层级后，即使出现异常，也可以按顺序恢复，而不是一次性重装所有设备。

工单沟通应提供什么

需要支持时，可从用户面板的工单入口提交问题。描述应包含当前登录用户名、所处操作阶段、使用平台、选择的模式、订单或订阅是否已更新，以及界面中出现的完整错误文字。不要提交密码或完整订阅地址。有效描述应能回答“在哪一步、预期看到什么、实际看到什么、已经尝试过什么”，这样支持人员可以直接定位账户、订单或客户端层，而不是先反复追问基础信息。

完成注册与付款后，不必马上在所有平台重复配置。先在主要设备进入下一章，取得订阅并确认客户端能够读取线路列表。只要首台设备完成闭环，其他平台的操作就会变成同一订阅在不同客户端中的导入问题，复杂度会显著下降。

取得订阅并准备客户端

订阅资料从用户面板领取

订单生效后，进入用户面板的概览或客户端区域取得订阅资料。营销页面不会提供静态安装包直链，也不会公开真实订阅地址；客户端与订阅都通过用户面板交付。这样可以让下载入口、账户状态和套餐归属保持一致。若尚未登录，可从本页按钮进入面板；若已经登录，则直接打开客户端下载区域，按当前平台选择对应入口。

订阅可以理解为一份会更新的配置清单。它可能包含线路分组、连接参数与规则信息，因此不应把第一次导入后的本地列表视为永久不变。线路维护或套餐状态变化后，需要让客户端重新读取订阅。只要账户中的订阅仍然有效，通常无需删除整个客户端；优先使用更新订阅功能，能保留已经确认可用的权限与基础设置。

识别订阅导入与手工添加的区别

订阅导入会一次性读取由服务端维护的线路与分组，后续可以通过更新动作同步变化。手工添加则是逐项录入单条连接信息，维护成本更高，也容易在参数变更后继续使用旧值。35VPN 的标准流程以订阅导入为主。客户端界面可能使用“添加配置”“导入订阅”“从链接导入”或相近名称，本质都是让客户端读取账户交付的订阅资料。

复制订阅时，应确保内容完整，不要额外加入空格、换行或说明文字。如果客户端提示格式无法识别，先回到用户面板重新复制，不要自行截取其中一段。为了说明格式，文档中的示例只能使用明显的假值，例如：

subscription: https://example.com/sub?token=YOUR_TOKEN
mode: rule
group: auto
update: manual

上述地址仅用于说明字段结构，不能用于真实连接。实际订阅必须从用户面板取得。任何出现在公开教程、截图或代码仓库中的真实订阅资料都可能失去控制，因此排错时应只提供错误文字和必要界面，不要粘贴完整内容。

下载客户端前先确认平台

本服务支持 Windows / macOS / iOS / Android / Linux。平台名称相近并不表示安装方式相同，例如 macOS 与 iOS 都属于 Apple 设备环境，但权限入口、配置导入和后台运行方式不同；Windows 与 Linux 都可以承担桌面工作流，但 Linux 更常见的是托盘界面、桌面代理或命令行进程。应从用户面板选择与当前系统对应的客户端入口，不要拿其他平台的安装文件尝试运行。

建立一个清晰的配置命名方法

导入成功后，建议给配置使用容易识别的名称，例如按品牌与用途区分，而不是保留一串难以辨认的默认文字。多份配置同时存在时，应明确哪一份是当前使用的 35VPN 订阅，哪些是历史配置。删除前先确认当前连接来源，避免误删仍在工作的配置。若客户端支持更新记录或最后更新时间，可把它作为判断订阅是否刷新成功的辅助信息，但最终仍应以线路列表和实际连接结果为准。

订阅列表为空时，先确认账户套餐有效，再重新复制订阅并触发更新；列表存在但连接失败时，进入线路与权限排查；只有某个应用不通时，则进入规则或应用代理排查。三种现象对应不同层级。把“没有列表”“线路不能连接”“单个应用异常”分开记录，能够显著减少无效操作。

导入前的最后检查

正式进入各平台操作前，确保已经完成四件事：订单状态有效、订阅来自当前账户、客户端来自用户面板、设备本地网络可以正常访问常用服务。最后一项用于建立基线，如果本地网络本身已经不稳定，连接后的现象就不能全部归因于线路。准备完成后，再按照下一章的平台分支逐一导入。

推荐先完成一个平台，再处理下一台设备。不限设备同时在线允许多设备并行使用，但配置过程仍应按顺序推进。首台设备验证成功后，可以把它作为参照：当其他设备出现问题时，用同一账户、同一订阅和相近线路对照，就能快速判断差异位于平台权限还是订阅本身。

五平台客户端导入与权限设置

Windows：先导入，再启用系统代理

在 Windows 设备上登录用户面板，进入客户端下载区域取得对应客户端。完成安装后打开客户端，从配置或订阅管理入口添加订阅，把面板复制的内容完整粘贴并确认。等待线路列表出现后，先选择一条与当前用途匹配的线路，再启用规则模式。部分客户端还需要打开系统代理开关，只有线路选择和系统代理同时处于正确状态，浏览器与常规桌面应用才会按规则转发。

若客户端显示已连接但浏览器没有变化，先查看系统代理是否启用，再检查浏览器是否设置了独立代理或扩展。独立设置可能覆盖系统配置。若只有终端工具不生效，应检查该工具是否读取系统代理；有些命令行程序需要在自身配置或当前终端会话中指定代理，而不是自动跟随桌面设置。排错时先用普通浏览器验证基础连接，再处理特殊应用。

macOS：关注系统网络授权

macOS 导入流程同样从用户面板开始。取得客户端后完成安装，首次运行时根据系统提示允许必要权限。随后进入订阅管理，粘贴订阅并更新列表。选择线路与规则模式后，如果系统弹出添加网络配置或修改网络设置的确认，应完成授权；拒绝后客户端界面可能仍可操作，但系统流量不会按预期进入线路。

连接后可以从菜单栏或客户端主界面确认当前状态。若应用在切换网络后失去连接，先断开并重新连接当前线路，让客户端重新绑定新的本地网络。macOS 上同时运行多个会修改代理或网络配置的工具时，设置可能互相覆盖，因此应暂时关闭其他同类工具，只保留当前客户端完成验证。确认稳定后，再逐项恢复其他软件。

iOS：导入后允许添加系统配置

iOS 客户端入口应从用户面板取得。打开对应客户端后，使用面板提供的订阅导入方式添加配置。首次启用时，系统会要求允许添加网络配置；这是让客户端接管相应网络请求所需的系统步骤。完成授权后返回客户端，更新订阅、选择线路并启用连接。若系统状态已经显示连接，而目标应用仍使用旧会话，可完全退出该应用后重新打开。

iOS 在网络环境变化后可能保留旧连接状态，例如从无线网络切换到其他网络时，客户端界面仍显示原线路。此时应主动断开再连接，不要只依赖状态栏图标。若订阅更新失败，先确认用户面板可正常打开，再回到客户端重试；如果面板也无法访问，则应先恢复本地网络，而不是继续修改订阅。

Android：处理后台保持与分应用代理

Android 平台的关键不仅是导入成功，还包括后台运行。通过用户面板取得客户端后，安装并导入订阅，选择线路与规则模式，再允许系统建立网络连接。随后检查系统的电量管理和后台限制，确保客户端在锁屏或切换应用后仍能维持必要进程。不同设备的设置名称会有差异，但判断标准相同：客户端不应在离开前台后立即被系统停止。

如果只希望部分应用使用线路，可在客户端支持的情况下配置分应用代理。设置时要明确是“仅所选应用使用”还是“所选应用不使用”，两种语义相反。更改后先用一个目标应用验证，不要同时加入大量应用。Android 的后台保活、分应用代理和省电策略可进一步参考安卓 VPN 推荐与后台保活实测对比。

Linux：区分桌面代理与终端代理

Linux 上先从用户面板取得适用客户端或导入方式，再根据当前环境选择桌面界面或命令行工作流。桌面环境通常可以通过客户端托盘与系统网络设置接管浏览器流量；终端程序则可能需要读取环境变量、自身配置或本地代理入口。导入订阅后先更新线路列表，选择线路并启动客户端进程，再从一个明确支持系统代理的应用开始验证。

若桌面浏览器正常而终端工具失败，说明订阅和线路大概率已经可用，问题位于终端应用的代理读取方式。可以在当前项目文档中查找代理配置项，或为当前终端会话设置由客户端提供的本地入口。不要把真实订阅地址直接写进项目配置。示例配置应只引用本机客户端提供的代理名称或环境变量，不把账户交付内容提交到代码仓库。

多设备扩展时保持配置一致

五个平台全部支持并不意味着必须一次配置完成。建议保留一台已验证设备作为基准，然后在新设备上使用同一账户重新取得订阅。若新设备列表与基准设备不同，先分别执行订阅更新；若列表一致但连接表现不同，则比较模式、线路、系统权限与应用设置。不要通过复制整个客户端目录来迁移，因为平台权限、缓存和本地路径并不通用。

不限设备同时在线适合个人多设备与家庭共享场景，但每台设备仍需要独立维护客户端权限和订阅更新。有关设备数计算、家庭使用边界与配置分工，可阅读VPN 多设备共享全解。当每台设备都能独立完成“更新订阅—选择线路—启用模式—验证出口”这条链路时，多设备使用才算真正可维护。

连接线路并验证实际生效

选线先看地区，再看用途

导入订阅后，不要直接把线路名称当成速度排名。先根据目标服务所在地区与访问用途缩小范围，再从同一区域中选择当前表现稳定的线路。需要访问地区相关内容时，出口地区比名称中的其他修饰更重要；进行普通网页、开发工具或远程协作时，则应优先考虑连接连续性。完整地区与线路类型可在全球节点中查阅。

线路类型代表网络路径组织方式，不等同于对所有本地网络都给出相同结果。IEPL 专线、中转与直连在路径、适用场景和对本地网络的敏感程度上有所不同。遇到问题时，可以在同一地区内切换不同类型，观察结果是否变化。不要一次跨地区、跨模式又跨应用同时测试，否则即使恢复正常，也无法知道是哪项调整起作用。

连接状态不等于应用已经生效

客户端显示连接只说明本地进程已经尝试建立线路，最终仍要从应用侧验证。首先打开一个没有独立代理设置的浏览器，访问网络检测页面，核对出口信息是否与所选地区一致。随后再打开目标应用执行实际任务。若浏览器出口正确而目标应用异常，问题多半位于应用缓存、独立代理、规则匹配或旧会话，而不是账户和订阅。

35VPN 站内提供网络检测页面，可用于确认当前出口与基础网络信息。测试前关闭浏览器中可能覆盖系统代理的扩展，并避免同时运行其他网络工具。验证完成后，再恢复日常配置。这样得到的结果更接近客户端本身的实际作用，不会被额外层叠设置干扰。

用规则模式与全局模式做对照

当目标应用无法访问时，保持线路不变，只把规则模式临时切换为全局模式。如果全局模式恢复正常，说明线路可用，下一步应检查规则是否命中、应用是否使用特殊域名或是否设置了独立连接方式。若全局模式仍然异常，再保持模式不变，更换同地区线路。通过这样的单变量测试，可以分别判断模式层与线路层。

排查完成后应回到适合日常使用的模式。全局模式便于验证，但可能让原本无需加速的本地流量也进入当前线路；规则模式更适合长期保持，并能减少不必要的路径变化。选择并非越彻底越好，而是让需要的应用走正确路径，同时保留其他连接的自然访问方式。

处理缓存、会话与域名解析

应用在切换线路后仍可能保留旧连接。浏览器可以关闭相关标签后重新打开，桌面应用可完全退出再启动，开发工具则可能需要重新建立长连接。AI 编程工具、终端助手与协作服务尤其依赖持续会话，线路切换期间的短暂中断可能让旧任务失去上下文。相关选择与配置可参考Cursor / Copilot 长连接稳定性实测。

若域名解析仍沿用旧网络结果，可以先断开客户端，确认本地网络正常，再重新连接线路并启动应用。不要在尚未确认基础连接时同时清理大量系统配置。解析问题、应用缓存和线路问题表面上都可能表现为页面打不开，但对照方法不同：换应用可判断应用层，换模式可判断规则层，换同区线路可判断线路层。

形成一份可复现的验证记录

一次有效验证应记录平台、客户端状态、当前模式、线路地区、目标应用以及结果。无需记录敏感订阅内容。若问题只在特定网络环境发生，也应注明切换网络前后的差异。可复现记录的价值在于支持后续比较：当同一配置再次异常时，可以直接确认哪些条件发生了变化，而不是从注册环节重新开始。

连接成功的判定应同时满足三点：订阅列表正常、客户端线路处于连接状态、目标应用通过预期出口完成实际任务。只满足其中一项都不足以结束检查。完成首次闭环后，保留当前可用配置作为基准，再开始优化线路、分流或多设备使用。

日常维护、升级与续费管理

订阅更新应成为固定动作

客户端中的线路列表是订阅在本地的缓存，不应长期假定它与用户面板完全一致。发现线路名称、分组或可连接情况发生变化时，先执行订阅更新。更新完成后再重新选择线路，必要时断开并连接。直接删除配置再重新导入属于后续手段，因为删除会同时移除本地选择、规则状态和部分客户端偏好。

多设备环境中，每台设备都维护自己的本地缓存。在 Windows 上更新订阅，不会自动替 macOS、iOS、Android 或 Linux 客户端完成相同动作。若不同设备看到的列表不一致，应分别更新，而不是判断账户获得了不同内容。保持配置名称清晰，并在修改后逐台验证，可以减少历史订阅与当前订阅混用。

观察流量而不是凭感觉判断

月订阅流量按开通日每月重置，应在用户面板中结合开通日理解剩余额度。应用下载、云端同步、影音预载、系统更新和错误重试都可能持续消耗流量。若消耗明显偏离预期，先检查设备后台任务与全局模式使用情况，再考虑升级套餐。仅凭网页数量无法准确推断流量，因为不同任务的数据规模差异很大。

流量包用完为止，永久不过期，因此维护重点是剩余额度与实际使用节奏，而不是等待周期重置。月订阅与流量包都应避免让不需要加速的后台任务长期经过线路。规则模式可以把本地服务与目标应用分开；Android 的分应用代理、桌面应用的独立代理以及 Linux 的环境配置也可以进一步缩小范围。

中途升级前先排除异常消耗

月订阅中途升级时，差价折算成剩余天数。提交升级前，先确认当前额度不足是正常使用造成，而不是某台设备的同步任务、错误重试或全局模式配置导致。若异常任务仍在运行，升级只会暂时增加可用空间，无法解决持续消耗。先停止异常来源，再进入套餐区核对目标档位和结算结果。

需要升级时，从当前账户的套餐区域操作，不要另建账户。另建账户会让订单、订阅与剩余状态分散，后续难以维护。完成升级后先在用户面板确认套餐变化，再逐台更新订阅。若面板已经变化而客户端没有变化，问题属于本地订阅缓存；若面板本身未变化，则回到订单与结算状态处理。

续费时保持账户和订单连续

续费前应确认仍登录原账户，并核对当前套餐与开通日。付款后依次查看订单状态、套餐状态和订阅更新，不要跳过账户层直接修改客户端。保持同一账户连续使用，可以让订单、工单和订阅资料集中在一个位置，也方便核对历史操作。支付方式仍为支付宝 / 微信 / USDT，以结算页面展示为准。

如果计划调整档位，应先分清是续费原套餐还是中途升级。续费用于延续当前选择，升级用于处理当前周期内的额度需求，两者在账户中的作用不同。提交前阅读结算摘要，确认金额、套餐与账户一致。关于全部套餐的集中说明，可随时返回套餐页面核对。

客户端维护以稳定为先

客户端正常工作时，不必为了界面变化频繁重装。优先维护订阅更新、系统权限与当前模式。若系统更新后连接异常，先检查原有网络权限是否仍然有效，再重启客户端和设备；只有确认安装本身损坏时，才从用户面板重新取得客户端。不要从不明页面寻找替代安装文件，因为它可能与当前订阅交付方式不兼容。

卸载前应记下当前使用的配置名称、模式和已验证线路，但不要记录完整订阅地址。重新安装后从用户面板重新领取订阅，完成导入，再按原记录恢复模式与线路。这样的恢复流程比复制旧程序目录更可靠，因为它避开了损坏缓存和过期本地文件。

定期整理设备与配置

不限设备同时在线不等于配置可以无限堆积而不管理。已经停用的设备应退出账户，废弃客户端中的旧订阅应在确认无用后删除。共享设备上的登录状态应及时退出，个人设备也应避免把账户凭据与订阅内容存进公开同步目录。设备数量不受限制，安全边界仍由账户持有人维护。

日常维护可以固定为一条短流程：先看账户套餐状态，再看剩余流量与开通日，随后更新订阅，最后用常用应用完成一次验证。遇到异常时保留已知可用设备作为对照。只要账户、订阅、客户端和线路四层都有清晰状态，续费、升级和跨设备迁移就不会变成重新摸索。

进阶分流与系统化故障排查

先建立分层排错模型

复杂问题应按本地网络、账户订单、订阅配置、客户端权限、线路连接、规则匹配和应用会话逐层检查。本地网络负责提供基础连接；账户订单决定是否有有效服务；订阅把线路资料交付到设备；客户端权限决定系统请求能否进入代理；线路负责实际传输；规则决定哪些请求使用线路；应用会话则可能保留旧连接。任何一层异常，都可能表现为“打不开”，但处理方法完全不同。

排错时从最靠前、最容易验证的层开始。先断开客户端确认本地网络正常，再登录用户面板确认套餐与订单，随后更新订阅并检查列表。然后选择已知地区线路，以全局模式做基础验证。基础连接成立后，再恢复规则模式并处理单个应用。这个顺序能避免在账户失效时反复改规则，也能避免在线路正常时无意义地重新付款。

规则分流的设计原则

规则模式的目标不是把规则数量堆得越多越好，而是让路径可解释。可以先按场景分组：本地服务保持原连接，跨境应用使用自动或指定线路，地区相关内容进入对应地区分组，开发工具根据长连接需求选择稳定分组。每条规则都应能回答匹配对象、走向分组和未命中时的回落路径。

修改规则后，应选择一个明确应用验证，不要一次加入大量域名。若应用包含多个服务域名，只添加主域名可能导致登录、资源加载或接口请求分别走不同路径。此时可以通过客户端连接记录观察实际请求，再补齐同一服务所需的规则。记录中若包含账户标识或敏感参数，分享前应先做遮盖。

mode: rule
rules:
  - local-service: direct
  - work-tools: auto
  - media-region: selected-region
fallback: auto

这段示例只表达规则结构，不对应真实客户端语法，也不包含真实线路或订阅资料。实际配置应优先使用客户端图形界面和订阅自带规则。只有明确理解客户端格式时，才进行手工编辑，并在修改前保留可恢复的本地副本。

处理长连接与持续任务

开发工具、远程协作和实时内容依赖持续连接。执行这类任务时，应避免频繁切换线路或模式，因为切换会让已有会话重新建立。先选定线路，完成连接验证，再启动任务。如果任务中断，先判断客户端是否重连、本地网络是否变化、应用是否保留旧会话。不要立即跨地区连续切线，这会让问题难以复现。

对于命令行工具，浏览器正常并不代表终端自动继承设置。检查应用文档中的代理支持方式，让它指向本机客户端提供的入口。真实订阅地址不应写入环境配置，订阅负责向客户端交付线路，应用只需要连接本地客户端。把这两层分开，可以避免项目文件携带账户资料。

只有部分网站异常时怎么判断

当多数应用正常、只有某个网站异常时，账户和订阅通常不是首要怀疑对象。先完全退出目标应用并重新打开，再保持线路不变切换全局模式。如果全局模式正常，则检查规则命中；如果仍异常，换同地区另一条线路复测。若同一网站在不同设备结果不同，对照两台设备的客户端模式、解析方式和应用扩展。

地区相关内容还可能根据账户地区、应用缓存或历史会话判断，不只依赖出口。确认线路出口后，重新建立应用会话，再观察内容是否变化。不要把所有地区差异都归因于线路。手册能确认网络路径是否正确，但具体平台的账户与内容规则由对应服务决定。

连接频繁中断时怎么定位

先记录中断发生时设备是否切换网络、进入休眠或被系统限制后台运行。Android 重点检查省电策略，iOS 重点观察网络切换后的重连，Windows 与 macOS 检查系统代理是否被其他工具覆盖，Linux 检查客户端进程是否仍在运行。若中断与设备状态同步发生，优先处理平台权限；若多个设备在同一本地网络同时异常，则先检查本地网络。

若只有当前线路中断，保持其他设置不变，选择同地区另一条线路。若多条线路表现一致，再切换线路类型或本地网络。这样的顺序能把线路个体、地区路径和本地网络分别验证。提交工单时附上平台、地区、线路类型、模式和复现步骤，不提交完整订阅资料。

无法更新订阅时怎么处理

先确认用户面板能够打开并且套餐状态有效。若面板正常，重新复制订阅并检查客户端中是否存在多余空格或旧配置。若面板无法打开，先断开客户端测试本地网络，再重新连接。不要在订阅更新失败时连续创建新账户或新订单，因为这不会修复本地导入格式，还会让账户关系更复杂。

客户端提示格式错误时，删除本次失败的输入，回到面板重新取得完整内容。提示连接失败但能显示线路列表时，订阅解析已经完成，应转向线路和权限检查。提示列表为空时，则继续检查套餐状态、订阅是否属于当前账户以及更新动作是否真正完成。错误现象本身就是定位线索。

何时重置，何时提交工单

只有在账户有效、订阅内容完整、平台权限已确认、多个线路与模式都完成对照后，才考虑重置客户端配置。重置前记录当前配置名称、模式和问题现象，再从用户面板重新导入。重置不是第一步，因为它会删除能够帮助判断的现场信息。若问题与订单、套餐写入或账户访问有关，应直接提交工单，不必继续修改客户端。

一份高质量工单应写清使用平台、当前操作阶段、模式、线路地区、错误文字、是否能打开用户面板、订阅列表是否存在，以及对照测试的结果。可以附经过遮盖的截图，但不要包含密码与完整订阅地址。问题描述越接近可复现步骤，处理越能直接进入对应层级。

把复杂配置留在可恢复范围内

进阶使用的底线是随时能回到已知可用状态。每次修改规则、应用代理或系统权限前，记下原设置；每次只改一个变量；修改后立即验证；结果不符合预期就恢复。不要把临时测试配置长期留在所有设备上。稳定基准可以是一台已验证设备、一份当前订阅、规则模式和一条常用线路。

完成本章后，整个使用流程已经闭环：从套餐选择、账户注册、付款核对、订阅领取，到 Windows / macOS / iOS / Android / Linux 导入，再到线路验证、流量维护、升级续费和分层排错。之后遇到问题，无需重新阅读全部内容，只需先判断问题属于哪一层，再从顶部目录进入对应章节。对于订阅、节点、协议、分流等基础术语，也可继续阅读VPN 新手名词速查。