Shadowrocket
设置详解

先判断选项属于哪一层

同一次访问可能同时受到三层设置影响：系统网络决定当前使用 Wi-Fi 还是蜂窝网络，以及是否允许建立 VPN；Shadowrocket 的 Settings 管理部分应用级行为；当前启用的 Config 则提供规则与配置参数。Home 中选中的服务器还决定实际使用的连接信息。因此，看到 Settings 里有某项取值，并不能直接推断所有请求都采用它。排查之前先记录当前网络、服务器、Global Routing 姿态和正在使用的配置文件，避免检查了一个未启用文件里的参数。

进入 Settings 时，应先确认要解决的问题是什么。例如“域名打不开”需要检查解析与路由，“切换网络后自动连接”需要检查 On Demand，“更换设备后列表不同”需要检查同步。不要因为某个名称看起来与网络有关就连续开启多个开关。设置项的展示位置和可用范围可能随应用及系统环境变化，本文保留英文名称作为查找线索；若当前界面没有对应入口，不应寻找同名但含义不同的开关代替。

怎样记录默认值与推荐值

本手册不把某台设备上的当前值写成所有用户的默认值。全新建立的配置、导入的文件、恢复后的应用数据，可能拥有不同起点。核对默认值时，应分清“应用初始设置”“当前配置内明确写出的值”和“没有明确填写时的继承行为”。尤其不要通过清除现有数据来观察初始状态：这样既可能丢失已有信息，也不能还原导入文件最初携带的参数。更稳妥的方法是先记录现场，再根据单项说明判断是否需要调整。

推荐值同样依赖用途。已经稳定使用的设备，推荐保留现状；临时诊断时，推荐减少变量；需要特定解析、自动连接或本地代理访问时，才建立相应设置。记录时除了数值，还要写明所在页面、配置文件名称、修改原因和验证结果。对于输入框，空白不必然表示关闭，也可能表示继承或自动选择。只有界面说明或配置语义明确时，才能把空白解释为某个具体行为。

一次变更应当形成一个闭环

修改前选择一个可重复的验证动作，例如打开同一网页并完成一次刷新。修改后使用相同网络、相同服务器和相同目标再试，必要时停止并重新建立连接，以排除旧连接仍然存在的影响。结果没有改善，就恢复刚才记录的取值，而不是继续叠加第二项修改。网络切换、服务器切换和规则修改应当分开测试，否则即使恢复访问，也无法知道哪一项起了作用。

首次连接遇到系统“添加 VPN 配置”提示时，应把它理解为系统允许应用建立相应网络配置的授权环节，而不是订阅导入步骤。拒绝授权与服务器参数错误是不同问题。若系统条目被删除，应回到正常连接流程重新处理授权，不要用修改 DNS 或规则来弥补。有关提示的具体关系可参阅VPN 配置提示说明，购买记录问题则应转到正版核验页处理。

DNS 设置实际改变什么

DNS 把域名转换为连接所需的地址，但它不等于代理连接本身。一次访问可能在域名解析之前就因为服务器连接失败而中断，也可能解析成功后在目标连接阶段失败。因此，“网页打不开”不能直接归因于 DNS。应先观察影响范围：所有域名都失败、只有某个域名失败，还是只有特定网络下失败。已有连接和缓存还可能掩盖问题，使同一设置看起来时好时坏，需要用新的访问记录确认现象。

配置中的 dns-server 用于指定相关 DNS 解析来源。示例中的 system 表示使用系统提供的解析来源，是建立基础对照的一种写法，不代表所有导入配置的默认值，也不保证适合每一种网络。系统解析来源可能随 Wi-Fi、蜂窝网络及网络配置改变。若用户已有配置明确安排了专用解析行为，应先阅读原配置说明，理解请求如何到达解析服务，再决定是否替换。

[General]
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

怎样选择取值与验证路径

对于没有特殊需求、目前工作正常的配置，建议保留已有 DNS 设置。需要诊断时，可在副本中使用系统解析作为对照，并保持其他参数不变。若使用加密解析地址，还需要考虑该解析服务本身的域名怎样解析、连接路径是否可达，以及证书验证是否正常。把某个地址填进输入框，不代表解析请求必然按预想路线发出；同样，解析服务可以连接，也不代表它返回的所有地址都能从当前出口访问。

不要只看解析服务的地理位置或名称来判断是否合适。真正需要验证的是：当前网络能否建立连接、查询是否得到合理应答、应答中的地址是否适合随后采用的路由。某些站点会根据解析来源返回不同地址，改变 DNS 后访问结果变化，并不一定意味着其中一方出错。应把“返回了什么地址”和“客户端接下来怎样连接这个地址”分开检查，必要时结合 Log 中同一目标的记录判断。

IPv6、缓存与网络切换

域名可能同时有 IPv4 与 IPv6 结果。某条路径只支持其中一种地址时，故障可能表现为部分站点慢、首次打开等待较久，或者切换网络后恢复。此时不应先删改全部规则。应确认本地网络实际提供的地址能力、所用服务器与协议的可达条件，再检查日志中的目标地址类型。若界面提供相关地址族选项，应记录原值后单项测试，不应把禁用某种地址族当作所有设备的长期通用方案。

修改 DNS 后，正在运行的应用可能继续复用已有连接；系统、应用和远端服务也可能各自缓存结果。因此，保存配置后立即刷新一次，不能充分证明新设置是否生效。可以先断开再连接 Shadowrocket，重新发起目标访问，并用日志确认产生了新请求。不要反复清除所有应用数据来处理缓存，这会引入额外变量。对照测试时还应避免同时切换 Wi-Fi 和蜂窝网络，否则解析来源和网络路径都会改变。

如果只有单个域名有问题，先核对拼写、对应规则及命中策略；若所有域名失败，再检查解析服务是否可达；若解析已有结果但连接失败，则转查服务器、目标端口与路由。需要向他人描述问题时，提供脱敏后的目标域名、测试时间、网络类型和错误阶段即可，不应公开完整订阅或访问凭据。更完整的逐层流程见开关已打开却无法访问的四步检查。

先看姿态，再看规则

Global Routing 决定应当如何理解当前的路由行为。Config 按启用配置中的规则处理请求；Proxy 用于让流量采用代理姿态；Direct 用于采用直连姿态。它们适合建立不同的诊断对照，但不能仅凭名称推断所有系统流量的处理结果：系统保留路径、配置中的绕过行为以及未进入连接处理范围的流量，都需要单独考虑。检查某条规则前，应先确认当前处于 Config，否则编辑规则后看不到预期变化，并不能说明规则语法无效。

Settings 中的应用级选项与 Config 内的参数可能分别影响连接行为，不能把其中一处的显示值当作全部有效配置。导入文件后，应确认哪个文件当前启用，再查看其 [General] 与 [Rule]。只编辑列表中的另一个文件，不会自动替换当前配置。遇到与预期不同的行为时，先记录启用文件名称和实际命中的规则，再研究参数含义，比重新导入整份文件更容易保留可用状态。

General 参数与规则顺序

bypass-system 涉及系统流量绕过行为，skip-proxy 用于列出应绕过代理处理的地址范围。下面的私有地址网段可作为理解语法的材料，不应不加检查地覆盖现有列表。用户所在网络可能还有其他地址范围，也可能存在特定访问要求。DNS、绕过列表与规则属于不同层面的判断条件，不能假定某个域名写了 PROXY 后，所有相关流量就必然忽略其他条件。

[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8
dns-server = system

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

规则通常按照顺序匹配，前面已经命中的条件会影响后续是否继续判断。示例先处理 example.com 及其子域名，再处理指定网段，最后用 FINAL 兜底。DOMAIN 适合完整域名，DOMAIN-SUFFIX 用于域名后缀，DOMAIN-KEYWORD 范围更宽，使用时要防止意外匹配。IP-CIDR 与 IP-CIDR6 则针对地址段，不应把域名文本直接填写成地址规则。

怎样判断修改是否有效

推荐从最小规则集建立对照，而不是先导入更长的规则列表。只让指定站点采用代理时，可以使用上面的 DOMAIN-SUFFIX 与 FINAL,DIRECT；需要其他兜底行为时，再按自己的使用目标调整。策略名应当在当前配置中有效，不能随意填入一个未定义的名称。修改后确认配置已保存并启用，再建立新请求检查命中结果；如果实际命中了前面另一条规则，应先修正顺序，而不是重复添加同一域名。

规则判断也受到请求可识别信息的限制。某次连接只有目标地址可用时，基于域名的预期未必能够直接复现；同一网页还可能访问多个域名，页面主体可见但图片失败，往往需要逐个查看相关连接。避免用一次页面加载结果概括所有规则的正确性。可以选定一个目标域名，核对其请求、命中项和策略，再扩大测试范围。针对只处理部分网站的场景，另见DOMAIN-SUFFIX 与 FINAL 配置说明。

区分“何时连接”与“怎样分流”

On Demand 用来按设定条件交由系统触发连接行为，关注的是连接何时建立或保持；Config 中的规则关注的是进入处理范围的请求采用什么策略。两者不是同一功能。开启 On Demand 不会自动补全服务器信息，也不会把所有网站改为某一种路由。如果用户已有服务器无法连接，应先在手动连接状态下修复，再配置自动触发，否则系统反复尝试只会让故障更难观察。

核对 On Demand 的当前值时，既要看应用内是否启用，也要看系统 VPN 配置的状态和相关条件。已经存在的配置、恢复数据或先前设置可能改变现场，因此本页不把开或关指定为所有设备的出厂值。对于首次建立连接、正在进行故障排查的用户，建议先保留明确可控的手动连接流程；当手动连接稳定、目标网络条件清楚后，再建立符合实际需求的 On Demand 规则。

按网络条件逐项验证

若当前界面提供 Wi-Fi、蜂窝网络或网络标识相关条件，应先确定每条条件的覆盖范围。网络名称相同不代表网络环境完全相同，公共网络还可能要求先完成网页登录。不要仅凭看到熟悉的 Wi-Fi 名称，就认为自动连接一定能够成功。配置完成后，应分别测试从蜂窝切到 Wi-Fi、从 Wi-Fi 切回蜂窝以及短暂断网后恢复这几种情形，并记录系统状态与应用状态是否一致。

测试顺序宜从简单条件开始：先使用一个明确的网络条件，确认连接触发符合预期，再增加例外。多条条件同时存在时，需要查看当前界面对顺序、匹配和动作的说明，不能凭列表位置猜测优先级。若某条条件覆盖范围过大，可能掩盖后面的例外。每新增一项，至少验证一次应该触发的场景和一次不应该触发的场景，这样才能确认边界，而不仅仅是证明开关能够打开。

网络发生变化时，现有连接可能中断并重新建立。某个应用的旧连接失败，并不一定表示 On Demand 没有工作；也可能是新连接已经恢复，但旧会话无法继续。应重新发起一次访问，再核对 VPN 状态。另一方面，系统显示 VPN 已连接，也不能证明所选服务器能够访问目标。自动触发、隧道建立和目标访问是连续但独立的环节，检查时应分别记录，避免把后两个环节的故障归因于触发条件。

停止连接与回退的方法

启用 On Demand 后，手动关闭连接可能很快又被满足条件的系统行为触发。这不应直接理解为按钮失效。需要临时停止时，应先暂停相关自动连接条件，再断开当前连接，并观察系统是否仍有其他有效的自动触发配置。具体入口以当前系统和应用显示为准。不要反复删除再添加全部 VPN 条目来达到临时断开的目的，否则会把授权、条件与连接问题混在一起。

在需要先完成网络认证的 Wi-Fi 中，应先确认本地网络本身已经可用，再启用自动连接。否则，解析、认证页面和远端连接可能同时等待，看起来像是所有网络都失效。排查时可以暂时回到手动连接，完成网络认证后重新测试；这属于定位网络准备阶段，不是要求永久关闭 On Demand。对于公司或学校管理的设备，还应遵循设备管理策略，不应通过随意删除系统配置绕过管理要求。

最终保留的设置应当能够用一句话说明，例如“在已验证的网络条件下触发连接，诊断时暂停”。若无法明确解释每条条件的用途，优先减少条件数量。每次变更后记录触发结果、所选服务器和是否需要重新授权，出现偏差时恢复到上一组已验证设置。自动连接只是减少重复操作的方式，不是连接质量保证；服务器可用性、订阅有效性与当前配置仍需由用户独立核对，相关常见情况也可在常见问题中继续查阅。

Ping 不等于实际访问速度

Ping 在界面中常被用于连接测试的概括名称，但具体测量可能采用不同方法。应先查看当前测试方式，而不是把所有结果都理解成同一种往返时间。针对服务器地址的探测、针对端口的连接与经过代理访问指定 URL，验证的是不同环节。某个服务器能对探测作出响应，不代表协议认证一定通过；端口能够建立连接，也不代表应用层参数、证书或目标访问全部正确。

低读数不能直接推导出高下载速度。短时测试主要观察建立连接与获得响应的过程，持续传输还受本地网络、服务器负载、线路状态和目标站点限制影响。单次测试失败也不等于服务器完全不可用，可能只是测试方法不被当前路径支持。阅读结果时至少保留测试方法、目标、网络类型和测试时间四项背景。没有这些条件，仅比较列表中的两个数字，容易把不同测量对象误当作同一质量指标。

测试方法与 URL 怎样选择

Settings 中相关测试选项的当前值，应以本机显示为准，不应把其他用户分享的截图当作统一默认值。如果已有测试结果稳定且符合实际使用，可以保留；需要诊断时，选择与问题阶段相符的方法。检查服务器端口时观察连接层，检查经过代理的访问时再使用相应 URL 测试。具体可选方法以当前界面为准，不要为了追求更小的显示数字而持续切换方法，这会使历史结果失去可比性。

若测试允许填写 URL，目标应当稳定、由用户确认可访问，并适合该测试预期的应答形式。重定向、登录页、证书异常、访问频率限制，都可能让测试失败但普通浏览仍有不同表现。教程中的 example.com 只用于说明格式，不应作为承诺长期可用的测速服务。也不要把带有私密访问参数的地址填进可能随日志展示的测试字段，避免后续分享诊断资料时泄露信息。

建立可比较的测试记录

推荐先固定一个服务器和一个测试目标，在同一网络下重复少量测试，观察是否持续失败以及结果是否大幅波动。不要把一次异常值当作结论，也不必短时间密集测试所有服务器。若测试功能显示超时阈值，应把它理解为等待上限，而不是网络质量目标；缩短阈值只会让较慢的响应更早被判定为失败，不会让实际连接变快。增加等待时间也无法修复错误的地址、端口或协议凭据。

当列表测试正常、实际网页失败时，先确认网页请求是否使用同一服务器，是否被 Config 分配到不同策略，以及是否包含另一个失败的资源域名。反过来，测试失败但实际访问正常时，要检查测试目标和方法，而不是立即替换全部设置。Connectivity Test 的结果也应结合其测试对象解读。测试工具是定位环节的证据来源，不能替代真实访问验证，更不能用一个成功状态证明所有应用都能正常工作。

最后进行本地网络对照时，只切换 Wi-Fi 与蜂窝网络，不同时更改服务器、协议和 DNS。如果结果随本地网络改变，再检查网络限制与地址可达条件；若各网络表现一致，再继续核对服务器参数和远端路径。测试结束恢复原先需要的 Global Routing 姿态，并停止不必要的批量探测。涉及持续速度问题的分层方法，可继续阅读速度慢的网络、协议与线路检查，不要把延迟读数当作带宽测量。

怎样取得一段有用的 Log

Log 的价值不在于内容越多越好，而在于能够与一次明确操作对应。开始排查前，先记录当前网络、服务器、Global Routing 和启用配置；然后按当前界面的日志功能启用所需记录，发起一次失败访问，立即查看对应时间附近的内容。若界面提供不同记录范围，应选择足以观察问题的范围。长时间累积的混合日志包含大量无关连接，反而不容易确认哪个错误属于刚才的操作。

日志开关和记录范围的初始状态，以当前设备显示为准。建议日常保留满足实际需要的设置，在问题复现期间临时扩大记录，结束后恢复原值。不要把详细记录长期开启当作提升连接质量的方法，它只是增加观察信息。若需要清空旧记录，应先确认是否仍需留存诊断证据；更稳妥的是先保存经过脱敏的相关片段，再建立一个时间范围明确的新测试，而不是一边清空一边反复操作。

按请求阶段阅读，而不是只搜错误词

阅读时可按“目标识别、规则命中、地址解析、远端连接、协议交互、数据传输”的顺序寻找线索。实际日志未必完整展示每一阶段，也未必严格按这个顺序排列，因此只能依据已有证据判断。出现超时，首先要看超时发生在哪个对象：解析服务、代理服务器还是目标站点。它们对应的修复方向不同，不能看到同一个错误词就统一修改 DNS，或统一更换所有服务器信息。

如果记录显示请求命中了 DIRECT，当前问题应先从规则与本地直连路径检查；若命中了预期代理策略，再检查服务器连接及协议参数。认证失败应核对用户已有信息中的密码、标识或相关参数，证书错误应核对目标名称、时间与证书条件，不应把关闭验证当作通用修复方法。若没有出现预期请求，先确认日志范围、是否产生了新连接，以及该请求是否进入当前处理范围，不要据此直接认定应用未运行。

Data 中的读数怎样使用

Data 更适合观察累计变化，而不是证明单次连接是否成功。读取上传、下载和累计值时，需要先确定当前视图按什么对象统计，以及统计起点是什么。若当前界面提供按服务器或按应用查看，应分别理解分组依据。某个服务器已有历史读数，并不能说明它刚才仍然被使用；某个应用没有新增读数，也可能与连接复用、统计刷新或处理范围有关，应结合 Log 与真实操作再判断。

Data 与系统流量统计不完全相同是可以出现的，因为统计时间段、流量归属、连接开销和覆盖范围可能不同。对照之前，应先统一观察区间，记录操作前后的增量，而不是比较两个不同时间起点的总数。清零操作若可用，也只改变相应统计记录，不会修复连接；不要在未保存基线前清零，否则会丢失判断依据。需要区分服务器与应用视图时，可参阅Data 页流量读数说明。

分享诊断材料之前脱敏

日志与配置可能包含订阅地址、服务器信息、认证参数及访问目标。分享前应逐项检查，不只遮住一处密码：完整 URL 的查询部分、二维码内容、请求头、配置注释和截图边缘都可能带有敏感信息。通常只需提供问题发生时间、脱敏后的错误片段、当前姿态和复现步骤。保留上下文中的阶段信息即可，不必公开完整配置来证明问题存在。诊断完成后，也应按自己的资料管理习惯处理临时导出文件。

Widget 显示应当怎样核对

Widget 提供便于查看或操作的入口，其可用样式和行为以当前系统及应用提供的组件为准。系统可能限制后台刷新，所以组件上显示的状态不一定与刚刚发生的变化同时更新。遇到组件仍显示旧状态时，应先打开 Shadowrocket 的 Home 核对实际连接和所选服务器，再通过一次新访问确认。不要只凭组件文字判断连接已经建立，也不要因组件刷新较慢就修改协议、规则或 DNS。

添加或调整 Widget 后，先检查组件是否关联了预期内容，再分别测试从应用内改变状态、从系统组件入口操作以及设备重新解锁后的显示。若某种操作需要打开应用或系统确认，应按当前界面完成。系统授权、On Demand 条件与实际服务器可用性仍然有效，组件入口不能跳过这些环节。推荐只保留自己能够解释用途的组件，减少多个入口显示不同时间状态造成的误判。

iCloud 同步不是连接同步

iCloud 同步涉及可同步数据的保存与传递，不意味着两台设备会同时建立连接，也不表示两台设备的系统授权、当前网络和临时状态完全相同。具体同步范围以 Shadowrocket 当前提供的选项为准，不能把“列表出现了”直接理解为“所有设置均已复制”。核对时应分别检查服务器列表、配置文件、所选对象及应用级设置，尤其要在目标设备确认哪个 Config 实际启用。

同步相关开关的默认状态应在本机核对。需要跨设备管理已有资料时，先确认系统已登录预期的个人账户、iCloud 功能可用，并查看 Shadowrocket 的相关同步选项；不需要跨设备使用时，可以保留当前安排。开启同步前建议保留本地副本，因为同步不是带有固定历史记录的备份保证。误删除、覆盖或冲突处理的结果可能传播到另一设备，不能把另一台设备永远视为独立的恢复来源。

同步延迟与冲突怎样处理

两台设备列表不一致时，先核对账户与同步范围，再确认两端网络正常，并给系统完成同步的时间。不要立刻在两台设备上同时编辑同一份配置，也不要连续关闭、开启同步来强制刷新，这会增加判断难度。应选定一台作为本次编辑来源，记录其内容，再到另一台核对是否出现相应变化。若当前界面提供明确的导入、导出或恢复入口，应先理解它是合并还是替换，再执行操作。

处理冲突时，比较配置名称是不够的，同名文件内部可能已有不同规则。需要查看关键参数、规则顺序和用户自行记录的修改说明。保留两份副本进行比对，比直接覆盖更容易回退。同步完成后，在目标设备上重新核对所选服务器、Global Routing、VPN 授权和 On Demand，进行一次独立的访问验证。源设备正常只能证明源设备现场可用，不能替代目标设备的实际测试。

用户已有订阅与本地配置也应分开理解。同步一个订阅条目，不等于订阅内容此刻已经重新获取；远端订阅更新与 iCloud 数据同步是不同过程。若条目存在但列表内容仍旧，应检查相应订阅的更新结果，而不是只等待系统同步。订阅地址具有访问凭据性质，应按敏感资料管理，不应为了比较两端内容而把完整地址发到公开讨论区。此处只说明已有资料的管理方法，不涉及任何服务提供或推荐。

换机时分开核对购买与数据

App Store 中的购买资格、应用数据恢复和网络连接授权属于不同事项。已购应用能够重新获取，不代表所有本地配置必然恢复；配置已经恢复，也不代表新设备已完成首次 VPN 授权。换机时按“获取应用、检查资料、选择配置、完成授权、验证访问”的顺序核对。购买与重装流程见已购恢复说明。如果原设备仍可使用，应在确认新设备运行正常之前保留原数据，避免在迁移过程中失去唯一可恢复的副本。

两种端口不能混为一谈

Add Server 中的端口属于用户已有服务器连接信息，必须与远端实际监听的协议和端口一致；Settings 中若提供本地 Proxy 端口，则属于本机代理服务的监听参数，供适用场景中的客户端请求连接。修改本地端口不会改变远端服务器配置，也不能修复远端端口填写错误。检查时先写清楚“谁连接谁”：是 Shadowrocket 连接服务器，还是同一设备上的请求方连接本地代理入口。

本地 Proxy 相关选项的名称、可用协议与访问范围，以当前界面说明为准。本页不列统一默认端口，因为设备现场、已有设置和功能状态可能不同。若没有明确使用本地代理入口的需求，建议保留当前设置，不必为了普通 VPN 连接随意启用额外监听。确有需求时，应记录监听地址、端口、协议以及是否允许其他设备访问，并确认接入方所用协议与入口相匹配。

监听地址决定谁能够访问

仅供本机使用与允许局域网访问是不同的范围。地址为回环地址时，通常只供本机访问；若监听范围扩展到网络接口，则可能允许网络中的其他设备尝试连接。不能只看端口号相同，就认定两端能够互通。还需要检查设备处于同一可通信网络、网络是否隔离客户端、当前地址是否变化，以及系统和应用是否允许相关连接。这里的范围判断应以当前功能的实际说明和测试结果为依据。

开放更广访问范围之前，应确认是否真的需要，并采用当前功能提供的访问控制措施。不要把监听范围扩大当作本机连接失败的第一修复步骤。对于不熟悉的网络，应优先缩小可访问范围，避免让不相关设备使用代理入口。停止使用时关闭不再需要的监听或访问选项，并验证请求方已经移除旧设置。否则，应用状态变化后，仍指向旧地址的请求方可能持续失败，让问题看起来像整个网络异常。

冲突与不可达怎样区分

同一监听地址上的同一端口通常不能被多个服务任意重复占用。若界面或日志显示绑定失败，应先核对是否存在冲突、端口值是否符合输入要求，而不是继续调整远端协议。若服务已经监听但请求方无法访问，则转查地址、网络路径和协议选择。HTTP 与 SOCKS5 的接入方式不同，请求方填写错误协议时，可能出现连接已建立但请求无法完成的现象，不能仅凭端口可连接就判定设置正确。

排查本地入口时，应先在最小访问范围内验证，再按需求扩大范围。保持远端服务器与 Global Routing 不变，只修改一个本地参数，并同步更新请求方对应值。若改了端口却没有更新请求方，测试失败属于两端信息不一致，不代表新端口不能使用。测试记录至少包含监听范围、双方端口、接入协议与错误阶段；涉及网络地址时可脱敏保存，但不要删掉能够区分本机与远端角色的上下文。

把全部修改收束到可恢复状态

完成诊断后，按记录逐项收尾：恢复不需要的测试姿态，关闭临时扩大范围的记录和监听，确认 On Demand 条件仍符合需要，检查当前启用 Config，并用一个已知目标重新访问。不要用“恢复所有设置”代替逐项回退，除非已经明确它会影响哪些资料并保留完整副本。一次有效诊断的结果应当是更少的不确定项，而不是留下更多无法解释的开关。

若仍无法定位，整理当前网络、所选服务器、姿态、配置名称、复现步骤和脱敏日志，再按服务器、解析、规则、系统授权的层次逐步复查。新出现的问题优先检查最近一次变更；没有变更却突然失败，则核对本地网络和已有服务状态。需要重新走完整操作主线时，返回使用教程；需要按具体症状查找答案时，进入常见问题。保留能复现问题的最小现场，比继续叠加未经验证的参数更便于判断。