Shadowrocket
完整使用手册

02 / 首次启动

首次启动与系统权限

先识别操作对象，再打开连接

首次打开 Shadowrocket 时，先确认 Home 中是否已有服务器条目，再查看当前 Global Routing 与 Config。服务器条目决定连接到哪里，Global Routing 决定怎样处理流量，Config 则提供配置模式下的具体规则。主开关只负责启动或停止连接，并不会替用户补齐这些前提。空列表、未选条目或导入失败时，应先回到添加步骤；此时连续切换主开关，通常不能让缺失的连接信息自动出现。

开始前可暂时停止其他正在接管系统网络的连接，减少配置之间的相互影响。这里的目的不是删除已有设置，而是建立一个清楚的测试环境：知道当前由哪个配置工作、何时开始连接，以及关闭后网络是否恢复。若设备由学校或组织管理，系统可能限制添加或修改网络配置，应遵循设备管理要求。不要在不了解用途时移除组织下发的设置，也不要将管理限制误认为服务器参数错误。

理解添加 VPN 配置的系统确认

首次尝试启动连接时，系统可能要求允许 Shadowrocket 添加 VPN 配置，并使用设备密码或系统认证确认。这个配置让应用能够通过 Apple 提供的网络机制处理流量，是连接能力的一部分；它不是向服务商购买连接权限，也不是服务器已通过验证的提示。只有在确认弹窗来自当前主动发起的操作、应用身份正确后，再按系统流程授权。授权成功后，仍需继续测试服务器是否可达。

如果之前选择了取消，先返回应用，确认当前条目完整，再重新尝试启动，以重新触发需要的授权流程。必要时在系统 Settings 中查看 VPN 相关项目，名称与路径可能随设备系统而变化，以实际界面为准。检查时重点确认是否存在对应配置、是否允许启用，以及是否有其他连接同时工作。不要为了让弹窗再次出现而一次删除全部网络设置，这会扩大变更范围，也不利于查明原来的失败点。

系统显示 VPN 状态，只说明网络配置处于工作状态，不等于服务器认证成功，更不等于某个网站一定按预期路径访问。一个配置可能已经启动，但所选服务器不可达；也可能服务器工作正常，而当前规则将目标交给 DIRECT。判断时应把系统状态、客户端测试结果和实际访问结果分开记录。之后遇到“开关已打开但无法访问”的情况，才能知道问题发生在授权、传输还是分流阶段。

按实际功能授予访问权限

使用 Scan QR Code 时，应用需要访问摄像头以读取用户已有的配置二维码。若不希望使用摄像头，可以选择适合现有资料的其他导入方式；已经拒绝后，可在系统 Settings 中核对相机权限。复制链接导入时，系统也可能询问粘贴相关权限，应确认剪贴板确实是准备导入的内容。不要把摄像头授权与主连接授权混为一谈：它影响扫码输入，不直接说明服务器连接能力。

二维码、剪贴板和配置文本都可能包含认证信息。扫码前应确认来源与用途，导入后检查条目类型、地址和端口，不能因为读取成功就直接认定参数正确。若二维码来自自己的另一台设备，也要留意它表示的是单条服务器、订阅地址还是整份配置。不同对象的后续维护方式不同；选错导入入口可能出现内容无法识别或对象位置与预期不符，并不意味着所有信息都已失效。

首次配置的合理终点不是“所有权限都已打开”，而是只授予当前操作所需的权限，并能说明每项权限的用途。完成系统网络授权后，保留一个明确的服务器条目用于测试，先手动连接和关闭各一次。暂不启用自动连接条件，便于观察状态变化。确认手动流程可复现之后，再到 Settings 章节安排 On Demand，避免自动触发掩盖手动连接时已经存在的问题。

03 / 输入连接信息

添加服务器与已有订阅

Add Server：逐项核对连接参数

添加前先区分手头材料：单条分享链接描述一个服务器，订阅地址用于获取一组可更新条目，配置文件则可能同时包含规则和其他设置。它们不能只因外观都是一段文本就互相替代。材料应来自用户自己的服务商或原有配置。若只有域名和密码，却不知道协议、端口或传输方式，应先核对完整参数；靠尝试不同类型凑出一个能保存的条目，并不能证明它可以连接。

在 Home 使用 Add Server，先选择与原始信息一致的类型，再填写地址、端口与认证字段。地址栏通常填写主机名或 IP，而不是带网页路径的页面地址；端口必须与服务端监听端口一致。显示名称用于辨认条目，不参与认证。填写结束后逐项复核，尤其注意复制内容首尾的空格、全角标点和被截断的字符串。能够保存只代表输入通过本地检查，是否可用还要进行连接测试。

Shadowsocks、VMess、VLESS、Trojan 等类型的字段并不完全相同，不能把某种协议的填写经验机械套用到另一种。若原始信息包含 TLS、Server Name、Host 或 Path，必须按其对应字段保留。Server Name 与连接地址可能不同，Path 也可能区分大小写。不要把关闭证书检查当作通用修复方法；证书名称不符时，应先核对时间、名称和原始参数，避免绕过真正需要解决的配置问题。

Subscribe：导入与更新是两个阶段

已有订阅应按订阅类型导入，地址本身通常用于请求一份服务器列表，而不是直接作为单条服务器的主机名。导入前完整复制地址，特别留意问号后的参数是否保留；其中可能包含识别用户的敏感信息。导入后检查是否生成了预期条目、分组是否清楚、条目数量是否合理，再选择一个服务器验证。订阅请求成功只说明列表已取得，不代表列表里的每个服务器都能通过当前网络连接。

更新会重新读取订阅端返回的内容，因此订阅管理的条目不宜当作长期手动编辑的副本。需要临时调整某个条目时，先保留原始信息，必要时另存为独立测试条目，再观察后续更新是否覆盖改动。发现重复条目时，先辨认是同一订阅导入多次，还是手动副本与订阅条目同时存在。不要在没有确认来源的情况下批量删除，否则可能把唯一保留的有效配置一起移除。

更新失败时按请求链路检查

订阅更新失败，应先确认设备基本网络可用，再检查地址完整性、当前访问路径和服务端返回状态。当前服务器不可用时，通过它请求订阅也可能失败；可在了解影响的前提下切换到能够访问订阅地址的路径，再重试一次。若提示认证或权限问题，应核对原地址是否已变化；若获取到了内容却无法解析，应确认返回的是受支持的订阅内容，而不是登录页、错误页或普通说明网页。

导入结束后，分别记住条目的来源、当前选择和更新结果。单条链接与订阅的结构差别可查阅分享链接与订阅地址说明。后续验证只针对一个明确条目展开，不要一边更新整组订阅，一边修改规则和 DNS；保持输入信息稳定，才能判断接下来 Global Routing 的变化到底影响了什么。

04 / 决定流量路径

Global Routing 三种模式与规则匹配

Config、Proxy、Direct 分别控制什么

Global Routing 是连接验证前必须确认的一项状态。Config 按当前启用配置的规则处理请求；Proxy 将适用的流量交给代理路径；Direct 使用直连路径。三种模式解决的是路径选择，不会修改服务器本身的认证信息。若相同目标在不同模式下表现不同，应优先检查分流路径，而不是马上重建服务器。模式名称与规则中的大写策略关键字也要区分：前者是界面选项，后者是配置文本。

排查时可以暂时用 Proxy 验证所选服务器，但测试结束要恢复预期模式。若 Proxy 可用而 Config 不可用，说明至少存在值得检查的规则差异，不能直接断定订阅损坏。Direct 可用于比较当前网络的直接访问情况，但并非所有目标在直连路径都应可达。测试结论必须写清目标与模式，单独说“能用”或“不能用”缺少范围，也无法指导下一次配置调整。

规则自上而下匹配，具体条件放在前面

Config 中的规则一般按从上到下的顺序检查，命中后采用对应策略。DOMAIN 匹配完整域名；DOMAIN-SUFFIX 匹配指定域名及其子域；DOMAIN-KEYWORD 按域名中的关键词匹配；IP-CIDR 与 IP-CIDR6 面向地址网段；GEOIP 依据地址归属数据判断；FINAL 处理此前未命中的请求。规则条件越宽，越容易提前截住后面的请求，因此需要先安排具体条件，再安排范围更大的条件与兜底。

下面只是一段教学用的 .conf 规则片段，不是一份可以替代现有设置的完整配置。域名采用示例值，PROXY 要求当前存在可用代理路径。应用示例前应复制原配置，在副本中修改对应部分，并确认所选配置已经启用。仅仅把文本保存到文件中，不代表当前连接已经读取了它；切换配置后，还要建立新的请求来检查规则结果。

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

在这段示例中，example.com 及其子域首先交给 PROXY；域名里含有 example 的其他请求可能由第二条接住。两条规则不是同义写法，后者的匹配范围更宽。私有网段与 GEOIP 条件继续按顺序检查，剩余流量由 FINAL,DIRECT 处理。如果把 FINAL 放到开头，后面的具体条件就失去预期作用。若将兜底改为 FINAL,PROXY，未列出的流量路径也会变化，不能只把它看作格式上的替换。

用最小改动验证分流意图

只让指定网站使用代理时，可以保留目标 DOMAIN-SUFFIX 规则，并以 FINAL,DIRECT 收尾；不过一个网页可能请求多个域名，主域名命中并不代表图片、登录或接口请求也采用同一路径。遇到页面只加载一部分，应查看实际失败的请求，再判断是否需要补充明确的域名条件。不要用无限放宽的关键词规则掩盖问题，否则可能把原本希望直连的其他请求一起改变。

规则验证应使用新请求，必要时重新建立连接，避免旧连接继续沿用先前路径而造成误判。IP 相关条件还可能受到解析结果影响，GEOIP 也不能保证精确表达某个网站的业务归属。更细的匹配解释见规则关键字说明；指定站点的配置过程见白名单分流示例。每次修改后记录“目标、命中规则、最终策略”，比只观察连接图标更有判断价值。

05 / 建立连接

连接验证与故障定位顺序

建立能够复现的测试条件

开始连接前，确认设备自身能够访问已知正常的网页，当前服务器条目明确，Global Routing 处于准备测试的模式。第一次验证尽量固定在同一个 Wi-Fi 或蜂窝网络中，不要在测试过程中同时切换网络、更新订阅和修改规则。记录测试目标也很重要：网页首页、登录接口和应用内请求可能走不同域名，不能把其中一个成功访问的结果推广到所有网络活动。

选中服务器后，可以运行 Connectivity Test，再开启主连接并发起实际请求。测试结果只能说明该测试方式下的可达性与耗时，不能直接代表所有协议、所有目标或长连接场景。某些网络对测试使用的请求方式与真实业务请求处理不同，因而测试失败不一定等于业务完全不可用；反过来，测试有响应也不能证明认证、TLS 或目标站点访问一定成功，应将两种证据结合判断。

把“已启动”和“能访问”分成两次确认

主开关打开后，先确认系统连接状态是否保持，再在浏览器中发起一次新的访问。若开关很快回落，应优先查看系统授权、配置是否可加载及错误提示；若状态保持但目标失败，继续检查服务器、路由、DNS 与请求细节。不要把系统 VPN 标识当作最终验收条件。它描述的是本地网络配置状态，而实际请求还要经过解析、连接、认证和目标响应等环节。

页面可以打开时，还应检查是否符合预期路径。对于 Config 模式，需要观察具体请求的规则和策略；对于 Proxy 模式，需要确认当前选择确实是准备验证的服务器。若页面内容来自缓存，刷新结果可能无法说明新路径是否工作，可以换一个明确的新请求或重新打开目标页面。验证结束后恢复日常模式，并再测试一次，避免留下为了排查而临时采用的全局设置。

按失败层次选择下一步

第一层是当前网络：关闭连接后仍无法访问正常目标，应先处理 Wi-Fi、蜂窝数据、门户认证或设备网络限制。第二层是服务器：核对地址、端口、认证字段和服务状态；相同条件下换一个自己已有的条目，可以帮助判断是否只有单个服务器失败。第三层是路由：若 Proxy 可访问而 Config 失败，检查当前启用配置、目标规则与兜底策略。每一层都要先得出结论，再继续下一层。

第四层是 DNS 与目标请求。若主机名解析失败，连接尚未进入预期的服务器通信阶段；若已经解析但提示超时，应继续区分连接建立、认证或响应等待。证书错误则要核对设备时间、Server Name 与证书匹配关系，不宜直接关闭检查。若只有一个网站失败，还要考虑目标自身状态、登录状态及附属域名，不应马上将整个配置判定为不可用。

一次改一项，并保留回退点

排查最容易失去线索的情况，是一次更换多个参数后终于“能用”，却不知道哪项改动产生作用。建议按时间记下原值、改动和结果，每次只调整一个可解释的条件。若改动没有帮助，恢复原值再进入下一步；若结果改善，再重复同一测试确认。这样也能发现偶发网络波动，避免将短暂恢复误归因于不相关的开关。

需要进一步查阅时，可按开关已打开却无法访问的检查清单逐项执行。提交问题说明时，保留设备网络类型、Global Routing、错误类别和复现顺序即可，不必附上完整认证信息。一个可复现的描述应说明“在什么网络、使用什么模式、哪个目标、出现什么结果”，而不是仅提供开关截图；这种记录也会成为下一章解读 Data 的基础。

06 / 读取诊断信息

Data 流量与请求结果的判断

先确认统计口径与观察时段

Data 用于观察应用提供的流量和连接信息，具体可见项目以当前界面为准。阅读时先看清统计属于当前会话、某个时间段还是累计记录，再决定它能回答什么问题。不同页面上的数字可能采用不同范围，不能直接互相相减。应用本地记录与服务商的计费口径也可能不同，不能据此认定服务额度一定增减了同样的数值；额度应查看用户原有服务的相应记录。

为了让变化有解释性，先记下观察起点，再只打开一个待测目标，观察新增记录与流量变化。设备上的后台同步、通知、图片预加载和其他应用请求，也可能在连接开启时产生流量。看到上传或下载数字增长，只能说明有数据被处理，不能单独证明待测网页已经成功。相反，页面显示失败时也可能产生少量流量，因为解析、握手、重试或错误响应本身都需要通信。

把域名、策略与错误放在一起看

若当前界面提供请求详情，应优先核对目标域名、使用策略和结果，而不是只看合计数。Config 模式下，一个请求采用 DIRECT，可能是因为命中了直连规则，也可能是最后的 FINAL 将它接住；要结合具体命中信息判断。若当前记录没有显示命中规则，就通过配置顺序和受控测试逐步缩小范围，不应凭某个 IP 地址猜测一定命中了哪条域名规则。

观察到解析错误时，先检查 DNS 路径与目标名称；连接超时则要继续区分服务器不可达、目标不可达或等待响应；认证失败应回到服务器条目核对身份字段。相似的外部表现可能有不同原因，例如页面一直转圈既可能是接口域名被分到错误路径，也可能是服务端响应延迟。错误信息的价值在于缩小层次，而不是让用户看到某个词就立即套用固定修改方案。

用受控对照解释异常变化

如果怀疑某个页面造成持续流量，可以先关闭该页面与相关应用，观察是否仍有同类请求；再单独打开它，比较新增记录。测试时保持服务器、Global Routing 与网络类型不变，减少其他因素。若流量在关闭页面后仍持续，也要考虑后台任务或长连接未立即结束，不必马上认定应用行为异常。适当等待并重复观察，比清空所有数据后重新猜测更容易保留有效线索。

如果怀疑规则没有生效，应先确认观察的是修改后新建的请求。已经建立的连接可能继续沿用旧路径，导致 Data 中同时存在不同时间的结果。可以结束待测页面的连接，再按同样方式重新访问，必要时在理解影响的前提下重新建立客户端连接。比较时明确区分旧记录和新记录，不要因为列表里仍有先前策略，就断定刚保存的规则完全没有作用。

流量突然增多时，先排查照片同步、媒体播放、应用更新等真实业务，再检查是否存在大量失败重试。同一目标反复出现错误，可能意味着应用不断重试，而不是成功下载了大量内容。此时应结合失败时间和错误类型，回到连接章节定位。不要把所有异常都归到服务器速度，也不要依据一次短时观察就调整整份配置；先找出是哪类请求、在什么条件下变化。

保留有用记录，减少敏感内容外传

需要保存诊断信息时，记录发生时间、模式、目标类别和错误摘要，通常比保留完整网络内容更适合日常维护。域名、请求路径和访问时间本身也可能涉及个人信息；分享截图前应检查是否露出订阅地址、认证参数或私密访问内容。用于说明问题的材料应只保留必要部分，不能因为是技术日志就默认其中没有敏感信息。

清理历史记录前，先保存正在排查问题的最小证据，再确认界面中清除操作的实际范围。清除诊断记录不等于删除服务器，删除条目也不等于重置系统授权，操作前应看清对象。Data 最适合承担的是验证与对照：把“预期怎样工作”和“实际发生什么”连接起来。它不能替代服务状态确认，也不能仅靠一个汇总数字证明所有请求都采用了同一条路径。

07 / 调整常用项

Settings、DNS 与 On Demand

先分清设置的作用范围

调整 Settings 前，先确定问题属于应用级行为、当前 Config、单条服务器参数，还是系统网络权限。相近名称的选项可能位于不同层次，不能只凭关键词就认为它们控制同一件事。例如服务器中的 TLS 字段影响该服务器连接，配置中的 DNS 条件影响解析路径，而 On Demand 处理自动触发。当前界面与启用配置共同决定实际行为，修改前应记下原位置与原值，避免在错误层次反复调整。

对于已经稳定工作的配置，设置调整应围绕明确目标展开，例如减少手动连接步骤、修正某个域名解析失败或验证特定网络中的行为。不要将网上某一组设置直接视为通用最优值，因为服务端条件、网络环境和规则目标可能不同。若界面选项与资料不一致，以当前应用实际可见内容为准；不确定用途的项目先保留原值，通过小范围测试理解影响后再决定是否采用。

DNS：解析结果参与后续连接与匹配

DNS 将域名转换为地址，但“能得到一个地址”并不是唯一判断标准。解析使用哪条路径、返回结果是否适合当前网络，以及后续请求怎样连接，都可能影响访问结果。系统 DNS、自定义 DNS 与 DNS over HTTPS 的差别，首先在于解析请求如何发送和由谁响应，不应只按名称判断哪一种必然更快。新增自定义解析方式之前，先明确原来究竟是解析失败，还是已经解析后连接失败。

DNS over HTTPS 需要能够访问相应的解析端点；如果访问端点本身依赖尚未正常工作的代理路径，就可能形成启动阶段的依赖问题。类似地，服务器地址是域名时，也需要先获得可用解析结果才能建立连接。修改后应分别测试服务器连接与目标域名访问，不能只打开一个已经缓存的页面就判定全部恢复。若更改没有帮助，恢复原设置，再检查其他环节。

DNS 结果也可能影响 IP-CIDR 与 GEOIP 等地址相关规则，但域名规则和地址规则的使用条件并不完全相同。一个网站可能返回多个地址，不同请求也可能使用不同记录，因此单次解析结果无法代表它的全部流量。更具体的选择与验证方法见DNS 设置说明。排查时记录修改前后的目标、解析结果与访问表现，避免把缓存变化误认为配置必然改善。

On Demand：手动可用后再配置自动触发

On Demand 用于按设定条件触发连接，不负责修复错误的服务器参数。启用前应先确保手动连接、关闭和重新连接都能正常完成，再逐个设置自动触发条件。若当前界面允许按网络环境安排规则，应分别测试进入、离开或切换该环境时的行为。一次只增加一类条件，观察系统是否在预期时间启动连接，避免多个条件交叠后无法解释为什么自动重连。

启用后，手动关闭连接却很快再次启动，可能是自动触发条件仍然满足，应先回到 On Demand 检查，而不是反复删除 VPN 配置。需要进行直连基线测试时，先暂时停止相关自动触发，再关闭连接，否则测试期间可能被自动恢复。完成排查后再恢复原条件，并确认不会影响日常所需的连接行为。自动化设置应当是已验证流程的延伸，而不是掩盖不稳定连接的办法。

高级选项采用保守的验证方式

遇到局域网资源、UDP 业务或特定传输异常时，先确认服务端和当前协议是否支持相应需求，再查找相关设置。单纯打开一个选项，不会让服务端获得原本没有的能力。也不要为了普通网页故障一次调整多项底层参数；这会增加变量，并使原来清晰的问题变得难以复现。若已有配置包含特殊 DNS 或路由安排，应先理解其目的，保留原文，再在副本中实验。

当连接已经可用，最重要的不是继续增加设置，而是确认配置能够解释、修改能够回退。保留服务器、Config 和应用级设置之间的边界，有助于在网络变化时只调整真正相关的一层。日常使用前再确认 Global Routing 与 On Demand 的最终状态，避免让测试设置长期留在设备上；下一章将这些检查整理为可重复执行的维护流程。

08 / 保持配置可恢复

备份、更新与日常维护

备份应覆盖多个独立对象

应用、服务器条目、订阅地址、Config 与系统权限是不同对象，不能假设保存了其中一个就能恢复全部环境。维护前先列出自己依赖的内容：哪些条目由订阅生成，哪些是手动添加，当前启用哪份配置，以及是否存在自己修改过的规则。使用当前界面提供的保存或导出能力时，读清实际包含范围。若只能保存部分内容，就分别保留必要信息，不要把一个文件名当作完整恢复能力的证明。

备份文件可能包含服务器认证信息或订阅凭据，应放在只有自己或明确授权人员能够访问的位置。公开笔记、共享相册和公开可访问的文件目录，不适合保存这些原始内容。为了便于辨认，可以在自己的记录中写明用途、来源和本地维护时间，但不要把密码直接写进文件名称。备份是否有用，最终要看能否理解并恢复所需对象，而不仅是是否曾经点击过一次保存。

修改前复制，修改后保留验证结果

编辑 Config 前先保留一份当前可用副本，并写下这次准备解决的问题。一次变更尽量只涉及同一目的，例如增加一个域名规则，而不是同时重排全部规则、替换 DNS 和更换服务器。保存后确认启用的是新副本，再按连接章节的方法建立新请求。若结果不符合预期，切回旧配置重测；旧副本在相同条件下正常，才更有理由继续检查本次改动，而不是把问题归给外部网络。

维护记录不需要很复杂，可以依次写明问题、原值、修改位置、测试目标与结果。对于规则，还应记录预期策略和实际观察；对于服务器参数，则记录从哪里重新核对，不保存到可公开的文档中。这样下次遇到同样现象时，可以知道哪些处理已经验证过。长期积累后，也能区分“某次偶然恢复”与“在相同条件下可重复解决”的改动，减少反复试错。

应用更新与订阅更新分开安排

Shadowrocket 的应用更新通过 App Store 处理，当前版本信息与更新内容以商店页面为准。Subscribe 更新则重新读取用户已有订阅的内容，两者不是同一个过程。为了便于定位问题，尽量不要在同一轮测试中同时完成应用更新、订阅更新和整份配置替换。更新后先确认原有连接与常用目标正常，再安排下一项变更；若界面位置发生变化，先寻找对应对象，不要立即重复导入造成条目混杂。

订阅更新后，应检查原先选中的服务器是否仍存在，名称或分组是否发生变化，以及手动修改是否被覆盖。某个旧条目消失可能来自订阅端的内容调整，不一定是本地保存失败。先看更新结果和条目来源，再决定是否需要重新选择服务器。若更新失败但旧列表仍在，也要明确当前测试使用的是先前保存的数据，不能将旧条目可连接误认为本次更新已经成功。

换机与重装后的恢复顺序

换机时，先在 App Store 确认应用购买记录与兼容性，再恢复自己的服务器和 Config，最后重新确认系统权限与自动触发条件。应用能够重新获取，并不保证本地条目会自动出现；系统网络授权也应按新设备实际提示处理。恢复后先选择一个明确条目手动验证，再检查规则和 DNS，最后安排 On Demand。按这个顺序推进，可以避免尚未确认配置有效时就被自动连接反复触发。

恢复后若看到重复内容，不要立刻批量清空。先辨认哪些来自备份、哪些来自再次导入的订阅，再选择需要保留的来源。删除订阅分组之前，也应确认是否会连带移除受其管理的条目。任何涉及多个对象的清理操作，都应先留好可恢复信息，再逐步执行。购买恢复的具体检查可参阅已购恢复说明，不要将购买记录与配置备份的职责互相替代。

建立简短而固定的日常检查

日常遇到问题时，按固定顺序检查：当前网络是否正常、所选服务器是否正确、Global Routing 是否符合用途、Config 是否为预期副本、订阅最近一次更新是否成功。随后才进入 DNS、规则和单个请求的细查。长期不用的测试条目可以在确认来源后清理，仍需使用的配置则保留清楚名称。每次排查结束恢复临时设置，并用常用目标再验证一次，避免修好一个场景却留下新的路径变化。

首次操作仍可回到快速上手按主线执行；需要理解现象时，再从本页目录定位相应阶段。完整维护流程的目标，是让每个变化都有来源、每次测试都有范围、每项修改都有回退点。不要将一次成功连接视为所有场景永久成立，也不必在稳定使用时频繁重建全部配置。保留必要记录，按层次检查，通常比不断叠加设置更容易得到清楚且可复现的结果。