Settings 设置项参考

01 · Settings 与默认状态核对

设置排查的起点不是恢复全部默认值，而是建立一个能够重复验证的基线。先在 Home 确认当前选择的服务器，再查看 Global Routing 的状态以及 Config 中实际启用的配置。Settings 中的某项修改只有放回这组条件里才有意义：同样的 DNS 值，在不同网络、不同规则或不同服务器下，结果可能不同。记录这三项后，再进入准备修改的设置页，保留原值、修改原因和测试结果。

默认值、当前值与建议值不是同一件事

默认值指应用在特定初始条件下采用的值，当前值则可能来自手动修改、导入配置或此前恢复的数据。已经使用过的设备不能仅凭某个开关的位置推断出厂默认状态。本手册不把无法在每台设备核对的数字写成统一默认值；涉及开关、端口和测试方式时，应先读取本机显示。建议值是一种适合当前用途的选择，也不表示它在所有网络下都更快。

如果需要核对默认行为，优先阅读对应项目的应用内说明，再检查启用的配置文件是否包含相关指令。不要为了获得一个“干净状态”就直接删除全部配置。删除操作可能同时丢失用于回退的服务器记录、规则和分组信息。更稳妥的做法是先备份现有内容，复制一份配置用于测试，并在记录里写明它与日常配置的区别。

先分清 Global Routing 的三种姿态

配置（Config）按当前配置中的规则决定请求去向；代理（Proxy）用于按该模式的代理路径处理流量；直连（Direct）用于直接连接。三者是不同的流量处理姿态，不是速度等级。日常需要规则分流时通常从 Config 开始；需要隔离规则影响时，可以临时切换并比较同一目标，但测试结束后应恢复原先姿态。切换姿态也不能补齐错误的服务器参数。

一次只改变一个变量

建议固定一个能够重复操作的目标页面，记录网络类型、连接状态和失败表现。修改一个设置后，按需要重新连接，再重新发起请求；如果同时更换服务器、DNS 和规则，即使恢复了访问，也无法判断是哪一项生效。需要回退时按修改顺序逐项恢复，而不是继续叠加新的设置。测试结果应描述“哪一步成功”，不要只写“感觉正常”。

还要区分应用范围与配置范围。Settings 中显示的全局项目、Config 文件中的指令、单个服务器的参数并不必然处于同一层。若某项修改没有产生预期效果，先确认修改的是正在使用的对象，再查应用内说明所描述的适用范围。不要假定所有同名设置都采用简单的覆盖关系，也不要把另一份未启用配置中的内容当作当前运行状态。

遇到入口名称与本文略有差异时，按功能和应用内说明核对，不要凭相似名称直接修改。完整的首次操作顺序见教程，按症状寻找排查分支可转到疑难解答。以下章节均沿用“读取现状、最小修改、实际验证、失败回退”的顺序。

02 · DNS：解析路径与规则检查

DNS 负责把域名解析为可用于连接的地址。域名解析成功并不表示后续连接一定成功，连接成功也不能单独证明使用了预期的解析路径。因此，排查 DNS 时需要同时观察域名、解析结果与后续策略。先核对当前 Config 中是否包含 DNS 相关指令，再查看 Settings 中实际可用的 DNS 项目及其说明；不要仅凭浏览器的一句错误提示就更换全部解析设置。

从现有可用配置开始，而不是直接替换

本机当前显示的值是排查基线，不应自动称为默认值。不同配置可能指定不同的解析服务器、查询方式或域名处理条件。日常使用已有配置且解析正常时，建议先保持现状；只有出现可重复的解析失败、返回地址不符合预期，或需要满足明确的网络条件时，再进行针对性修改。手动填写的地址越多，并不意味着可靠性越高。

在校园、办公或其他受管理网络中，内部域名可能依赖该网络提供的解析信息。把所有请求一律改交另一解析地址，可能导致内部站点失效。相反，某个解析地址在当前网络不可达时，也可能拖慢请求。要先分清“解析服务器无法连接”和“服务器返回了不符合预期的结果”，这两类情况需要不同的处理，不能只依据等待时间作判断。

域名规则与地址规则解决不同问题

DOMAIN-SUFFIX 按域名后缀匹配，GEOIP 则根据地址对应的地理信息作判断。它们处理的依据不同，不能互相当作完全等价的替代品。规则通常按顺序检查，因此更明确的域名规则应放在适当位置，FINAL 作为末尾的最终策略。以下片段用于说明顺序，不是一份可以直接替代个人配置的完整文件；其中 PROXY 必须是当前配置可识别的策略引用。

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

此例先处理 example.com 及其子域名，再检查地址条件，剩余请求交给末尾策略。实际选择 DIRECT 还是 PROXY 应由自己的访问需求与已有配置决定。不能通过复制片段就保证某个站点可访问，也不应把所有域名都归入同一策略来掩盖解析问题。希望只让指定网站走代理时，可继续阅读DOMAIN-SUFFIX 配置与验证。

分阶段验证，减少缓存干扰

先用同一域名重现问题，再检查请求记录中是否取得地址、匹配哪条规则以及连接发生在哪一步。修改 DNS 后，应重新发起请求；已有连接可能继续使用此前解析结果，浏览器或系统也可能保留缓存。必要时关闭相关页面后重新打开，并按应用提供的方式重新建立连接。不要把一次页面刷新就当作所有缓存都已清空的证据。

若只有一个域名失败，先检查拼写、域名规则和该目标本身；若多数域名都无法解析，再检查解析地址可达性与网络状态。若已经得到地址却在建立连接时失败，应转向服务器、TLS、路由或目标服务排查，而不是持续更换 DNS。使用地址直接访问也不总能作为对照，因为 HTTPS 站点可能依赖正确的域名和证书验证。

建议保存一组成功与失败的对照：同一网络、同一服务器、同一域名，仅改变待核对的解析设置。如果必须跨网络测试，应单独记录网络变化。出现内部域名异常时，优先恢复原解析条件验证；出现广泛失败时，先回退最后一次修改。将结果与 Log 中的时间对应起来，比反复切换多个地址更容易定位原因。

03 · On Demand：按条件连接与手动控制

On Demand 用于按照系统支持的条件触发或管理 VPN 连接行为。它处理的是何时尝试连接，不负责选择某个网站应该采用哪条分流规则，也不会自动修正不可用的服务器。准备使用这一功能时，先完成一次稳定的手动连接：导入自己的配置、确认当前服务器可用、检查 Global Routing，并验证实际访问。手动连接仍失败时，不宜先开启自动触发来增加变量。

启用前先读当前状态与条件

进入对应设置后，先记录总开关与已经存在的条件，再查看每个条件的适用范围。当前状态可能延续此前设置，不能仅凭重新打开应用就认为它已经恢复默认。如果界面提供按网络或条件细分的项目，应逐项核对；未显示的能力不要根据其他设备的截图推断。建议从最少的条件开始，只覆盖确实需要自动连接的使用场景。

触发条件与实际连接成功之间还有多个环节：系统需要识别条件、允许相应连接、建立网络通路，再由客户端完成服务器连接。若当前网络尚未取得可用地址，或者需要先完成网络登录，自动尝试也可能暂时失败。On Demand 的启用状态不应被解读为连接始终成功，更不能用来保证某个请求一定按预期完成。

网络切换时怎样观察

建议先在一个已知可用的 Wi-Fi 环境验证，再切换到另一种可用网络，观察 VPN 状态与应用内连接状态是否符合条件。每次切换后留出完成联网的时间，并发起一次新的访问请求。既有连接可能中断后重建，后台应用也可能保持旧状态，因此应以新的请求和当前记录为依据，不要只看切换前打开的页面是否仍然可见。

如果设置涉及 Wi-Fi 名称，应检查名称是否完全一致，尤其是大小写、空格与相似字符。相同名称也不代表处在相同的可信网络环境，因此名称条件只能作为连接逻辑的一部分，不能当作身份验证。设备上的其他 VPN 配置或受管理策略也可能影响连接结果；遇到互相切换的现象时，应先确认当前由哪个配置接管连接。

区分断开操作与自动触发

开启按需行为后，手动断开与后续条件再次满足是两个不同事件。若断开后又出现连接，应先检查 On Demand 条件，而不是直接判断开关失效。需要做明确的离线排查时，可先关闭相关按需行为，再手动断开，随后确认系统与应用的状态。排查完成后，再按原记录恢复设置，避免忘记自己临时改变过自动连接逻辑。

系统权限、设备管理限制以及当前网络状态都可能影响按需行为。若界面提示需要处理 VPN 配置，应阅读系统弹窗再操作；不要在看不清来源时反复确认。首次授权与日后的自动连接不是一回事，配置已经存在也不意味着所有条件都有效。无法确认当前状态时，先退回手动连接路径，验证基础网络与服务器信息。

推荐取值取决于是否需要自动触发，而不是统一要求开启。经常手动测试规则的用户，可暂时保持手动控制以减少干扰；已有稳定配置且明确需要按条件连接时，再启用并逐项验证。不要为了降低操作次数而一次添加大量条件。每增加一项，都应能说明它适用于哪个场景，以及发生意外连接时如何撤销。

如果连接时断时续，记录发生前是否锁屏、切换网络或完成网络登录，再与 Log 诊断对应。反复点击连接只能增加观察噪声。先停用自动触发、复现一次手动连接，往往更容易把问题分成网络、服务器与触发条件三条清楚的排查路径。

04 · Ping 与 Connectivity Test：测量边界

Ping 与 Connectivity Test 用于观察不同层面的连通情况，测试结果不是对全部实际访问的保证。首先应核对当前采用的测试方式、测试目标与超时设置，再解释结果。名称相似的测试可能检查不同环节：有的侧重主机或端口可达，有的会经过代理路径发起请求。必须阅读设备上的项目说明，不能把所有显示的毫秒数都理解为同一种延迟。

先确定测量对象，再比较数字

一次测量通常包含特定网络条件与目标条件。向服务器地址发起的测试，与通过服务器访问目标网页的测试，覆盖范围并不相同。前者成功只能说明相应路径上的某些环节可达，后者还可能受到域名解析、协议握手与目标服务影响。测试方式不同或目标不同的结果不宜直接排序，更不应把较小数字视为所有应用都会更快。

本手册不写统一的默认超时或测试目标，因为当前值可能已被修改，并且实际可用项目应以应用显示为准。建议先保留当前可用方式，用重复测试建立基线。需要调整时，只修改一种条件，例如保持同一目标而更换网络，或保持同一网络而比较测试方式。过短的超时会把较慢但可完成的连接判为失败，过长则会延迟发现不可达状态。

怎样做一次有解释力的测试

先确认服务器信息属于自己有权使用的配置，并核对地址、端口与协议。然后在同一网络下连续进行少量测试，记录成功与失败分布，而不是只保存最好的一次。若结果波动明显，应先排除网络切换、信号变化和设备正在进行的大量传输。不要同时运行多个测试任务，否则相互竞争的网络资源会让结果难以比较。

随后建立连接，访问一个能够重复验证的目标，检查实际请求是否完成。页面能够打开后，还应根据用途测试后续动作，例如继续载入资源或完成一次普通交互。首个响应快不代表持续传输稳定，单次下载表现也不能直接代表小请求延迟。测量应服务于正在排查的现象，而不是为了得到一个看起来更好的数字。

超时并不总是服务器不可用

某些网络会限制特定探测方式，服务器也可能不响应某类探测。因此，Ping 超时与实际代理请求失败不能画等号。若实际访问正常而探测失败，可以保留可用配置，并核对是否存在更适合当前环境的测试方式。反过来，端口可达也不能证明认证参数正确；密码、UUID 或 TLS 参数错误，可能在更后面的握手阶段才显现。

如果所有已有服务器都在同一时间出现相似失败，应先检查本机网络是否正常联网，再检查公共的解析或测试目标条件。若只有一个条目异常，则优先核对该条目的参数与服务状态。批量测试失败并不足以说明所有服务器同时故障，尤其当这些测试共享同一个目标时，目标本身就可能是共同影响因素。

对 TLS 类连接，应保留证书验证，不要为了让测试通过就随意改变安全相关选项。测试失败时先核对服务器地址、端口、域名与设备时间，再查服务端要求。协议参数的不同不能靠延长超时来修复；需要理解具体填写项时，可查阅Trojan 参数说明，但仍须以自己的真实配置为依据。

最终应选择“能够稳定完成所需请求”的设置，而非只追求最低测试值。把测试发生时间、网络类型和结果保存为简短记录，再到 Log 中寻找同一时间的失败阶段。这样可以区分测量方式不适用、基础连接失败与目标访问失败，避免在错误层面反复修改。

05 · Log 与 Data：从记录定位失败阶段

Log 的用途是解释一次真实请求经历了什么，而不是仅凭出现某个英文词就判定故障。开始排查前，先记下当前时间、目标域名、网络类型、Global Routing 与选中的服务器；再发起一次能够重复的请求，并寻找时间相邻的记录。多个应用会在后台同时联网，因此只按列表最上方的一行判断，很容易把不相关请求当成当前问题。

按解析、规则、连接与响应分层阅读

第一层检查域名是否被解析以及是否取得地址；第二层检查请求匹配到哪类规则、采用哪种策略；第三层检查是否成功建立到目标或服务器的连接；最后才看后续握手和数据传输。记录的具体字段以应用实际显示为准，并非每种请求都会提供同样细节。缺少某项记录也不一定说明该步骤没有发生，应结合记录范围和当前设置判断。

例如，能够看到域名与地址，但后面发生超时，说明应继续检查连接路径，而不应只修改 DNS。若请求稳定匹配到不符合预期的规则，则先检查 Config 和规则顺序；若策略正确但认证失败，重点转向服务器参数。只有把现象放回完整流程，才能避免因为一个看起来熟悉的错误词而跳过真正的失败环节。

日志级别与保留范围怎样选择

先查看当前日志相关选项及应用内说明，不把本机当前状态写成统一默认值。日常使用建议保持足以观察必要信息的范围；需要复现问题时，再临时增加相应记录。更详细的记录可能增加存储和处理负担，也可能包含更多访问上下文。完成诊断后应恢复日常设置，不需要长期保留每一次测试产生的全部内容。

不要在尚未保存有用信息时立即清空记录。更合适的顺序是先记录现象与时间，保存必要片段，确认已有回退依据，再按需要清理。重新连接可能让记录时间线发生变化，因此要标记每次连接与断开的时间。若失败偶发，记录“何时开始、持续多久、是否切换网络”通常比堆积大量没有上下文的日志更有用。

Data 统计不能直接等同账单

Data 用于观察应用能够统计到的流量信息。阅读时应先确认统计范围、方向、时间区间以及是否经历过清零。应用计数与系统计数、网络运营方或连接服务的计数可能采用不同口径；协议开销、计量起止点与刷新时间也可能不同。因此，Data 适合帮助判断某次测试有没有传输，不宜直接当作其他系统的结算依据。

出现持续增长时，先检查前台下载、媒体加载与后台任务，而不是立即认定某项设置异常。连接已经建立但数据没有明显变化，也可能只是尚未产生新的请求。建议先做一个短小、可重复的访问，再观察变化；不要为了验证统计而反复进行大量传输。需要长期比较时，应先统一统计窗口和清零时点。

分享前先移除敏感上下文

订阅链接、认证信息、访问地址和服务器标识都可能进入诊断上下文。公开讨论前，应检查完整文本，而不只是遮住画面中央的密码。保留错误类型、时间顺序和必要字段名称，替换能够识别个人账户或连接资源的值。若只需说明规则问题，通常不必提交完整订阅或整份配置。

最后将“观察事实”和“个人推测”分开写：事实是哪个请求在何时失败、匹配什么策略；推测才是可能由哪个设置引起。带着这份最小记录查看疑难解答，能够更快进入正确分支。排查结束后，回退临时开启的详细记录，并确认日常配置仍是原先选定的那一份。

06 · Widget：快捷入口与状态确认

Widget 适合作为日常查看状态或进入操作的快捷入口，不应替代 Home 中的完整核对。系统会管理组件刷新与交互方式，组件显示的内容可能不是此刻最新的连接结果。因此，当 Widget 与应用内状态不同，先打开 Shadowrocket 查看当前服务器、Global Routing 和连接状态，再发起实际请求。不要仅凭组件上的旧文字判断连接一直保持成功。

先区分组件展示与实际控制

不同设备环境可提供的组件样式和交互项目可能不同，应以系统添加组件时展示的选项及应用内说明为准。某些操作可能需要进入应用或经过系统确认；不能因为点击没有直接改变界面就判断功能失效。添加后先进行一次明确的验证：从断开到连接，再从连接到断开，分别观察应用内状态与组件何时刷新。

Settings 中与 Widget 有关的项目，应先读取当前值，再决定是否修改。本手册不规定一个通用默认样式，因为组件布局与系统支持范围会影响实际呈现。推荐只保留能够帮助日常判断的信息，避免让过多相似入口造成误操作。需要修改服务器、协议参数或复杂规则时，仍应回到应用内对应页面进行完整核对。

组件内容落后时怎样排查

先检查应用内是否已经完成状态变化，然后等待系统刷新并重新查看组件。如果应用内本身仍在连接，应先排查连接过程，而不是重建组件。若应用内正常、实际访问正常，只是组件信息未更新，可按系统提供的方式重新配置或重新添加组件。此时不要同时重置 Config、DNS 和服务器记录，它们通常不是显示问题的首要对象。

网络切换、锁屏和后台状态都可能改变观察结果。应记录问题发生在什么操作之后，并区分“组件没有刷新”“点击未完成操作”和“连接建立失败”三类现象。前两类属于展示或交互链路，第三类才需要结合 Ping 与 Log 检查网络。把三类问题混在一起处理，容易反复改变本来正常的连接参数。

与 On Demand 配合时注意动作顺序

如果 On Demand 已启用，组件触发的手动断开之后，条件再次满足可能引发新的连接尝试。这并不一定是组件按钮没有响应。验证时先暂时关闭按需行为，再单独检查快捷操作；确认正常后恢复按需设置，并测试二者配合的结果。每次测试都以应用内实际状态为依据，而不是只比较图标外观。

快捷入口也可能延续应用中原先选择的服务器和配置，因此操作前应清楚自己最后停留在哪个状态。临时测试完成后，如果没有恢复日常配置，下一次从 Widget 进入连接时就可能使用测试条件。建议在每次规则排查结束时完成一个固定收尾：恢复配置、恢复 Global Routing、确认服务器，再检查快捷入口表现。

控制信息展示范围

组件可能出现在容易被旁人看到的位置。若可配置展示内容，应考虑服务器名称和状态信息是否需要对外可见。给个人条目命名时，也不宜把完整账号、订阅地址或其他认证信息写进名称。名称用于辨认即可，详细参数保留在相应设置里；这既方便日常选择，也减少截图或屏幕展示时泄露上下文的机会。

组件显示的流量若来自应用统计，还应结合 Data 的计量边界理解，不能只凭组件上的数值判断全部设备流量。系统刷新节奏与应用统计窗口都可能影响显示。想比较一次访问前后的变化，应先在应用内确认统计范围，再完成受控测试，而不是在不同时间截取两个组件数字直接相减。

推荐把 Widget 保持为简短入口，将复杂修改留在应用内完成。若组件持续异常但应用与实际访问正常，先按展示问题处理；若三者都异常，再回到基础连接排查。这样既保留快捷操作的便利，也避免用反复重置连接设置的方法处理纯粹的显示延迟。

07 · iCloud：同步、备份与换机恢复

iCloud 同步与导出备份用途不同。同步用于在支持的范围内传递内容变化，备份则用于保留某个明确时点的副本；同步不等于拥有可以随时回到任意历史状态的归档。开始整理或换机之前，先确认应用实际提供哪些 iCloud 项目、当前开关状态以及可导出的内容，再保存独立副本。不要在尚未核对数据时同时修改多台设备。

先确认同步范围，而不是假定全部复制

应逐项核对服务器记录、Config 文件和应用设置分别采用什么方式保存或同步。不同内容可能具有不同处理方式，不能因为其中一份配置出现了，就推断所有密码、选择状态和统计记录都已经迁移。具体覆盖范围以应用内说明及实际结果为准。推荐先用一项容易辨认且不包含敏感信息的内容验证，再决定是否进行大范围整理。

在系统设置中确认当前 iCloud 账户与相关访问权限，并检查可用空间和网络状态。应用里的开关开启，只是同步条件的一部分，不是远端已经保存完成的凭证。出现内容未更新时，先检查这些基础条件，再观察另一台设备能否读取；不要通过连续开关或反复导入同一份文件来催促同步，这可能产生重复与难以辨认的副本。

换机按安装、核对、恢复、验证进行

先从 App Store 获取 Shadowrocket，购买与已购项目核对见恢复说明。应用的购买记录与个人连接配置不是同一类数据，恢复已购应用不表示服务器信息已经恢复。安装完成后，先确认 iCloud 条件，再按已有备份恢复所需内容。最后重新核对当前服务器、Config、Global Routing 与必要的系统授权。

首次恢复后建议先手动连接，暂不立即启用复杂的 On Demand 条件。选取一个熟悉的目标完成真实请求，再检查 DNS 与规则是否符合预期。若内容已恢复但连接失败，应继续检查服务器参数和当前网络，而不是直接把故障归因于同步。旧设备上的可用状态可以作为对照，但不要同时在两边做互相矛盾的修改。

处理差异与冲突时保留两份依据

两台设备都修改过同一内容时，不要假定系统一定会保留自己想要的那份。先分别保存本地可用副本，明确哪一份是准备继续使用的基准，再按应用提供的操作方式处理。对比时至少查看规则顺序、最终策略、服务器引用和必要参数。文件名称相同并不能证明内容相同，显示时间较近也不能代替实际核对。

如果出现重复条目，先确认它们是不同内容还是重复导入，再删除冗余项。不要仅按名称批量清理，因为同名服务器也可能有不同端口或传输参数。整理后应在一台设备上完成验证，再检查另一台设备的结果。涉及同步删除时尤其要谨慎：在确认影响范围之前，保留可以独立恢复的副本比追求列表整齐更重要。

备份也需要访问控制

导出的配置可能包含地址、密码、UUID 或订阅链接，不能因为文件名看起来普通就把它当作可公开资料。保存到自己能够控制访问范围的位置，分享前逐项检查；仅用于讨论规则时，另做一份去除个人参数的最小示例。备份成功的标准也不只是“文件存在”，还包括能够读取并辨认其中保存的内容。

日常建议在重要修改前保留一份已知可用副本，并记录它对应的用途，不必把每次无意义测试都作为长期备份。完整的换机顺序与恢复检查可参阅配置备份与 iCloud 迁移。完成迁移后再恢复自动连接和快捷入口，最后确认旧的测试副本不会被误选为日常配置。

08 · Proxy 端口：本地监听与访问范围

Proxy 相关端口首先要区分本地监听端口与远端服务器端口。Add Server 中的端口用于连接自己的服务器；本地代理监听端口则用于让支持相应代理方式的请求连接到设备上的监听服务。两者所在位置、用途和访问路径都不同。修改本地端口不会改变远端服务的实际端口，也不会修复认证信息错误，更不能代替已经失效的连接服务。

先核对协议、地址、端口三个条件

当应用提供相应监听设置时，应阅读实际显示的协议类型、监听地址与端口说明。HTTP 与 SOCKS5 是不同的代理接入方式，调用方必须选择匹配的类型。地址指出请求应连接哪里，端口指出具体监听入口；只填写一个正确数字，而协议或地址错误，仍然无法使用。不要根据其他设备的示例，把某个常见数字当成本机必然采用的默认值。

推荐只在确实存在调用需求时启用对应能力，并记录本机原值。若当前只使用 Shadowrocket 的正常 VPN 连接与规则分流，通常应先完成该主线验证，不必为了“设置完整”而额外改变监听项。不同入口可能有不同适用条件，应以应用内说明为准；界面没有提供的监听或访问控制能力，不应通过猜测配置字段来假定存在。

回环地址与局域网地址不是一回事

回环地址表示发起请求的设备自身。另一台设备填写回环地址时，指向的是那台设备自己，而不是运行 Shadowrocket 的设备。若用途确实涉及其他设备，应先确认应用支持相应访问方式，再核对监听范围、所在网络与必要的访问控制。不能仅通过把监听范围放大，就假定请求一定能够跨设备到达。

扩大监听范围意味着更多网络来源可能尝试访问该入口，应优先采用满足需求的最小范围。如果界面提供认证或访问限制，应按用途核对；如果无法确认访问边界，不宜把监听服务暴露到不受信任的网络。网络发生切换后，设备地址可能变化，原先填写的地址也可能不再适用。使用结束后，应恢复不再需要的访问设置。

连接被拒绝、超时与认证失败分开处理

连接被拒绝时，先确认相应监听是否启用、应用状态是否符合要求、端口是否填写正确。超时则还需要检查地址、网络可达性和访问范围。若已经连接却出现认证或协议错误，应检查调用方采用的协议类型以及双方要求。不要在尚未确认失败层级时连续更换多个端口，否则容易让调用方与监听方的记录失去对应关系。

测试时先保留正常 VPN 路径作为对照，再单独验证监听入口。调用方若支持代理配置，应只修改它自己的必要字段，并在测试结束后恢复；否则后续其他应用的异常可能只是仍在引用一个已经关闭的监听地址。一个应用可以通过代理访问，也不表示设备上所有应用都会自动采用同样设置，必须按实际请求范围确认。

把端口验证纳入完整收尾

本地入口可用后，还需要核对请求最终使用的策略与服务器。监听成功只是说明请求到达入口，不能替代后续解析、规则与连接验证。可结合 Log 寻找同一时间的请求，再确认目标响应。若没有对应记录，应先检查调用方是否真正使用了刚才填写的代理，而不是继续修改远端服务器参数。

最后按固定顺序收尾：恢复日常 Config 与 Global Routing，确认选中的服务器，回退临时 DNS 和日志设置，核对 On Demand，再检查 Widget。需要保留修改时，先更新自己的备份记录。若仍未定位问题，可按疑难解答继续排查，或回到教程重新走一遍最小连接流程；不要用更多无关开关覆盖尚未解释的现象。