Settings 设置项参考

01 / Scope

设置范围与当前值核对

区分 Settings、Config 与系统授权

Settings 不是连接行为的唯一来源。可以把需要核对的内容分为三层：应用层保存测试方式、日志及部分通用偏好；Config 保存规则和配置文件中的相关参数；系统层决定 VPN 配置授权、网络访问条件及 iCloud 可用性。服务器条目还有自己的地址、端口和协议字段。遇到问题时，先判断它属于哪一层，再寻找对应入口。修改 Settings 不能纠正服务器地址的拼写，切换 Config 也不能代替系统弹窗中的授权确认。

同一个设置看起来没有变化，实际请求路径仍可能不同。例如 Home 选中的服务器变了，Global Routing 从 Config 切到了 Proxy，或者设备从 Wi-Fi 切到蜂窝网络，都会改变测试条件。查阅任何章节前，记录当前网络、所选服务器、Global Routing 姿态与当前 Config 名称。这四项是比较结果的基本上下文。若没有记录，只凭“昨天可以、今天不行”很难分清是设置变化、网络变化还是远端状态变化。

默认值、当前值与推荐值不是同一件事

默认值指特定安装状态下尚未修改的初始设置；当前值指此刻页面显示或配置文件保存的值；生效值则是一次实际请求最终采用的行为。恢复备份或同步数据后，当前值可能来自旧设备，不再等同于初始默认。本文对可变项采用“保留当前可用值”的推荐起点，尤其不建议为了对照手册而重置整个应用。若字段显示自动、空白或继承，也不要立即把它理解为关闭，先查它是否表示交由配置或系统决定。

建立一次可回退的修改记录

修改之前，保存当前配置的副本，并用私人记录写明项目名称、原值、新值、修改原因和验证结果。配置副本可能包含服务器凭据，不要放进公开笔记。一次只改变一个变量，例如先改测试方式而不同时改 DNS。修改后保存，必要时在允许中断连接的时段断开再连接，重新运行同一个目标的请求。若结果没有改善，就恢复原值，而不是继续叠加更多修改。这样可以保留一条明确的因果链。

验证时要区分“设置已保存”和“设置已被使用”。界面能返回上一页，只说明编辑动作完成，不说明旧连接已重建；浏览器成功显示页面，也可能来自缓存。对关键修改，应使用新的请求，并在 Log 中对照对应时间。涉及系统授权时，检查系统 VPN 状态，而不是仅看应用开关颜色。没有必要为查默认值删除应用，因为删除可能同时影响本地配置与记录，且不能保证恢复之前的可用组合。

如果问题只发生在某个目标，优先检查该目标的规则；所有目标都失败，再核对服务器、网络和解析。若不确定购买页面或应用身份，先查看正版核验三要素。设置参考不会改变购买范围，也不能替代已有服务器信息的正确性。常见症状的简短答案集中在问答页，适合先定位问题类别，再返回本页逐项查阅。

02 / DNS

DNS 解析与规则关联

先区分目标域名与服务器域名

DNS 把域名转换为连接所需的地址。一次代理请求至少可能涉及两类解析：设备要先找到服务器域名对应的地址，随后请求目标域名也需要在相应路径上完成解析。前者失败时，代理链路可能根本没有建立；后者失败时，则可能出现服务器测试有响应、特定网站却打不开的现象。因此，“更换 DNS”不是所有连接错误的通用处理，必须先知道失败的是哪个域名，以及解析发生在连接建立之前还是之后。

Settings 中的 DNS 相关选项需要与当前 Config 的内容一起看。如果正在使用的配置包含 DNS 指定或相关行为参数，不应只看一个页面就判断最终解析方式。默认状态以当前界面与生效配置为准，本文不指定一个适用于所有网络的公共地址。推荐从现有可用设置开始，保留配置提供的明确约定；只有日志显示解析错误、返回异常地址或解析路径不符合预期时，才针对该项排查。

按输入格式核对，不混填地址与协议

DNS 字段可能接受地址、服务器列表或应用支持的特定格式，具体以该字段说明和实际可选项为准。普通地址与带协议的解析地址不是可随意互换的文字。输入前核对是否需要协议前缀、是否包含多余空格、分隔方式是否正确，以及当前网络能否到达该解析服务。不要把网页地址直接当作 DNS 地址，也不要因为看到加密传输字样就假设它一定在当前网络上可用。解析服务本身同样需要建立网络连接。

如果服务器地址本身使用域名，还要考虑解析依赖关系。一个解析端点若必须经过尚未建立的代理才能访问，而建立代理又依赖它解析服务器域名，就可能形成启动阶段的循环依赖。处理这类问题时，先恢复原有解析设置，确认服务器域名可以在连接建立前得到有效结果，再单独验证目标域名的解析路径。不要直接把某次查到的地址永久写进服务器条目；远端地址可能变化，且某些协议还依赖正确的名称校验。

DNS 与规则匹配的先后影响

域名类规则与地址类规则观察的是不同对象。DOMAIN-SUFFIX 可以直接针对域名后缀匹配；GEOIP、IP-CIDR 等规则则与地址有关。为了判断地址规则是否匹配，处理过程可能需要取得解析结果。若只想让一个明确域名使用指定策略，通常应把具体域名规则放在较宽泛的地址判断之前，而不是先增加多项 DNS 改动。规则按照顺序处理，前面已经命中时，后面的示例不再承担同一请求的选择工作。

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

上述片段只展示规则关系，不是完整连接配置。example.com 与 example.org 是说明用域名，PROXY、DIRECT 是策略关键字。使用前须确认当前配置接受相应策略，并在 Global Routing 的 Config 姿态下验证。这里没有指定 DNS 服务器，因此不能从这几行推出解析请求一定走哪条路径。若要理解更多匹配对象，可继续阅读规则语法与匹配顺序说明。

解析问题的验证与回退

先用同一网络、同一服务器重复请求一个能稳定复现问题的目标，记下时间，再查看 Log 是否出现解析超时、名称失败或后续连接失败。解析成功而连接超时，重点已转向地址可达性；名称解析失败，则继续核对解析端点与网络条件。改变 DNS 后旧缓存不一定马上消失，复测时应建立新连接，并避免把缓存页面当作成功证据。没有明确改善时恢复原值，保留测试记录，不连续替换多个端点。

03 / On Demand

On Demand 自动连接条件

自动触发不等于连通保证

On Demand 用于按照配置的条件请求系统建立 VPN 连接。它解决的是“何时尝试连接”，不是“服务器是否有效”，也不是对所有应用流量的永久连通保证。启用前应先手动完成一次连接，确认 Home 中的默认服务器、Global Routing 与 Config 均符合预期，并通过 Connectivity Test 和实际目标访问验证。若手动连接尚未成功，自动触发只会重复同一个失败过程，使问题看起来更频繁，而不会修复地址或认证错误。

开关的初始状态、可选条件及已有规则，以当前界面为准；从旧设备恢复后尤其应检查是否带入了以前的条件。推荐起点是先保持手动控制，连接稳定后再按明确场景启用。需要自动连接时，逐项阅读条件，确认它针对的是网络环境、请求触发还是其他可配置范围。不要把某个条件名称理解成所有网络均适用，也不要假定列表中后面的条目一定能覆盖前面的行为。

按网络切换建立测试矩阵

自动连接常在 Wi-Fi 与蜂窝网络切换、离开一个接入点或设备唤醒后表现不同。测试前写清希望出现的结果，例如在指定网络内保持现状，在其他已允许网络中请求连接。每次只切换一个条件，等待系统完成网络变更，再查看系统 VPN 状态与应用记录。刚切换时短暂的连接中断并不自动说明规则错误，应结合触发时间和后续状态判断。反复开关网络会让多个状态变化叠在一起，反而难以定位。

为什么关闭后又出现连接

若手动断开后系统又尝试建立连接，先检查 On Demand 是否仍处于启用状态，以及当前条件是否持续满足。手动断开动作与自动规则是两种控制来源；前者并不必然取消后者。需要暂时停止自动行为时，应先在应用中关闭相应自动连接设置，再断开连接，并观察系统状态。若仍有重复行为，核对系统中实际正在使用的 VPN 配置，避免把另一份保留配置的行为归因于当前编辑页面。

设备可能保存多个 VPN 配置描述，当前应用页面显示的选择与系统实际活动配置需要对应。检查时不要直接删除所有配置，而应先确认名称、来源与当前状态。系统授权弹窗允许应用建立相关配置，不代表已经设置好全部自动条件。对于受组织管理的设备，部分网络或 VPN 行为还可能受系统管理策略影响；应用内开关无法代替这些系统要求，处理时应遵守设备的管理规则。

登录网络与恢复策略

需要先打开网络登录页的 Wi-Fi，可能尚未具备完整访问条件。在完成合法的网络认证之前，即使自动连接触发正确，也可能无法到达服务器。遇到这类情况，可暂时停止自动尝试，在系统允许的流程中完成网络登录，再恢复原有条件并复测。不要用不断修改服务器协议参数的方式处理尚未完成接入的网络，因为问题发生在代理连接之前，改动协议只会增加新的变量。

建立自动规则后，至少验证正常进入条件、离开条件和手动暂停三种情况，并保存原设置。系统状态、触发记录和实际访问结果应能互相解释。若规则过于复杂，先退回最少条件，再逐项加回；每次加回后都做一次网络切换验证。与自动触发无关的首次连接步骤见默认服务器选择与 Connectivity Test，不必为排查 On Demand 重做整套导入流程。

04 / Ping

Ping 与 Connectivity Test

测试结果只代表对应测试路径

Ping 相关设置影响列表测试采用的方式、目标或等待条件，具体字段以当前界面提供的选项为准。列表里的响应时间不是完整的网络质量评分，也不等于浏览网页所需的全部时间。一个请求还可能包含名称解析、建立连接、协议协商、远端处理与内容传输等阶段。测试方式不同，覆盖的阶段就不同，所以不能直接把两种方法得到的数字放在一起比较，更不能仅凭最小数字判断某个服务器适合所有用途。

默认测试方式和超时以当前设置为准；同步恢复或之前的手动修改都可能改变它们。推荐先保留原有测试参数，选一个稳定的已有服务器建立基准，再改变单项观察差异。如果当前界面支持 TCP 或其他连接型测试，它主要回答相应连接是否能在等待范围内建立；若使用需要请求目标的测试方式，测试目标自身的可用性也参与结果。测试失败可能是目标失败，而不一定是服务器条目失效。

固定目标、网络和时间范围

比较前应固定测试目标、当前网络、测试方式与服务器条目，并尽量在相近时间完成。网络从 Wi-Fi 换成蜂窝后，比较条件已经变化；把白天结果与高负载时段结果直接相减，也难以说明设置是否改善。可以重复少量测试，观察结果是否稳定，但不需要高频连续请求。测试本身会产生流量和连接，过度测试可能影响正在使用的连接，并把短时波动放大成错误结论。

超时表示测试没有在限定等待时间内完成，不直接说明地址永久不可达。等待值过短，可能把较慢但可用的路径排除；等待值过长，又会让失效项很久才返回结果。本文不设一个统一秒数，推荐先使用界面原值，再按实际测试目的调整。若多项同时超时，先确认设备网络和测试目标，不要逐个重写服务器字段。若只有单项异常，再核对该项地址、端口、认证信息和服务状态。

把列表测试与实际连接分开验证

列表中出现响应，不等于该条目已经被选为默认服务器。先在 Home 点选要使用的服务器，核对选择标记，再检查 Global Routing 的姿态。之后打开连接，使用 Connectivity Test，并访问一个能够稳定复现问题的目标。这样可以分别验证“条目可被测试”“当前选择正确”“连接路径可用”三个问题。只做第一项，容易把未被选中的服务器测试结果当成当前连接状态。

响应正常但实际访问失败

出现这种差异时，先看测试覆盖了哪些阶段。如果测试只到服务器端口，认证字段仍可能错误；如果测试目标可以访问，实际目标可能命中了另一条规则。接着检查 DNS、目标域名的策略和 Log 中的错误阶段。不要仅凭响应时间重复切换服务器，因为切换会同时改变远端出口与连接状态，让原始问题消失在新的条件中。保留一组能复现的条件，通常比收集更多测试数字更有价值。

对于 VMess、VLESS、Trojan、Hysteria2 等不同协议，端口能够连接也不能证明全部协议参数匹配。某些条目还涉及传输层、名称校验或其他服务端约定，必须与用户已有的服务器信息逐字段对照。协议字段的用途可参阅支持协议与 Add Server 字段概览。本页只解释测试设置，不根据测试数值评价服务商，也不据此推荐任何节点。

05 / Log

Log 记录与故障定位

先记录时间，再复现一次请求

Log 用于对照连接过程中出现的事件与错误，但不是每一条信息都代表故障。开始排查时，先记录设备时间、当前网络、默认服务器、Global Routing 和当前 Config，然后只执行一次明确操作，例如连接后访问一个目标。接着查找相近时间的记录，沿着名称解析、建立连接、协议处理、目标访问的顺序阅读。把整段日志不加区分地翻看，容易把前一次尝试的错误与这一次成功混在一起。

记录开关、详细程度和保留方式以当前界面为准，本文不假设所有安装都默认保存同样内容。推荐平时保留满足基本诊断的当前设置，排错时才临时增加可用的详细记录，并在完成后恢复。更详细的记录可能包含更多访问元数据，也会增加存储与阅读负担。若界面没有某项级别或导出选项，不需要寻找同名隐藏入口；以实际提供的功能为准即可。

按失败发生阶段缩小范围

日志中若首先出现名称解析错误，先查 DNS 和对应域名；若解析已有结果但连接等待结束，检查地址、端口与网络可达性；若建立连接后出现认证或协议相关失败，再核对服务器字段。目标返回错误响应，则还要考虑目标服务本身。这个顺序不是对所有记录的机械分类，而是减少无关修改的方法。没有解析证据时先改一组协议参数，或认证失败时不断替换 DNS，都容易偏离真正的故障阶段。

连接中断也可能只是网络切换或手动断开的结果。阅读时把日志时间与操作时间对应，确认它是否发生在从 Wi-Fi 切到蜂窝、启用 On Demand 或切换服务器之后。若每次相同操作都出现相似错误，才有较强的复现依据。偶发一次且随后恢复的记录，可以先保留观察，不必立即重置配置。对于无法稳定复现的问题，应收集发生条件，而不是用大量无关改动掩盖现象。

核对规则命中，不把目标与策略混淆

使用 Config 姿态时，日志如果提供策略或匹配信息，应核对实际目标是否进入预期策略。域名规则要写在能抢先匹配它的宽泛规则之前，FINAL 放在兜底位置。应用显示的目标域名、实际连接地址与策略名称是不同字段，不能只看到一个熟悉的域名就认定走了代理。若使用的是 Proxy 或 Direct 姿态，先理解当前姿态的作用，再判断规则是否“没有生效”。

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

这段示例中，example.com 本身先命中 DOMAIN 并使用 DIRECT；其子域名可能匹配后面的 DOMAIN-SUFFIX。它展示的是具体条件优先的结果，不代表出现两条相关规则就是冲突。修改时只调整需要改变的规则，并在相同目标上重新验证。若把两行交换，根域名可能先被后缀规则匹配。仅检查规则是否“存在”不够，还要检查顺序和实际请求名称。

保存与分享前处理敏感内容

日志可能包含服务器地址、目标域名、局域网信息、订阅链接或认证相关内容。公开求助前，应删除完整订阅地址及其查询参数、认证信息、个人可识别数据和不必要的访问记录。仅遮住服务器显示名称不一定足够，因为真正的地址可能出现在后续行中。最好保留最小复现片段：时间范围、错误阶段、已遮盖的相关字段和采取过的操作，而不是发送整份长期记录。

不要为了整理日志先删除仍有价值的证据。可先在私人位置保存必要片段，再按应用当前提供的方式清理记录。清理日志不等于清理配置，恢复配置也不一定恢复日志，两者应分别管理。如果日志为空，先确认记录是否启用、是否查看了正确范围，以及请求是否确实经过当前连接；没有记录本身不能证明请求成功或失败。常见错误的快速分流可从问答页的故障排查分类进入。

06 / Widget

Widget 与系统状态核对

便捷入口不替代完整设置页面

Widget 是系统提供的便捷展示或操作入口，其可用样式与功能以设备系统和应用当前提供的组件为准。它适合查看有限状态或触发所支持的操作，不适合代替 Home、Config 与 Settings 的完整核对。尤其在刚导入配置、切换默认服务器或调整 On Demand 后，应先回到应用确认实际选择，再使用 Widget。不能只凭组件上的一段文字，就推断当前配置、策略与服务器都已正确切换。

组件是否显示、放在哪个位置以及使用哪种尺寸，属于系统管理范围；应用内相关偏好则可能影响它能够读取或呈现的内容。两类设置要分开检查。默认展示以当前添加的组件及其设置为准，没有所有设备通用的推荐布局。推荐先使用信息最少、容易辨认的现有组件，仅在确有需要时增加其他入口，避免多个近似名称让用户误点到旧选择或误读状态。

状态延迟与连接状态不同步

系统组件的刷新由系统调度，并不保证与应用页面逐秒一致。应用内已经断开，组件仍保留上一状态，或刚连接时显示尚未更新，都可能需要进一步核对。遇到差异时，打开 Shadowrocket 查看当前连接，并对照系统 VPN 状态和一次实际请求，而不是连续点击组件试图强制刷新。连续触发连接与断开会产生新的状态变化，让原来只是展示延迟的问题变成真正的连接中断。

系统省电、设备锁定、后台调度与网络变化，都可能影响信息更新时机。这里不承诺固定刷新间隔，也不建议为了组件文字立即更新而长期改变系统电源策略。若组件持续显示异常，先确认应用能正常打开并读取当前状态，再查看组件是否需要重新选择其配置项。系统提供移除和重新添加功能时，可在记录原布局后尝试；这一步针对组件展示，不应连带删除应用或重置连接配置。

区分选中服务器与连接中的服务器

Home 中的选择、已经建立的连接以及 Widget 里显示的项目，可能在切换瞬间处于不同阶段。选择一个条目不自动证明旧连接已经按新条目重建；组件展示一个名称，也不证明该项当前可用。切换后应按应用当前行为确认是否需要重新连接，再做 Connectivity Test。若测试失败，返回 Ping、DNS 和 Log 章节排查，不要把问题全部归到 Widget 的展示设置。

对有多个相似名称的服务器条目，建议在用户自己的管理范围内使用容易区分的名称，但不要在名称里写密码、完整订阅地址或其他敏感内容。Widget 可能在旁人可见的位置显示项目文字，锁定屏幕上的展示尤其要结合个人隐私需求选择。名称只用于辨认，修改名称不能修复协议参数，也不会改变服务器真实能力；测试和配置核对仍必须针对实际字段进行。

与 On Demand 配合时的操作边界

通过 Widget 触发断开后，如果 On Demand 条件仍满足，系统可能再次尝试连接。此时应检查自动触发来源，而不是认定组件按钮没有响应。需要临时停止连接时，进入应用确认自动条件，再执行断开；准备恢复时，先确认原有服务器和配置仍正确，再恢复相应条件。组件是操作入口，自动规则是另一层控制，两者应在同一条验证链里解释，不能只观察最后一次点击。

如果组件点击后打开应用而不是直接完成预期动作，应以当前系统允许的交互方式为准；某些操作可能需要设备解锁、进入应用或完成系统确认。不要把所有交互都理解为后台静默执行。首次 VPN 授权仍应在系统弹窗中明确确认。组件适合已经验证成功的日常使用，首次配置和失败排查应在应用完整页面完成，这样才能看到必要字段和错误信息。

iPhone 与 iPad 的组件摆放和可用位置可能不同，系统要求及适用性以 App Store 页面标注为准。若需要从头建立一条清晰的连接流程，请返回使用教程；若只是显示延迟，不必重新导入已有订阅，更不必为了刷新展示反复改变 DNS 或 Proxy 端口。

07 / iCloud

iCloud 同步与配置恢复

应用购买、配置同步和系统授权分别处理

iCloud 同步用于在应用支持的范围内保存或交换数据，不能把它与 App Store 已购记录视为同一功能。已购记录回答“是否可以重新获取应用”，同步回答“哪些应用数据可以在设备间恢复”，系统 VPN 授权则回答“这台设备是否允许建立相应配置”。即使使用同一个账号体系，这三件事仍有不同入口和状态。换机后应用已经安装，不代表所有服务器、规则和连接授权都已完成恢复。

同步开关、可同步的数据类型与当前状态，以应用和系统界面为准。本文不假定 Config、服务器条目、所有 Settings、日志和系统授权会作为一个整体完整复制。推荐在源设备上先确认哪些内容纳入同步，再在目标设备逐项检查实际出现的项目。若界面提供独立的数据选择，就按需要启用，不为了“全都一样”而盲目打开全部选项。系统层的 VPN 授权仍应在目标设备上核对。

开启前确认账号、容量与一份独立副本

启用或排查同步前，先确认系统 iCloud 已登录、应用具有相应使用条件，并检查存储和网络是否可用。默认状态以当前设备为准，旧设备开启不意味着新设备必然采用相同状态。对仍在正常使用的配置，应先保存一份独立副本，并妥善保护其中的凭据。同步不是历史版本库，也不保证能找回每一次误改；一项错误被同步到其他设备后，仍需要可靠的原副本才能恢复。

源设备与目标设备同时编辑相同内容时，可能出现名称重复、内容不一致或覆盖选择。处理前先暂停双向编辑，选定一台保存完整可用内容的设备作为核对基准，再比较另一台的实际数据。不要连续在两台设备上删除和重建同名配置，因为这些动作本身也可能进入同步流程。若应用显示冲突或选择提示，应先读清保留范围，确认需要保留哪一份，再执行操作。

订阅更新不等于 iCloud 同步

Subscribe 更新是从用户已有的订阅地址重新读取数据；iCloud 同步是设备间的数据交换。前者受订阅地址、认证和格式影响，后者受账号、系统权限与同步状态影响。一个条目在新设备出现，不证明该订阅地址当前仍可刷新；源设备能刷新，也不保证目标设备已经收到最新列表。排查时先确认问题发生在“取回远端数据”还是“设备间传递数据”，不要把两种流程交替操作。

如果目标设备已经取得订阅条目，但更新失败，应核对订阅地址是否完整、是否过期以及当前网络能否访问，而不是反复关闭 iCloud。若源设备已经更新而目标设备列表仍旧，再检查同步范围和状态。具体刷新入口与失败分支见订阅手动更新与自动更新排查。任何含有访问凭据的订阅地址都应作为私人信息保存，不应写进公开的同步排错记录。

恢复后逐项验证，不整份照搬结论

恢复完成后，先检查 Home 列表、默认服务器选择、Global Routing、当前 Config 以及 DNS 相关设置；再核对 On Demand 是否符合新设备的使用场景。两台设备即使数据相同，也可能连接不同网络，受到不同系统权限和路由条件影响。因此，源设备能访问某目标不能作为目标设备已恢复成功的唯一证据。目标设备仍应独立完成手动连接、Connectivity Test 和一次实际访问。

需要重新获取应用时，从 App Store 已购项目或正版产品页处理，步骤见换机与已购恢复说明。购买适用性、系统要求与共享范围以 App Store 页面标注为准。恢复应用购买不包含用户自行管理的线路服务，也不意味着凭据长期有效。若恢复后缺少某项数据，先保留当前状态，再检查同步范围和独立副本，避免用反复重装代替有顺序的检查。

准备退出账号、停用同步或清理云端数据前，先确认操作影响本机、云端还是其他设备，并保存需要保留的内容。不要把“停止同步”直接理解成“删除所有副本”，也不要把“本机还有数据”理解成“云端一定已经备份成功”。以界面提示和实际核对结果为依据，能显著降低恢复过程中的误删风险。

08 / Proxy

Proxy 端口与最终验证

区分远端端口与本地监听端口

Add Server 中的服务器端口由用户已有的服务器信息决定，用于连接远端服务；Settings 中与 Proxy 相关的本地端口，属于设备提供本地代理入口时使用的监听参数。两者即使都是数字，也不是同一个字段。修改本地端口不会改变远端服务端口，更不能修复错误的服务器地址。排查之前先确定看到的是服务器编辑页面，还是应用的本地 Proxy 设置，避免在错误位置反复尝试数字。

本地监听端口的默认数值、是否启用以及允许的访问范围，以当前界面为准。推荐没有本地代理接入需求时保留现有状态，不为普通连接额外开放监听。确有需求时，先记录地址、端口、协议类型和访问范围，再配置调用它的一端。端口是连接入口的一部分，必须与监听地址和协议一起理解；只有一个端口数字，无法完整表达如何连接，也无法判断其他设备是否应当能够访问。

监听地址与访问范围的安全边界

仅本机可访问的地址与局域网可访问的地址，暴露范围不同。扩大监听范围之前，应确认实际需要、所在网络是否可信，以及应用是否提供访问控制。不要为了让另一个设备连通，就直接把监听扩大到所有可达网络。若只需要本机使用，应采用当前功能允许的最小访问范围。共享网络中的其他设备可能不受用户控制，因此本地代理入口应按真实用途管理，而不是把“能连上”作为唯一目标。

填写调用端设置时，地址应指向提供监听的设备，而不是远端服务器域名；端口应与本地监听值一致，协议类型也必须匹配。设备换网后局域网地址可能变化，旧地址失效并不一定代表 Shadowrocket 故障。排查时先确认两端处于预期网络、监听仍启用且地址未变，再核对端口和协议。不要在未确认这些基本条件前修改 DNS、规则或服务器认证字段。

端口冲突与连接拒绝的检查顺序

连接立即被拒绝、持续等待和连接后协议失败，是不同现象。被拒绝时先核对监听是否启动、地址和端口是否正确；持续等待时检查网络可达性及访问范围；建立连接后失败，再检查调用端所选协议与认证要求。端口冲突也可能使监听无法正常启动，但不能只凭一次超时认定冲突。应查看应用是否给出相关提示，并结合 Log 核对，不使用随机更换大量端口的方式试错。

需要改变本地端口时，先在允许中断的时间操作，修改后保存，并同步更新所有调用端。旧连接可能不会自动迁移到新端口，应重新建立测试连接。选用数值前确认字段接受范围及是否被其他本地用途占用，本文不指定一个统一端口作为必填值。若改动没有改善，恢复原来的监听设置及调用端配置，避免留下一端已改、另一端未改的不一致状态。

Proxy 入口仍需核对路由与配置

本地入口可以接收请求，不等于后续策略一定正确。还要核对 Global Routing、所选服务器和当前 Config。下面是独立的规则片段，只用于说明策略选择，不包含监听设置或服务器凭据。它不能单独替代完整配置，也不应覆盖用户已有订阅中的协议字段。把本地端口排查与规则排查分开，才能知道请求是没有进入应用，还是进入后走了不符合预期的路径。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

示例中的域名和地址段用于说明语法。DOMAIN-SUFFIX 匹配域名后缀，DOMAIN-KEYWORD 匹配域名中的关键字，IP-CIDR 面向地址范围，FINAL 作为末尾策略。REJECT 会阻止匹配请求，因此添加前应评估范围，不把宽泛关键字直接用于重要业务。Global Routing 处于 Config 姿态时，才适合用这类规则顺序解释普通分流结果；其他姿态应按其自身含义验证。

用一条闭环结束修改

最终验证分为入口与出口两段：先确认调用端能到达正确的本地监听，再确认应用选择了预期策略并完成目标访问。若入口已通而出口失败，回到 Ping、DNS 与 Log 章节；若入口未通，先查地址、端口和范围。完成后保存成功条件、原值和新值，关闭仅为排错启用的额外记录，恢复需要的 On Demand 状态。设置手册的目标不是增加更多开关，而是让每一项改动都有明确用途与可验证结果。