设置范围与默认状态
先区分设置所属层级，再判断应该修改哪里。Settings 是应用设置入口，但一次连接还受到 Home 中的服务器选择、Global Routing 姿态、Config 中的规则和系统网络环境共同影响。只看到某个开关处于开启状态，并不能证明请求已经按预期处理。查阅时应把当前服务器、当前配置和连接状态一起记录，避免把不同层级的问题归到同一个设置项。
应用设置、配置文件与服务器参数
应用设置通常管理测试方式、显示、记录与系统集成等行为；Config 保存规则及相关网络配置；服务器条目则包含协议、地址、端口和认证参数。同一个“端口”出现在不同位置时，含义可能完全不同：Add Server 中的 Port 指向远端服务，而本地 Proxy 监听端口是设备上的服务入口。修改前先确认所在页面，不要按中文解释相似就互相代填。
导入用户已有的订阅，主要是取得服务器条目及其更新来源，不应直接推断当前规则文件也随之更换。应用更新、重新导入配置和切换服务器同样是不同操作。若某个值在更新后发生变化，应先检查更新的是哪类对象，再追溯它是否由导入内容覆盖。盲目重复导入可能使原有条目与新条目混杂，反而增加定位难度。
| 位置或对象 | 主要作用 | 验证依据 |
|---|---|---|
| Settings | 应用行为、测试与系统集成 | 对应功能的实际表现 |
| Config | 规则及配置文件中的网络设置 | 当前启用文件与请求记录 |
| Add Server | 远端服务器连接参数 | 原始服务器信息与连接结果 |
| Global Routing | 选择配置、代理或直连姿态 | 实际请求的处理路径 |
默认值不是所有设备共用的固定答案
本手册不把某次设备显示的数值当作永久出厂值。首次安装后的状态、旧设备迁移后的状态以及导入配置后的状态可能不同；部分选项还会随系统能力和应用实现调整。这里的默认状态核对，是指修改之前查看当前字段、帮助文字与当前配置，保留可恢复的记录。没有明确需求时，建议保留现值，而不是为了与某份清单一致而逐项改写。
记录时至少写清选项名称、修改前值、修改后值以及修改目的。若字段为空，不要自动理解为关闭或无效；空值可能表示使用系统提供的信息，也可能表示采用配置层的处理方式，具体应以该字段说明为准。不能确认空值语义时，先保留现状，再通过受控测试观察，不要用猜测的公共地址或数字填满所有空白项。
建立可以重复的修改与回退过程
建议先在稳定网络中完成一次基线测试：确认连接能够建立，打开一个常用页面，记录 Global Routing 与当前 Config。随后只改一个变量，用相同页面和相同网络复测。若同时改 DNS、服务器和规则，即使结果改善，也无法知道是哪一项起作用；若结果变差，也难以确认应恢复哪一处。逐项修改比反复重置更有诊断价值。
涉及连接核心参数的改动，若界面提示需要重新连接，应按提示操作；没有明确提示时，可在保存后主动断开再连接，以避免仍在使用旧会话。不要把旧连接继续可用当作新值已通过验证。回退时恢复原字段与原配置，再重复同一测试；如果恢复后仍然失败，说明还需要检查网络切换、服务器状态或系统层面的变化。
DNS 与域名解析
DNS 的作用是把域名解析为后续连接所需的地址。它与规则判断有关，但不能代替规则，也不能修复服务器认证失败。排查前先把现象分清：域名解析报错、已经取得地址却连接超时、连接成功但页面内容不完整，属于不同阶段。只有前一类直接指向解析过程，后两类仍需结合路由、传输和服务端响应判断，不能统一归为 DNS 问题。
核对解析设置来自哪里
先查看当前启用的 Config 是否包含 DNS 相关内容，再查看 Settings 中可用的 DNS 选项及说明。界面与文件同时出现相关字段时，不应仅凭位置认定谁一定覆盖谁；应确认该选项是全局行为、配置补充还是某种解析模式的参数。不同字段负责的阶段可能不同，名字里都有 DNS 不代表它们重复。修改后用新请求验证，而不是只看保存是否成功。
对于尚能正常使用的配置，推荐保留当前解析方式。只有在能够复现解析失败、需要使用自有解析服务，或已有配置明确要求某种处理方式时，才调整相关字段。填写地址前应核对界面接受的是单个地址、列表还是带协议的地址形式，不能把浏览器中的完整页面地址直接当作解析服务器地址；协议前缀、端口与路径也应遵循该字段支持的格式。
解析服务本身也需要被访问。若使用带加密传输的解析方式，其服务名称可能仍需要先获得地址，证书验证也依赖正确的名称和系统时间。因此，“改成加密解析”并不意味着此前所有网络条件都不再重要。出现循环依赖或连接失败时，应先恢复原解析方案，确认基础网络恢复，再核对新方案的可达性与配置语义，不要连续叠加更多解析地址。
域名规则与地址规则的区别
DOMAIN 与 DOMAIN-SUFFIX 可以直接依据请求中的域名判断；IP-CIDR、IP-CIDR6、GEOIP 则围绕地址条件工作。在需要地址信息的场景中，解析结果会影响后续判断；但请求是否保留域名、是否已经命中前面的规则，也会影响处理过程。因此，排查规则时应从上到下阅读，先确定命中了哪一项，再考虑 DNS 是否参与，不能只盯着列表末尾的地址规则。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY上述片段只说明规则顺序，不是一份完整连接配置，也不要求替换现有文件。example.com 是示例域名；私有地址规则用于展示地址段匹配；FINAL 处理前面未命中的请求。加入自己的配置前，需要检查已有规则、策略名称和预期路径。不要因为某段示例可以保存，就推断它适合所有网络，尤其应留意局域网资源和原有业务规则是否受影响。
缓存、网络切换与推荐验证顺序
修改 DNS 后，浏览器、应用或已有连接可能仍持有先前结果。先关闭正在测试的页面或应用会话，再按需要重新连接，使用相同域名发起新请求。不要要求某个解析结果必须返回固定地址：同一服务可能根据网络与负载返回不同地址。诊断重点是解析是否成功、请求走向是否符合规则，以及连接结果能否稳定重复，而不是地址文本是否与他人一致。
只在某个 Wi-Fi 下失败时，先确认该网络已经完成必要的网页认证，再检查局域网解析与当前 DNS 设置是否冲突。只在网络切换后短暂失败时，应区分缓存尚未更新和隧道尚未恢复。若恢复原设置后问题消失，再对新增字段逐项核对；如果原设置也失败，则继续检查基础网络和当前服务器，不应在同一处不断更换解析地址。
On Demand 按需连接
On Demand 管理的是系统在匹配条件下如何触发或保持连接，不是按域名选择代理或直连的规则列表。前者回答“什么时候建立连接”，后者回答“连接建立后怎样处理请求”。如果把两者混为一谈，容易出现已经设置域名规则，却期待系统自动开启连接，或者设置网络条件后，以为所有请求都必然经过某个服务器的误解。
先确认手动连接，再增加自动条件
首次配置时建议先保留当前 On Demand 状态，通过 Home 手动建立连接，确认已有服务器信息、Config 和 Global Routing 可以正常工作。只有手动路径已经稳定，自动触发才有明确的验证基础。若手动连接本身失败，应先修复基础连接，再考虑按需条件；自动触发只能启动相同的连接过程，不能补足失效的认证参数或不可达的远端地址。
查看 On Demand 页面时，应逐项核对界面提供的网络类型、网络名称或其他匹配条件，并确认保存后的实际规则。不要根据别人的截图假设自己的设备具有完全相同的选项。网络名称需要按实际显示填写，近似名称不等于同一网络；若多个条件存在，先阅读界面对匹配与例外的说明，再决定是否组合使用，避免规则范围比预期更广。
没有明确自动连接需求时，推荐维持手动控制；确有需求时，从一个能够反复验证的条件开始。例如只针对自己常用的某种网络状态测试，观察进入与离开条件时的行为，确认后再补充其他情况。不要一次覆盖全部网络，因为任何异常都会同时影响日常连接，用户也难以判断是条件匹配问题，还是连接建立阶段的问题。
系统授权与网络切换的边界
首次建立连接时，系统可能要求允许添加 VPN 配置。该授权让系统建立相应的网络连接配置，并不表示订阅内容或服务器参数已经验证通过。授权之后仍需要完成实际连接测试。若先前拒绝了授权，应依据系统当前提示重新进行允许操作；不要把反复切换 On Demand 当作重新获取权限的固定方法，也不要删除其他用途的系统配置来碰运气。
从 Wi-Fi 切换到蜂窝网络时，旧连接可能中断，新连接需要在新的网络条件下重新建立。此时页面短暂等待，不必立即判断按需规则失效。应先确认系统实际网络已经切换，再查看 Shadowrocket 的连接状态，最后发起新的请求。若网络尚在认证、信号不稳定或当前服务器在新网络不可达，自动触发即使成功，也无法保证目标请求立刻完成。
系统允许的后台行为与前台应用行为并不完全相同。不能把“离开应用后界面不再实时刷新”当作隧道一定断开，也不能把状态图标仍显示当作所有请求都成功。验证应结合当前连接状态和实际访问结果。若另有系统网络管理配置参与连接，应先明确各自用途，避免在不了解影响范围时同时调整多套自动连接条件。
停止连接、回退与异常定位
启用按需连接后，手动断开又重新出现连接，可能是系统再次匹配了触发条件，而不一定是按钮没有响应。需要持续停止时，先检查 On Demand 是否仍在要求连接，再按当前界面方式停用相关触发规则，然后断开。操作后等待状态稳定并发起一次普通请求确认，不要快速连续点击开关，这会让建立与断开的过程交错，难以判断最终状态。
排错可以按固定顺序进行：先暂时停用按需条件并验证手动连接，再只恢复一个条件，观察是否触发；随后在触发成功的前提下核对请求路径。如果从不触发，检查条件与系统授权；若能触发但访问失败，检查服务器、DNS 与规则；若频繁重连，则记录发生时的网络类型及切换过程，而不是首先扩大自动匹配范围。
Ping 与 Connectivity Test
测试数值只能说明某种测试方法在某一时刻的结果，不能直接代表全部业务的可用性。Settings 中的 Ping 相关选项用于调整测试行为；Home 中的 Connectivity Test 用于发起相应检查。阅读结果前，先核对测试方法、测试目标以及是否通过所选服务器。不同方法覆盖的网络阶段不同，把它们混在一起比较，得到的排序往往没有实际意义。
测试方式分别证明什么
如果界面提供 TCP 测试，其主要关注指定地址与端口的连接建立情况。端口能够建立连接，不等于协议认证、加密协商和目标访问都已完成。若提供 HTTP 测试，还需要确认目标地址以及请求是否经过代理路径；能得到响应通常覆盖更多环节，但依然只针对该目标和该次请求。测试名称相近，也不能省略对路径与条件的核对。
遇到超时，应先判断超时发生在测试目标还是服务器连接阶段。远端服务器可能可达，而测试目标暂时无法响应；目标也可能正常，但当前网络到服务器的路径失败。不要把一次失败直接等同于服务器永久失效。先用相同方法重复测试，再核对基础网络与测试目标，并对照一次真实请求，才能把偶发现象与持续故障区分开。
| 观察 | 可以说明 | 不能单独说明 |
|---|---|---|
| 端口连接成功 | 该次传输层连接可建立 | 协议认证与页面访问都成功 |
| 测试目标响应 | 该次测试路径得到响应 | 所有目标与所有协议都可用 |
| 测试超时 | 规定时间内未完成该测试 | 故障必然发生在服务器端 |
目标、超时与重复次数怎样选择
对于测试地址，建议保留当前可验证的设置，或使用自己能够稳定访问、用途明确的目标。不要为了让数值看起来更小而不断更换目标，这样会失去前后对照。若测试目标使用域名，解析也可能成为整个测试的一部分；如果页面发生跳转或要求认证，最终行为也可能不同于预想的简单响应，应先确认该目标适合当前测试方法。
超时时间没有适用于所有网络的统一最佳数字。设置得过短，可能把高延迟但仍可用的连接判为失败；设置得过长，则会延后发现明显不可用的路径。首次排查推荐保留当前值，在稳定网络中观察，再依据实际失败分布调整。若一次请求经常接近阈值，先检查网络与服务器，而不是只通过延长超时掩盖持续问题。
重复测试应保持间隔和条件一致，避免在设备正在大量上传、下载或网络切换时进行排序。短时间集中测试多个条目还可能引入并发负载，使结果偏离平时使用。更有意义的方法是选少量已有条目，在相同网络下重复观察，并以实际业务是否稳定作为补充。不要把一次较小读数当作长期优先选择的充分理由。
测试通过但实际访问失败
先核对实际请求的 Global Routing。测试某个服务器，不等于当前业务请求一定使用它；在 Config 姿态下，请求可能命中 DIRECT，也可能被其他策略处理。接着查看 Config 中与目标有关的规则，再检查域名解析及请求记录。若只切换服务器而没有确认命中规则，可能一直在比较一个根本没有参与该请求的条目。
协议参数也会造成“基础测试正常、应用请求失败”的差异。例如涉及 TLS 的连接，还需要正确的服务名称与证书验证；涉及 UDP 的业务，不能仅凭一次 TCP 连接结果判断。已有服务器参数应按原始信息核对，而不是为了让测试通过随意关闭验证。Trojan 字段的具体边界可阅读Password、SNI 与 Allow Insecure 填写说明。
恢复测试设置时，应把目标、方法和超时一起恢复到记录值，再重新测试同一条目。如果恢复后结果仍变化，说明网络状态或远端响应也在变化，不能将全部差异归因于刚才的设置。最终保留一份简短记录：网络类型、测试方法、是否成功、实际请求结果。这样的记录比一张没有条件说明的数值截图更便于继续排查。
Log 与 Data 诊断
Log 用于观察事件与错误，Data 用于观察流量统计，两者应互相补充，不能互相替代。统计增长只能表明有数据经过对应统计口径，不能保证某个页面完整加载；日志出现连接建立，也不能保证后续业务响应成功。诊断时先提出一个具体问题，例如“这个域名是否命中直连规则”，再收集对应记录，避免无目的地长时间开启详细记录。
记录范围与建议开启方式
先在 Settings 中查看 Log 相关选项，区分当前是否启用、记录详细程度以及可查看的内容。实际可用项目以界面为准，不把某个设备上的日志等级当作所有设备默认值。平时建议保留满足基本排错的当前状态；出现可复现问题时，再临时增加所需记录。完成排查后恢复原状态，以减少额外记录量及不必要的本地敏感信息留存。
复现前先记下当前时间与准备访问的目标，然后只执行一组明确动作，例如打开一个页面并等待结果。记录量较大时，可先按界面支持的方式清理旧记录，再开始测试；清理前如需保留证据，应先做脱敏备份。不要一边批量测试服务器一边复现单个页面故障，否则测试请求和业务请求会交织，难以确认哪条错误属于目标操作。
查看错误时，应沿发生顺序阅读，而不是只搜索最后一条失败文字。解析失败可能导致后续连接无法开始，认证失败可能发生在传输建立之后，而远端关闭可能是更早错误的结果。记录中若只显示简短分类，应结合前后事件理解，不要把每个相似错误都归到同一个字段。修改后的复测也应保留同样的操作顺序。
用 Data 对照请求路径
Data 中的上传与下载通常是观察一段时间内活动的入口，但读数必须结合当前视图、统计范围和重置状态理解。不同视图未必采用完全相同的归类方式，不能把其中两项直接相减后当作精确结论。测试前先记下基线，随后只发起目标请求，观察相关读数是否变化；这样比对照一个已经积累很久的总量更容易判断。
设备上的其他应用可能同时进行同步、消息接收或后台访问，所以测试期间总流量增长不一定来自刚才打开的页面。若需要确认某个服务器是否参与，应查看能够关联该服务器的统计或请求记录，再与规则命中情况核对。仅凭总量增加，既不能证明目标使用了代理，也不能证明某条规则已经按预期生效。
页面失败但仍有少量数据增长，也并不矛盾。连接建立、认证交换、失败响应和重试都可能产生数据；完整内容是否返回是另一个问题。反过来，页面从本地缓存显示时，界面看似打开却可能没有新的网络请求。验证规则时应确认确实发起了新请求，必要时换一个可控页面路径，而不是反复刷新同一份缓存内容。
脱敏、分享与诊断闭环
日志与配置可能包含订阅地址、认证参数、服务器地址、访问域名以及查询内容。分享前应删除完整凭据与不必要的个人信息，尤其注意链接查询部分可能携带认证信息。不要认为只遮住密码字段就足够，也不要直接公开整个配置文件。需要展示结构时，可把业务域名替换为 example.com，并保留错误类别和规则类型等必要上下文。
一份有效的排错说明应包含：预期行为、实际现象、网络类型、Global Routing、当前 Config，以及已做过的一次单项修改。可以附上脱敏后的相关记录，但不必提供所有历史内容。如果问题涉及应用获取或系统兼容性，应回到 App Store 页面核对；若涉及远端账户有效性，则应使用用户已有服务的管理信息确认，而不是从日志猜测权限。
Widget 与系统入口
Widget 是查看状态或访问常用操作的系统入口，其具体形式取决于应用提供的组件与系统当前支持的能力。它不是独立的代理配置，也不会替代 Home 中的服务器和 Global Routing。第一次使用时，应先在应用内完成连接验证，再添加组件；这样出现差异时，能够区分组件显示问题与连接本身的问题，不会在多个入口之间反复修改同一状态。
组件设置与系统添加是两件事
Settings 中出现 Widget 相关选项时，通常需要先理解它影响的是组件内容、显示方式还是快捷操作。即使应用内已经配置相关内容，也仍需按照系统提供的组件添加流程，把对应组件放到支持的位置。反过来，系统中存在组件也不代表其中所有操作已经完成初始化；首次使用前应打开应用，确认当前配置和系统授权均处于可用状态。
不要把不同系统界面中的入口名称视为永久固定。系统可能提供不同尺寸或不同位置的组件，展示的信息量和允许的交互也可能不同。选择时应以当前设备能够添加的项目为准，优先采用满足日常查看需求的简单布局。若某个选项在本机没有出现，不要通过修改网络参数寻找它；先核对系统兼容性与应用中的实际功能入口。
推荐先保留默认显示内容，再根据需要减少不必要的信息。若组件位于他人容易看到的位置，应考虑服务器名称、状态文字或统计内容是否会暴露使用习惯。自定义名称可以帮助辨认，但不要把密码、订阅地址或认证信息写进条目名称。显示字段属于便捷入口的内容设计，不应承担保存敏感连接参数的用途。
状态刷新与操作结果怎样核对
系统组件的显示更新不一定与应用前台界面完全同步。网络切换、连接建立以及系统调度期间，组件可能暂时显示较早状态。遇到显示差异时，先打开 Shadowrocket 查看 Home 的实际连接状态，再发起一次请求验证。不要仅凭组件上的文字决定连接已成功，也不要因为组件暂未刷新就连续执行相反操作，造成状态反复变化。
从组件发起操作后，系统可能需要打开应用或显示确认界面；应按当前提示完成，而不是把中间页面视为失败。操作是否完成，应回到实际连接结果判断。若当前 On Demand 仍要求连接，组件执行断开后也可能再次触发建立连接。这种情况应查阅按需规则，而不是反复删除并重新添加组件，因为后者不会改变触发条件。
如果组件不显示预期内容，先确认添加的是正确组件及正确尺寸，再核对应用中的 Widget 设置。随后打开应用等待初始化完成，并按系统方式重新加载组件。只有在应用内连接本身异常时，才进入 DNS、服务器与规则排查。将显示问题和网络问题分开，可以避免为了修复一个界面读数而误改原本正常工作的连接参数。
后台、耗电与系统权限的边界
组件存在、应用留在后台、系统网络连接正在工作，是三个不同状态。不能因为应用界面离开前台就断定连接停止，也不需要为了让组件刷新而不断重建连接。系统对后台更新有自己的调度方式，应用内的网络记录则反映实际请求。若要确认某个时间段发生了什么，应结合 Log 与 Data，而不是仅依据屏幕上是否仍显示应用。
耗电也不能只由某个开关解释。频繁重连、大量请求、网络信号差以及详细日志记录都可能增加活动。比较前先固定网络与使用方式，再一次只改变一个条件。不要在网络持续切换、后台同步繁忙时对组件或 Ping 设置做耗电结论。若某次改动后出现异常，应先恢复该改动并复测，再判断是否存在稳定关联。
iCloud 同步与 Config
同步、备份、导入和订阅更新应分开理解。同步用于让支持同步的内容在设备间传递；备份用于保留一个可恢复副本；导入用于把外部内容放入当前应用；订阅更新则根据已有来源刷新相应条目。这几件事可能在相近入口出现，却不意味着覆盖相同数据。换机前先列清需要保留的服务器、配置与本地设置，再选择对应方法。
先确认同步范围与系统条件
使用 iCloud 相关功能前，应核对设备是否登录预期的 Apple 账户、系统是否允许应用使用相关云端能力，以及当前网络是否能正常完成同步。随后阅读 Shadowrocket 当前入口对同步范围的说明。不要假定所有 Settings 值、连接状态、系统 VPN 授权与历史日志都会同步；未明确列入范围的内容，应在新设备上逐项核对。
同步开关的当前状态不等于云端已经保存最新内容。修改后应给系统完成传递的时间，再到另一台设备确认对应条目是否出现且内容一致。若系统提示存储或网络问题，应先解决这些条件，而不是重复导入同一份文件。反复导入与同步并行发生时，可能产生同名条目，使用户难以判断哪份才是最新且准备使用的对象。
建议在大规模编辑前保留一份明确命名的备份，并注明其用途与保存时的配置状态。同步不能自动代替历史备份，因为误删或误改也可能被传递。备份中若包含凭据，应保存在自己可控的位置，避免通过公开链接分享；文件名也不要包含完整订阅地址。恢复测试最好先从少量条目开始，确认结构与内容正确后再继续。
Config 文件选择与导入后的核对
导入 Config 后，先检查文件是否完整、规则是否可读、策略引用是否能够对应当前环境，然后确认它是否真正被选为当前使用文件。文件出现在列表里与文件已经启用不是同一件事。若目标是恢复旧设备行为，还应核对 Global Routing 是否处于 Config 姿态；否则即使选中了同一文件，实际请求也可能绕过原先的规则判断。
阅读配置时，从整体结构进入细节，先看规则顺序和最终处理，再看域名、地址段及相关网络设置。不要把别处摘取的一行直接追加到文件末尾，因为它可能位于 FINAL 之后，无法产生预期效果。编辑前复制原文件作为回退对象，编辑后保存并确认启用的是修改后的副本，避免在同名文件之间切换却误以为修改没有生效。
[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY该示例展示更具体的规则放在前面：example.com 本身先匹配 DOMAIN，相关子域名再由 DOMAIN-SUFFIX 处理，其他请求交给 FINAL。它只是规则片段，不能替代完整服务器信息。实际使用时应明确每条规则的目的，核对现有策略和域名范围。若配置来自用户已有来源，也应先阅读改动内容，再决定是否应用，不能只根据文件名称判断用途。
多设备冲突与恢复顺序
两台设备同时编辑同一内容时，应先确定哪一份作为保留依据，再等待同步稳定。不要在双方持续修改的情况下反复删除重建，否则更难辨认最终结果。可先暂停其他设备上的编辑，在一台设备确认内容，再到另一台核对。恢复过程中尤其要检查同名服务器的地址与协议参数，而不是仅凭显示名称认为它们完全一致。
换机建议按“取得应用、恢复数据、核对当前配置、完成系统授权、实际测试”的顺序进行。应用购买资格与配置数据是不同对象，前者按 App Store 的已购与兼容性处理，后者按实际备份或同步范围恢复。恢复后仍需检查本地 Settings 和 On Demand，不应默认旧设备所有行为都已复制。购买恢复步骤可查看已购恢复说明。
订阅更新后条目变化时，先确认更新来源和条目归属，再检查自定义编辑是否仍被保留。不要把远端条目刷新理解为 iCloud 冲突，也不要为了保留本地名称而随意改动认证参数。若需要整理，先备份并明确哪些内容由已有订阅管理、哪些由自己维护，保持职责清晰，才能在下一次更新后继续追踪变化。
Proxy 端口与验证流程
Proxy 端口首先要分清本地与远端。服务器条目中的 Port 是连接远端服务的目标端口，必须与用户已有服务器信息一致；Settings 中如出现本地 HTTP 或 SOCKS5 服务相关端口，则是设备提供本地代理服务时的监听入口。两者不要求相同，也不能互相替代。没有本地代理服务需求时，建议保留相关功能现状，不为“优化速度”随意开启额外监听。
监听地址、端口与访问范围
端口需要与监听地址一起理解。只允许本机访问的入口，与允许局域网其他设备访问的入口，暴露范围不同。设置前先阅读界面关于绑定范围与访问权限的说明，确认是否确有让其他设备连接的需求。不要只因为知道端口数字，就认为其他设备一定能够访问；网络隔离、地址变化、系统限制和服务是否运行都会影响结果。
如果需要手动填写本地端口，应选择界面允许且未被其他服务占用的值，并记录原值。不要把远端服务器的 Port 直接复制到此处，也不要通过随机改数字解决所有连接错误。保存后先确认服务可以启动，再由预定使用方按正确协议访问。HTTP 入口与 SOCKS5 入口属于不同协议，单纯把它们的端口互换，不能让使用方自动获得兼容。
本地服务测试应先从最小访问范围开始，确认能够工作后再评估是否需要更广范围。若设备网络地址发生变化，使用方保存的地址也可能失效。不要把地址变化误判为服务器失效，更不要在没有访问控制认知的情况下开放到不受信任的网络。停止使用后，应按实际入口关闭服务，并核对是否仍有其他设备持续尝试连接。
Global Routing 决定后续请求处理
本地代理入口能够接受连接，不等于后续请求一定经由所选远端服务器。最终还需要核对 Global Routing 和当前配置。Config、Proxy、Direct 是三种不同姿态：配置、代理、直连。日常有分流需求时，通常应在确认规则正确后使用 Config；Proxy 与 Direct 更适合在明确理解影响范围的前提下用于需要统一路径的场景或临时诊断。
| 界面词 | 中文说明 | 核对重点 |
|---|---|---|
| Config | 配置姿态，依据当前配置处理请求 | 启用文件、规则顺序与策略引用 |
| Proxy | 代理姿态，以代理路径处理请求 | 所选服务器与实际连接结果 |
| Direct | 直连姿态，不经所选代理服务器转发 | 当前网络到目标的直接可达性 |
排查某个域名时，可以在保留原状态后，用 Direct 与 Proxy 分别做临时对照，再回到 Config 检查规则。但对照只是缩小范围：直连成功、代理失败，仍需检查代理路径上的解析、认证与目标响应；两者都失败，则还应考虑目标本身和当前基础网络。测试结束必须恢复原姿态，避免把临时诊断状态误当成日常分流设置。
按阶段定位，而不是同时改全部参数
先判断连接是否建立，再判断域名是否解析，随后判断规则是否命中，最后检查目标响应。若根本无法连接服务器，优先核对 Address、Port、协议及认证信息；若已连接但只有部分域名失败，再看 DNS 与规则；若只有特定业务失败，则结合传输类型和服务端要求。WireGuard 的字段不能按普通密码协议套用，可查阅Private Key、Peer 与 MTU 参数说明。
涉及 MTU、UDP 或特殊传输参数时，推荐保留已有配置提供的值，只有在问题特征明确且具备对照条件时才调整。数值越小或开关越多，并不自然意味着更稳定。每次变化都要对应一个可检验的假设，例如是否只有某类请求在特定网络失败。验证没有改善就恢复原值，不要让多次试探留下一个无法解释来源的设置组合。
完成修改后，做一次覆盖日常需求的收尾检查：确认当前服务器与 Config，核对 Global Routing、On Demand 和临时日志状态，再分别测试常用页面、必要的局域网资源及网络切换。保留有效结论和回退记录，删除不需要的临时副本。若仍有问题，带着脱敏后的现象与测试条件查阅分流规则与连接排查 FAQ，不要通过反复重置掩盖尚未定位的原因。