Shadowrocket 故障排查大全

开关打不开：先检查系统连接层

Home 中打开开关后立即回落，首先说明连接建立过程没有完成；这与开关保持开启、但网页打不开不是同一种故障。先观察系统是否弹出添加 VPN 配置的授权提示、是否出现具体错误，以及回落发生在点击后的哪个阶段。不要仅凭状态栏图标判断成功，部分设备的图标显示位置会随系统布局变化。应同时核对 Home 状态，并保留错误原文，而不是反复快速点击开关。

区分未授权、配置冲突与连接失败

首次启用时，系统需要确认添加 VPN 配置。若曾取消确认，返回 Shadowrocket 再次尝试，并在系统提示中完成授权；设备密码由系统界面处理。随后到系统 Settings 中查看 VPN 配置是否存在、当前启用的是哪一项。设备上保留多个 VPN 配置并不一定有问题，但同时启动另一项连接可能中断当前连接。先停止其他正在工作的 VPN，再单独测试 Shadowrocket，不要直接删除所有网络设置。

若设备属于学校或单位管理，授权开关不可操作、配置无法添加，或者系统明确提示受管理限制，应联系设备管理员确认策略。删除应用通常不能解除这类限制，也可能丢失本地配置。个人设备则先检查是否有自动启动的连接规则：手动停止后立即再次开启，未必是按钮失效，也可能是 On Demand 正在触发。先记录条件，再临时关闭相关自动连接行为，见耗电与 On Demand章节。

用最小配置判断问题边界

在 Home 确认已有一个参数完整的服务器，并明确选中作为默认服务器；仅导入列表、不选择默认项，不能构成完整测试条件。将 Global Routing 临时设为 Proxy，再尝试启动，目的是减少规则文件对判断的干扰。如果仍立即回落，应优先看授权、系统网络扩展状态或服务器字段错误；如果可以保持开启，原来的 Config 配置或策略引用就更值得检查。测试结束后恢复原来的路由姿态。

保存当前 .conf 文件和必要的服务器信息后，可以先正常关闭应用连接，再重新打开应用测试。若异常发生在网络切换之后，先确认当前 Wi-Fi 已完成登录认证，或蜂窝数据能够直接访问普通网页。系统要求网络登录时，代理连接可能先于登录完成而失败。可先断开连接完成认证，再启动 Shadowrocket；不要把登录页打不开直接解释为服务器失效，也不要在不明提示中输入订阅凭据。

什么情况下才重建系统配置

只有在网络正常、默认服务器明确、授权流程仍持续异常时，才考虑重建与 Shadowrocket 对应的系统 VPN 配置。操作前先确认应用内配置已备份，停止连接并关闭 On Demand，再在系统设置中识别准确的项目。移除该项目后回到应用重新发起连接，让系统重新请求授权。这个动作只解决系统连接配置层的问题，不会修正错误的地址、端口或密码，因此不要把它当作所有故障的固定第一步。

若系统升级后首次出现回落，先重启设备并复测最小配置，而不是连续重装。记录“能否显示授权提示、是否生成配置、是否保持连接”三个结果，后续定位会更明确。恢复后再逐项开启原来的规则、自动连接和附加设置。每恢复一项都测试一次；若某项刚启用就再次回落，就保留这条证据，回查该项依赖与配置内容。常见授权疑问也可在FAQ中查阅。

已连接无法上网：按四层顺序排除

连接开关保持开启，只能说明系统连接处于工作状态，不能证明当前服务器能够转发流量。先断开 Shadowrocket，用同一网络访问一个平时可达的网页，确认基础网络、无线认证和蜂窝数据权限正常。然后重新连接，依次检查默认服务器、Global Routing、DNS 与规则命中。每一步使用相同目标，并记录失败表现是等待超时、名称解析失败、证书提示还是服务端返回错误，几种表现对应的排查方向不同。

先看服务器，再对照三种路由姿态

在 Home 检查默认服务器是否仍指向预期项目，尤其是在订阅更新、删除旧项目或切换分组之后。用 Connectivity Test 查看连接结果，但不要把一个测试数值当作全部业务可用的保证。测试成功而目标打不开时，仍可能是目标路径、DNS 或协议传输差异。若已有其他有效服务器，可只替换默认项进行对照；切换后重新建立连接，避免把旧连接的表现误认为新服务器的结果。

三种姿态的测试不是要求长期使用某一项，而是建立可比较的条件。如果 Direct 可用、Proxy 不可用，应回查服务器参数及其网络可达性；如果 Proxy 可用、Config 不可用，应检查规则顺序、策略名称与当前启用文件。若三者都不正常，先回到基础网络与 DNS，不要直接添加更多规则。完成定位后恢复适合实际用途的 Config，并确认它引用的是已存在的策略。

按命中顺序检查规则，而不是只找关键词

[Rule] 通常按顺序判断，前面的宽泛规则可能先于后面的精确规则命中。下面片段只用于解释顺序，example.com 是演示域名，不能直接替代你的完整配置。DOMAIN-SUFFIX 覆盖该域名及其子域名；GEOIP 依据目标 IP 所属信息判断；FINAL 用于前面规则均未命中时的兜底。需要同时考虑解析结果、规则覆盖面和实际策略，不能仅看到文件里有 PROXY 就认定请求一定经过代理。

[General]
bypass-system = true
dns-server = system

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

若原配置使用自定义策略组，检查组名是否拼写一致、组内是否仍有可用项目，以及组当前选择是否随订阅更新发生变化。修改文件之前另存一份，避免同时丢失可恢复的基线。局部网站失败时，可先用一条针对该域名的临时规则验证方向；验证后再决定是否纳入正式配置，不要用宽泛 DOMAIN-KEYWORD 掩盖问题，更不要把 FINAL 提到前面覆盖后续规则。

把浏览器缓存与系统状态分开验证

浏览器可能保留旧页面、已有连接或先前解析结果，因此切换模式后应重新发起请求，而不是只观察原来的加载动画。关闭失败页面再打开，必要时换一个此前未访问的测试目标，并与另一应用的结果比较。若只有一个站点异常，先检查该站点本身的状态与证书，不要据此重置所有连接。若多个域名失败但已有连接仍工作，则按下一步检查 DNS，具体判断见DNS 专章。

服务器超时：核对参数与传输路径

超时表示在等待期限内没有得到预期响应，不等于密码一定错误，也不等于服务器一定停止工作。连接可能停在域名解析、地址可达、端口建立、TLS 握手或协议认证中的任一阶段。先保留测试类型与错误原文，确认是 Connectivity Test 超时，还是实际网页超时。某些服务器不响应特定探测方式，因此探测失败应结合真实请求验证，不能只凭列表中的一条状态删除已有配置。

先逐字段对照已有服务器信息

打开 Add Server 对应项目，与自己的服务商提供的信息逐项核对。服务器地址不要混入路径、空格或协议前缀；端口应与该入口要求一致。密码、UUID 等认证字段应完整保留大小写和字符，复制时特别注意末尾换行。不要因为字段外观相似而互相替代，也不要将订阅地址直接填入服务器地址栏。二维码导入后仍要检查协议类型与关键参数，导入成功只说明内容被识别，不代表参数在当前网络下有效。

表格是核对方向，不是通用填值模板。各字段是否需要填写，必须服从已有服务器的实际配置。更多协议说明见协议与参数概览。如果服务器信息来自订阅，应先尝试正常更新并比较字段，再决定是否手动编辑；直接修改订阅生成的项目可能在下次更新时被覆盖，导致暂时修好的参数又发生变化。

TLS、传输类型和 UDP 分开判断

当错误涉及 TLS 握手或证书时，检查设备日期与时间是否正确，以及服务器名称是否与服务端提供的信息一致。连接地址和证书验证名称可能不同，但只能按真实配置填写。不要通过关闭证书验证来长期绕过报错，这会掩盖名称错误、证书过期或连接对象不正确的问题。若使用特定传输，Host、路径等参数也需要与服务端一致；只核对地址和认证字段不足以完成诊断。

普通网页主要能证明相应网页路径可用，不能覆盖全部 UDP 场景。若同一项目浏览网页正常，而实时通信或依赖 UDP 的功能异常，应检查协议能力、服务器端条件与当前网络是否允许相关传输。使用已有的另一条可用配置进行对照时，只改变一个变量。例如同一网络换服务器，或同一服务器换网络；同时换协议、网络和 DNS 后即使恢复，也无法知道真正原因。

利用网络对照确定责任边界

在 Wi-Fi 下超时、蜂窝数据正常，提示问题可能与当前 Wi-Fi 的解析、端口或传输条件有关；但也可能是两种网络选择了不同地址。先核对解析结果和连接目标，再下结论。若多个网络都只有同一服务器失败，而其他已有服务器正常，就应向自己的服务商核对该入口是否变更。提供协议类型、错误原文与复现条件即可，不要发送完整密码、密钥、订阅令牌或包含全部字段的二维码。

确认服务端参数正确后，再回到本地测试：选定默认项、临时使用 Proxy、断开并重连、打开同一个目标。如果恢复，逐项恢复 Config 与自动连接。若始终失败，把“基础网络可用、其他服务器可用、该服务器在两个网络均超时”作为结论保留，比不断增加超时等待更有诊断价值。单纯拉长等待时间只能改变报错出现的速度，不能修正不可达地址、错误端口和不匹配的传输参数。

订阅更新失败：区分下载与解析

订阅更新至少包含两个过程：先取得远程内容，再把内容解析成服务器项目。无法访问订阅地址、认证失效与内容格式不匹配应分别处理。开始前保留现有可用项目与配置，记录错误原文、原有项目是否仍在，以及失败发生在手动更新还是自动更新。不要为了重试先删除整个订阅；当远程暂时不可达时，删除本地内容反而会失去最后一个可以使用的连接条件。

核对链接完整性与获取条件

订阅地址应从自己的服务商处取得，并确认是用于客户端导入的地址，而不是登录页面、帮助页面或账户中心地址。复制时核对开头、路径和查询参数，避免只复制可见的一段。订阅中的令牌具有访问意义，不应放进搜索框、公共笔记或公开截图。地址被换行显示并不一定有问题，但复制时加入真实空格、遗漏参数或把标点一起带入，都会导致失败。

若返回的是登录页、访问确认页或普通网页，说明请求到达的内容并非预期订阅。此时应核对服务商提供的导入方式与账户状态，而不是在 Shadowrocket 中反复切换协议。若提示认证错误，也先检查链接是否已被重置或失效；客户端无法替远程服务恢复一个已撤销的令牌。需要联系服务商时，提供错误状态与发生时间段即可，避免把完整访问地址发到公开讨论区。

判断更新是否依赖当前连接

某些订阅地址在当前基础网络无法直接访问，但通过用户已有的有效连接可以取得内容。先比较断开和连接后的更新结果，并记录当时使用的默认服务器。如果只有连接后更新成功，问题属于订阅下载路径；如果只有断开后成功，则可能是代理路径或其解析影响了下载。不要将这个结果推广为所有订阅都必须使用同一种方式，应以该地址在当前网络的实际表现为准。

遇到循环依赖时尤其要谨慎：远程订阅暂时取不到，而本地所有项目又已失效，不能靠不断点击更新生成新的可用信息。应从自己已有的服务器资料恢复一个明确有效的项目，或向原服务商确认访问条件。Shadowrocket 负责使用已有信息，不提供线路。设置更新策略前先保证手动更新可用，再检查自动更新触发条件；自动更新失败不应立即解释为订阅内容整体损坏。

下载成功但列表不对时检查格式

如果能够取得内容，却显示无法解析、项目为空或协议字段缺失，应核对订阅格式是否与导入入口匹配。服务器订阅和 .conf 配置文件用途不同，前者主要提供服务器资料，后者还可能包含路由、DNS 与其他设置。不要把两者简单互换，也不要因为扩展名看起来相似就选择入口。手动查看内容时注意其中可能包含认证信息，必要时只检查结构，不复制完整内容到外部工具。

更新后项目数量或名称变化不一定代表故障，远程内容可能已经调整。应先确认新列表中是否存在所需项目，再检查默认服务器与自定义策略组是否仍有效。若规则引用了已消失的名称，表现可能是更新成功但无法联网，此时应转到路由排查，而不是继续重复下载。先记下更新前后的差异，再恢复有效引用，可以避免把两个连续发生的问题误当成同一个错误。

完成修复后，保留一份可恢复的配置文件，并妥善保存自己的订阅来源说明。备份应放在受保护的位置，避免与公开文档混在一起。若曾公开暴露完整订阅地址，应联系原服务商处理令牌变更，再更新客户端中的地址；仅删除公开截图不能保证旧凭据失去作用。导入的完整主线见使用教程，本章只处理下载、解析与引用之间的故障边界。

速度慢与间歇中断：先建立可比较条件

速度慢可能指首次打开等待长、持续下载吞吐低、视频反复缓冲，或网络切换时短暂中断。这些现象并不等价，先描述清楚是哪一种，再选择测试。Connectivity Test 的延迟不能直接代表大文件吞吐；网页打开快也不能保证长连接稳定。建议固定一个合法可访问的测试目标，在相近条件下比较，不要把不同时间、不同站点和不同网络的结果混在一起得出服务器优劣结论。

先拆分本地网络、服务器与目标站点

断开连接后，先观察当前 Wi-Fi 或蜂窝网络是否也有明显卡顿。Wi-Fi 信号格数只反映部分无线状态，不代表上行带宽、拥塞和丢包都正常。可靠近接入点并暂停其他设备的大流量任务，再用同一目标复测。若直连已经慢，应先处理本地网络；此时切换代理协议或修改规则，通常不能解决无线干扰、基础带宽不足或网络登录尚未完成的问题。

基础网络正常后，保持网络和目标不变，仅切换用户已有的另一台有效服务器。如果只有一个服务器慢，重点回查该服务器路径、负载或服务端限制；如果所有服务器访问同一目标都慢，则可能是目标本身或共同路径问题。需要向自己的服务商反馈时，说明网络类型、目标类别和是否只有单一入口异常，不必提交完整认证信息。不要一次启动大量并行测试，测试本身也会占用带宽并影响结果。

区分解析等待、握手等待与持续传输

首次打开很慢、第二次明显变快，可能与 DNS 缓存、连接复用或目标缓存有关，不能立即断定是带宽问题。观察等待主要出现在打开前，还是页面已经开始加载后。若多个新域名都在开始阶段停顿，应查看 DNS；若名称解析后仍长时间等待，则回查服务器建立连接与 TLS。若加载开始很快但持续传输缓慢，才更适合检查拥塞、服务端吞吐和目标限制。

Config 与 Proxy 的对照也能帮助定位。Proxy 下表现正常、Config 下特定目标慢，可能是规则将请求送到不同路径，或自定义策略组选择了另一项目。查看当前文件与策略引用，而不是只确认默认服务器名称相同。若目标被 DIRECT 规则命中，列表里选中的代理服务器未必参与了该次请求。对照时重新发起请求，避免已有长连接继续沿用先前路径造成误判。

处理网络切换与长连接中断

从 Wi-Fi 切换到蜂窝数据时，设备地址和网络路径可能改变，已有长连接不一定能够延续。短暂恢复过程与持续无法重连应分开判断。若切换后新网页能够打开、旧会话仍卡住，可先重新建立该会话；若所有请求都停止，再断开并重连 Shadowrocket。记录是否每次网络切换都会复现，并检查 On Demand 条件是否在两种网络之间反复触发。

只在实时通信、游戏或其他特定业务中中断时，检查该业务是否依赖 UDP，以及服务器、协议和当前网络是否满足相关条件。不要因为浏览网页正常就排除传输差异，也不要盲目修改 MTU 或其他底层参数。确有依据需要调整时，先记下原值、一次只改一项，并用同样业务复测；无法证明改善就恢复原值，避免留下影响其他场景的长期副作用。

测试最终应形成一句明确结论，例如“同一 Wi-Fi、同一目标，仅服务器 A 的持续传输异常”，或“新域名首次访问等待长，但建立连接后速度正常”。这样的结论能直接指向下一步。单独记录一个最快数值意义有限，还应观察重复测试是否稳定、是否伴随重连以及是否受后台任务影响。完成测试后关闭临时探测，恢复原来的 Config，避免诊断流量继续影响日常体验。

DNS 问题：从解析与连接的边界判断

DNS 将域名转换为连接所需的地址。服务器本身可能使用域名，目标网站也可能使用域名，因此解析失败既可能阻止代理服务器连接，也可能只影响某些网站。常见表现包括新域名打不开、已有连接仍可用、同一服务器在不同网络结果不同。浏览器的错误提示可以作为线索，但不能只凭“打不开”就认定 DNS 有问题，应先排除基础网络与服务器端口不可达。

先恢复一个明确的解析基线

修改前保存当前配置，记录 [General] 中与 DNS 有关的原始设置。下面示例使用系统解析作为诊断起点，不代表适合所有网络，也不保证能满足每个域名的需求。先在当前网络确认系统解析是否正常，再决定是否继续使用。不要同时添加多组未经确认的解析设置；配置越复杂，越难判断请求到底经过哪一条路径，以及失败是来自解析器还是到解析器的连接。

[General]
bypass-system = true
dns-server = system

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

若原配置还包含远程解析、加密解析或特殊域名处理，回退时应注意这些设置之间的依赖。只改一行不一定真正恢复了基线，因为其他段落可能继续影响结果。对不熟悉的选项，应先复制文件、另建测试配置，再逐项删减或恢复。配置结构可参照.conf 文件分段说明，不要在不了解作用范围时直接拼接多个来源的片段。

不要用浏览器直接访问 IP 作为唯一证据

HTTPS 网站通常需要正确的域名、证书名称与请求信息。直接把 IP 填进浏览器，即使失败，也不能单独证明 DNS 正常或异常；即使某个 IP 能打开，也不代表原域名解析一定正确。更稳妥的方式是结合应用可见的请求或诊断信息，区分名称解析报错与连接建立报错，并对多个目标交叉检查。操作时注意日志可能包含访问域名，分享前按需要遮盖。

同一个域名可能返回多个 IPv4 或 IPv6 地址，不同网络也可能得到不同结果。若只有某种网络持续失败，记录实际使用的地址类别与连接结果，再检查对应路径。不要看到 IPv6 就直接认定它是原因，也不要把全局关闭某类地址当作固定步骤。诊断性调整应有对照、有恢复记录；如果只有一个目标的某个地址不可达，应优先处理局部路径，而不是改变所有请求的行为。

检查 Host 覆盖、规则与缓存影响

[Host] 中的静态映射可能让某个域名持续使用旧地址，即使外部 DNS 已变化也不会自动跟随。若仅固定几个域名异常，应查看是否存在相关映射，并核对其来源与用途。不要为绕过一次故障随意写入长期 IP 映射，目标地址可能变化，证书与服务路由也可能受影响。暂时移除映射前先备份，复测确认改善后再决定是否永久调整。

规则同样会改变解析后的连接路径。DOMAIN 类规则依据域名匹配，GEOIP 与 IP-CIDR 类规则依据地址相关信息判断，两者的命中条件不同。若域名被解析到一个并非预期的地址范围，后续策略也可能变化。因此应同时检查“解析到了什么”和“最终走哪条策略”。不要仅凭一条 GEOIP 规则的存在，推断所有目标都会按同样方式分流，更不要用宽泛规则覆盖尚未查明的解析问题。

调整后需要发起新的请求验证，已有连接或缓存可能暂时延续旧结果。可以重新连接、重新打开测试页面，并比较一个此前未访问的域名；不必每次都重置整台设备的网络设置。确认新请求稳定后，再恢复必要的自定义 DNS 选项。最终保留最少且用途明确的设置，并记下每项解决的问题，避免下次迁移配置时把已经失效的历史补丁一并带入。

耗电与 On Demand：检查持续活动来源

系统电池统计显示 Shadowrocket 有活动，不一定说明应用持续执行异常任务。代理连接期间，其他应用产生的网络流量也需要经过相应处理，因此应结合使用时长、流量规模、网络信号和连接是否反复重建判断。先记录耗电发生在待机、视频播放、文件传输还是网络切换期间，再与相近条件对照。不同天的使用场景差异很大，单看电池占比不能直接计算应用造成的额外耗电。

先排查重连、探测与高流量任务

如果设备在弱信号网络中频繁重连，建立连接、重新解析与恢复会话可能反复发生。先观察连接是否稳定，再考虑规则优化。对照时选择一个信号稳定的网络，使用同一台已有服务器，暂停非必要下载与云同步，并关闭诊断期间开启的连续探测。不要为了观察耗电而同时运行大量测速；测速会产生真实流量，反过来改变被观察的条件，结果不能代表日常待机。

持续日志记录、频繁连接测试和大量失败重试也值得检查。若此前为排错提高了记录强度，定位后应恢复日常设置，并妥善处理含敏感内容的记录。观察是否有某个应用在后台不断请求失败域名，或某项同步因连接不稳反复上传。此时应先修复对应的网络错误，而不是简单归因于代理开关。只有把请求来源与活动时间对应起来，才能决定该调整哪一层。

On Demand 与手动开关的关系

On Demand 按条件触发连接行为。若手动关闭后很快再次开启，应先检查是否存在仍满足的触发条件，而不是认定开关失灵。记录当前规则涉及的网络条件，以及设备是否正处于频繁切换状态。为了对照，可以临时关闭 On Demand，保持其他设置不变，观察手动连接是否稳定。测试后根据需要恢复，避免排错结束后遗忘自动连接已被关闭。

需要重新设置条件时，从简单、可解释的规则开始，确认它在目标网络触发、在非目标条件下不触发，再添加其他条件。规则之间若重叠，可能出现用户预期与系统实际判断不一致的情况。不要同时调整网络名称、触发行为和服务器选择，否则无法确定是哪项产生改善。对于学校或单位管理设备，应同时确认管理策略，避免把系统强制行为与个人 On Demand 配置混为一谈。

做一次可复现的耗电对照

选择相近的观察时段，保持屏幕使用、网络类型、服务器和后台任务尽量一致，分别记录连接稳定性、是否发热以及系统显示的活动。对照重点是模式是否重复出现，而不是追求一个适用于所有设备的百分比。若只有某个服务器导致频繁重连，按服务器超时章节处理；若仅在切换 Wi-Fi 时出现，则回查网络切换与自动连接，不必先更换全部配置。

规则过于宽泛可能让本可直接完成的请求也经过远程路径，但调整前必须了解原有意图。可以检查常用业务的命中情况，修正明显错误的分流，不能为了降低流量随意把所有请求改为 DIRECT。对有隐私或访问路径要求的业务，应保持符合自身需求的策略。性能优化的目标是减少无意义重试与错误路径，而不是牺牲正确性换取一个暂时好看的统计结果。

若关闭连接后仍持续明显发热或耗电，问题可能涉及系统更新任务、其他应用活动或电池状态，应回到系统层继续检查。Shadowrocket 开关与耗电同时出现，并不能单独证明因果关系。相反，若在稳定网络、低流量、关闭诊断探测的条件下仍能重复复现异常，应保留发生条件与脱敏记录，再按最后一章进行配置回退。一次可复现的对照，比多次无记录的重装更有价值。

更新后异常与 iPad：保留基线再恢复

“更新后开始出问题”描述的是发生顺序，不一定说明更新本身就是原因。同期可能还发生订阅刷新、系统升级、默认服务器变更或网络切换。先列出实际变化，保留当前配置与错误原文，再用最小配置复测。不要在没有备份时直接删除应用：本地服务器、配置与个性化设置可能因此丢失，重新安装后也未必能恢复。恢复流程应从可逆操作开始，最后才考虑重装。

把应用、系统与配置变更逐项分开

先确认基础网络正常，重新选择一台已知有效的服务器，临时使用 Proxy 并发起真实请求。若最小条件可用，逐项恢复 Config、自定义策略、DNS 与 On Demand；哪一步恢复后再次出现异常，就优先检查那一项。若最小条件也不可用，则按本页前面的授权、超时与 DNS 分支继续定位。不要把整个旧配置立即覆盖回来，否则会把尚未查明的问题重新引入。

iPhone / iPad 的应用更新在 App Store 中处理，系统要求以 App Store 页面标注为准。需要重新获取时，核对开发者 Shadow Launch Technology Limited、官方图标与应用 ID 932747118。iPhone / iPad 版 App Store $2.99 一次性付费，Mac / Windows / 安卓 / Linux 版免费。已有购买的恢复与平台下载方法见已购项目恢复说明，购买状态与本地配置备份应分别确认。

桌面与安卓恢复时的系统放行边界

Mac、Windows、安卓与 Linux 需要重新获取安装包时，进入全平台下载页选择设备，安装包由本站 /dl/shadowrocket/ 路径提供。Mac 应先在“关于本机”查看芯片，区分 Apple 芯片与 Intel，不要根据外观推断。重新获取前保留原有配置，确认下载来源与目标文件后再操作；不要在尚未完成参数排查时，把更换安装包当作服务器问题的修复方法。

这些平台的安装包没有代码签名，首次打开可能被系统拦截。Windows 遇到 SmartScreen 时，在确认文件来自本站后按“更多信息 → 仍要运行”处理；Mac 可在“隐私与安全性”中对该应用选择“仍要打开”。安卓仅对实际用于安装的应用允许“安装未知应用”，完成后可收回该权限。Linux AppImage 需有执行权限。更完整的提示与命令见安装放行表，不要全局关闭系统防护来解决单个文件的提示。

iPad 横屏、购买状态与配置迁移

iPad 横屏分栏可能让列表与详情同时显示。先确认正在编辑的项目与当前默认服务器是否一致：打开某个项目的详情，不一定意味着它已经被选为默认。竖屏和横屏切换后，仍按 Home 中的实际选择与连接状态判断，不要依据详情停留在哪一项推断连接对象。若页面布局变化导致找不到操作入口，可先回到列表层级，再按快速上手主线逐项确认。

在 iPhone 已经购买后，iPad 应使用原购买所用的 Apple ID 检查 App Store 已购项目。恢复应用购买不等于自动迁移所有服务器和 .conf 文件；两台设备能否连接，应分别检查已有订阅、默认服务器、路由姿态与系统授权。不要因为另一台设备正常，就跳过本机的授权和网络排查。迁移时先导入必要内容、测试连接，再恢复附加设置，避免一次搬入过多未知差异。

若 iPad 与 iPhone 在同一 Wi-Fi 下结果不同，先比较两台设备实际使用的配置与解析设置，再检查是否启用了蜂窝数据、不同的自动连接条件或系统管理策略。确认配置一致后，用相同目标和同一服务器复测。迁移文件与二维码都可能包含凭据，应使用受保护的个人传输方式，完成后清理临时副本。布局与购买细节可继续阅读iPad 使用与配置迁移说明。