导入完成只表示客户端收到了输入
用户把订阅地址粘贴进客户端并看到“添加成功”，最稳妥的解释是客户端接受了这段输入。它尚未证明地址属于当前账户、网络请求已经发出、服务器返回有效配置、正文能够解析，也没有证明新结果已经替换本地列表。
把按钮结果当成全链条成功，会让后续“列表为什么没变”只能靠反复重装猜测。本篇把过程拆为地址、请求、响应、解析、本地提交与缓存六个观察点，逐层保留证据。
先保护旧配置和回退能力
排查前记录旧列表数量、最近一次可用时间、客户端版本与当前配置名称。若客户端支持导出非敏感设置，可在本机保存；不要截取或上传包含完整订阅地址、节点凭据或二维码的画面。
不要先删除仍能工作的旧配置。新订阅失败时，旧配置既是回退方案，也是比较基线。删除后重新导入可能暂时恢复，但会同时改变缓存、排序和本地数据库，无法知道原问题发生在哪层。
第一层：地址是否来自自己的账户区域
订阅URL通常包含可识别账户或授权的令牌，持有者可能获得配置内容，因此应按密码级资料保护。只从自己已经核对的账户区域取得，不从公开群组、搜索结果或他人截图抄录。
页面显示品牌名称不代表地址属于当前账户。核对最终域名、账户状态、生成时间或页面提供的说明；若页面要求把地址交给陌生人代测，应停止。本站不会接收完整URL或二维码。
复制时最常见的是边界字符错误
移动端复制可能带入换行、前后空格或全角标点，聊天软件还可能截断问号后的参数。客户端若只做表面格式检查，仍可能把错误字符串保存为一条配置。
先在不联网的本地文本视图核对开头协议、域名和整段是否完整，但不要把内容贴到在线短链、二维码或解码工具。重新从账户页使用复制按钮通常比手工选取更可靠。
新旧地址是否代表同一份授权
账户页可能允许重置或轮换订阅链接。新地址生成后，旧地址可能立即失效，也可能在一段时间内并存。不能假设两个长得相似的URL指向同一权限状态。
记录哪一个地址是本轮取得、何时取得，以及旧地址最近成功时间。不要在多个客户端同时轮换后再比较，因为服务端限制、缓存和本地记录会一起变化。
账户网页变化不等于客户端已同步
账户页显示套餐、到期时间或节点数量发生变化，只能证明网页当前展示了新状态。客户端需要再次请求订阅资源，收到并解析后才可能更新。网页和客户端是两套观察窗口。
若网页也没有变化，应先处理账户或订单状态，而不是修改客户端解析设置。独立指南无法确认付款、续费或账户生效时间，也不会承诺服务端立即同步。
第二层：客户端是否真的发出请求
点击更新可能只把任务放入队列，随后因离线、后台限制、休眠或频率控制而没有发送。观察按钮是否出现进行中状态、是否有开始与结束时间、客户端日志是否显示目标域名和非敏感状态。
不要公开日志全文，因为其中可能包含URL令牌。只记录时间、状态码类别、超时位置和错误文字。若日志完全没有新事件，问题更接近任务没有启动或界面状态。
连接建立慢与服务器处理慢不同
网络请求先进行名称解析和连接建立，之后才等待服务器响应。高延迟网络会放大握手时间；连接超时与已经连接后长时间无正文，指向不同阶段。
同一设备在Wi-Fi和热点间做一次短窗口对照。热点成功只说明原接入网络参与，不足以断言DNS、运营商或区域线路中的具体一项。保持地址、客户端和时间窗口不变。
HTTP响应存在也可能是错误结果
MDN对Fetch API的说明指出，请求在收到响应头时即可得到Response，即使HTTP状态代表错误。客户端显示“请求完成”因此不必然意味着取得有效订阅正文。
常见的业务结果还可能是未授权、频率限制、服务器错误或重定向到登录页。普通用户不需要猜具体代码，只需区分“没有响应”“收到错误提示”“收到内容但解析失败”。
登录会话与订阅令牌可能是两种授权
有的账户页面依赖浏览器会话Cookie，而订阅URL自身携带令牌；也可能请求时仍需要有效会话。浏览器已登录不能自动证明客户端请求具备授权，客户端成功更新也不表示浏览器会话仍有效。
若客户端得到登录页面样式而非配置，可能说明请求被引导到身份验证；这只是机制推断，具体实现仍以可核对发布说明为准。不要把浏览器Cookie复制进第三方工具。
重定向会改变最终取得的对象
订阅地址可能经过规范化、区域分流或身份验证跳转。合理的重定向应仍落在可解释的域名与资源类型；若最终域名陌生、跳转次数异常或进入广告与登录收集页，应停止。
客户端不一定显示完整跳转链。可记录最终错误中的主机名，但不要使用会把完整URL上传到外部服务器的在线检测器。隐私边界优先于为了看清跳转而泄露令牌。
频率限制常被连续点击放大
短时间反复更新可能触发服务器或边缘层的频率限制。第一次只是慢，后续却稳定失败，并不一定说明服务持续恶化，也可能是测试行为改变了条件。
看到冷却、请求过多或稍后再试的提示时，记录时间并停止。等待一个完整周期后只做一次请求。不要用多个设备同时刷新来验证，因为它们可能共享同一账户或出口。
第三层：响应正文是否真的是配置
服务器返回200等成功状态，也可能给出HTML登录页、维护说明或通用错误页面。解析器期待特定文本、JSON、YAML或编码内容时，会把这些页面报告成格式错误。
记录响应类型、大小范围和解析器第一条错误，不保存或分享完整正文。若错误里出现HTML标签或页面标题，重点回到授权与重定向；若正文为空，检查服务端状态与缓存。
内容编码与字符边界会影响解析
订阅内容可能经过编码或压缩，客户端需要按约定解码。中间页面错误、代理改写、复制截断或不匹配的Content-Type都可能让解析失败。用户不应凭猜测手动反复Base64解码，更不应把私密内容贴到在线工具。
可核对发布说明是否指定兼容客户端或格式。若同一地址只在某一客户端失败，应记录客户端名称与版本；这说明解析实现可能参与，但仍不证明该客户端存在普遍缺陷。
单条坏记录与整份格式失败不同
有些客户端遇到一条无法识别记录时继续导入其余内容，有些会拒绝整份配置。列表部分更新、数量减少或出现默认名称，和完全没有变化是不同现象。
比较导入前后数量、分组名称与第一条错误即可，不要逐条公开节点。若只有部分内容缺失，向发布者反馈格式兼容性；不要自行修改远端订阅再分发。
客户端版本决定支持哪些语法
新配置字段可能要求较新的客户端，旧版解析器会把未知字段视为错误或忽略。反过来，新版也可能收紧校验，不再接受旧格式。版本关系应由发布说明和实际错误共同判断。
更新客户端前保留旧版和配置回退条件。不要因为解析错误从陌生镜像下载所谓兼容版；来源和签名仍需按Android、Windows或Mac设备页核对。
第四层：解析成功后是否提交到本地列表
解析器得到结构化结果后，客户端还要写入本地数据库、合并分组并刷新界面。存储权限、数据库锁、只读目录或应用崩溃可能让解析完成却没有持久化。
观察重启客户端后变化是否仍存在。只在当前会话出现、重启后消失，更接近本地提交或保存；从未出现则回到响应与解析层。不要用重装同时清空数据库来验证。
覆盖、追加与新建是三种导入策略
同一地址再次导入时，客户端可能覆盖同名记录、追加一个副本，或按URL建立新条目。用户看到列表数量不变，不一定是失败，也可能是原条目被原位更新。
比较更新时间、分组名称和代表性非敏感字段，而不只看总数量。若出现多个同名副本，首先核对哪一个是本轮记录，再删除明确重复项；不要一次清空全部。
排序变化会造成“没有更新”的错觉
新节点可能按延迟、名称、地区或手工顺序排列。列表顶部保持相同，不代表底层数据未变；客户端也可能保留用户固定排序。
先取消筛选或查看完整分组，记录总数和更新时间。不要为了验证排序而运行所有节点测速，因为大规模测试会引入网络负载并可能触发服务限制。
第五层：界面缓存可能继续展示旧状态
HTTP缓存可以复用仍被视为新鲜的响应，并通过ETag或修改时间验证内容；客户端自身还可能缓存解析结果和列表视图。远端响应缓存与本地界面缓存不是同一层。
RFC 9111说明缓存验证可能得到304并继续使用已存内容。对用户而言，重点是记录请求时间、响应是否重新验证、重启后列表是否变化，而不是把所有旧画面都称为缓存。
强制刷新不是第一步
强制刷新或清缓存会改变证据。若旧列表仍可用，先完成普通更新记录，再考虑客户端提供的单项刷新功能。不要删除应用数据、系统钥匙串或整个配置目录。
清理后恢复只证明被清理的状态参与，仍需结合前面的请求和解析记录。若清理造成账户退出或配置丢失，应先停止，避免继续扩大变化。
缓存键可能让相似地址得到不同结果
缓存至少会考虑请求目标，有时还结合请求头。两个仅令牌不同的URL对服务端是不同资源；相同URL在不同授权头或地区也可能得到不同响应。
因此，不要用他人的订阅地址测试自己的客户端，也不要以他人更新成功证明自己的授权有效。比较必须留在同一账户和同一地址范围。
时间戳应该来自哪里
客户端显示的“更新时间”可能是点击按钮时间、收到响应时间、解析完成时间或列表提交时间。没有说明时，不能把它直接当作服务端内容发布时间。
记录多个可见时间并注明含义。例如“21:05点击更新，21:06提示解析成功，列表仍显示昨日”。这种写法比单独截图一个时间更能定位。
多设备结果怎样解释
同一订阅在手机更新、电脑失败，说明地址和服务端至少能在某一环境工作，电脑客户端、网络或本地状态更值得检查。两台都失败则可能是共同地址、账户或远端问题，但也可能共享同一网络。
对照时优先让两台设备使用不同接入网络，或在同一设备换网络；不要同时替换地址。每轮测试仅保留一项差异，结论才有边界。
手机后台限制可能中断刷新
Android和iOS可能限制后台网络、低电量模式或长时间未使用应用的权限。点击更新后立即切到后台，任务可能被挂起。先保持应用前台完成一次，不必关闭系统省电保护。
前台成功、后台失败，只说明执行条件参与；应查看应用是否明确支持后台刷新。不要通过授予无关权限来换取后台运行。
桌面休眠会切断未完成请求
Windows或Mac在合盖、休眠、切换Wi-Fi时可能中断正在进行的连接。唤醒后界面仍显示旧进度，不代表服务端继续处理。
重新开始前记录休眠时间与原任务状态。若每次唤醒后失败而冷启动成功，重点检查应用恢复和网络重连，而不是重置订阅地址。
证书或系统时间错误属于连接安全
设备时间偏差、证书验证失败或HTTPS被拦截，会在取得正文前阻止安全连接。此类提示不能用修改订阅格式解决，也不应忽略证书警告继续。
先让系统自动校时，核对网络是否存在登录门户或组织代理。若证书主机名与订阅域名不符，应立即停止，不提交账户资料。
公共Wi-Fi登录页会伪装成格式错误
酒店、机场或咖啡店网络常在首次访问时返回门户页面。客户端期待订阅配置却收到HTML，可能报告解析失败。先用浏览器完成合法网络登录，再重新请求一次。
门户页面不应索取Kuromis密码或订阅令牌。若网络要求安装证书或描述文件，需由网络经营方明确解释；不确定时改用可信网络。
代理与网络扩展可能形成循环
客户端在更新订阅时可能沿当前代理请求，而当前代理又依赖旧订阅配置。旧配置失效后，请求无法完成，形成“需要更新才能联网、需要联网才能更新”的循环。
可在确认安全和账户状态后，短暂停止现有连接，使用直接网络完成一次更新。记录前后差异；不要导入陌生临时节点解决循环，因为那会引入新的来源风险。
服务器维护与本地失败的证据不同
同一时间、不同设备与不同网络都收到相同维护提示，支持远端事件；只有一台设备解析失败，而账户页和其他设备正常，更接近本地客户端。
公开状态页只作为背景。没有公告不能证明服务正常，有公告也不能替当前请求下结论。记录提示、时间和受影响功能即可。
更新成功但连接仍失败是下一问题
列表确实出现新时间和新内容后，连接失败应转到节点选择、系统权限或网络路径，不再继续重复导入。订阅更新和连接建立是相邻但独立的任务。
保留一个已确认更新的代表配置做测试，不要同时切换多个节点、协议和网络。否则会把解析成功后的诊断重新混成一团。
不要用节点数量评价更新质量
节点数量增加不保证可用性，数量减少也可能是维护、去重或方案变化。本文的成功标准是客户端取得并正确呈现当前授权内容，而不是达到某个固定数字。
本站不会虚构节点数、速度或实时状态。若账户页面有明确方案说明，以当前可核对资料为准；独立指南不替经营方解释商业变更。
隐私处理应贯穿每一层
地址层不公开URL和二维码；请求层遮住查询参数与授权头；响应层不上传正文；解析层只保留错误类别；列表层隐藏节点与账户标识；缓存层不导出整个数据库。
求助时使用脱敏模板：设备与系统、客户端版本、操作时间、停点、错误原文、已做的单变量对照。任何人要求密码、验证码、完整订阅或远程控制，都应停止。
一张四层检查表
地址：来自自己的账户区域、复制完整、未公开；请求：有明确开始时间、目标域名可核对、未触发频率限制；解析：响应类型符合预期、有具体错误或成功提示；列表：更新时间、数量或分组发生可解释变化。
再加两项保护：旧配置仍可回退，测试期间只改变一个条件。检查表用于减少遗漏，不是要求把每项资料上传。
案例一：请求成功却解析到HTML
用户点击更新后很快提示格式错误，日志只显示响应成功。浏览器打开同一主域发现会话已退出。合理推断是客户端可能取得登录页或错误页，而不是配置正文。
后续处理是从已核对账户区域重新取得或确认地址授权，而不是清空列表。这个案例不能证明所有格式错误都来自登录页，因此仍需看响应类型和提示。
案例二：解析成功但重启后消失
更新时列表短暂出现新分组，关闭客户端再打开又回到旧状态。请求和解析已有成功迹象，本地提交、数据库权限或多份配置文件更值得检查。
首先核对应用是否运行了多个版本、配置目录是否只读，以及退出时是否正常保存。不要再生成新订阅地址，因为地址变化无法修复本地持久化。
案例三：只有晚间更新超时
白天同一设备与地址正常，晚间Wi-Fi超时，手机热点仍能完成。证据支持原Wi-Fi或其上游在该时段参与，但不能直接归因某条区域线路。
按晚间网络对照方法记录短窗口结果，并减少重复更新。若热点也开始失败，应重新检查频率限制和远端提示。
案例四：列表数量不变但内容已更新
客户端采用原位覆盖，更新前后总数相同，但分组更新时间、备注或代表条目发生变化。只盯数量会误判失败。
比较两三个非敏感字段即可，不运行全量测速。确认内容更新后转到连接测试，不再重复导入。
从错误提示选择后续处理
无网络或超时：检查请求层；未授权或登录页：检查地址与账户；格式不支持：检查响应类型和客户端版本；保存失败：检查本地提交；更新成功但显示旧内容：检查筛选、排序与缓存。
提示无法解释、最终域名异常、要求上传订阅或关闭安全保护时停止。不要为了获得一个成功图标跨过身份与隐私边界。
最小化复测顺序
第一轮保持全部条件，记录失败；第二轮只换网络；第三轮若有必要只重启客户端；第四轮才考虑从账户区域重新复制地址。每轮之间恢复上一个条件，避免变化累积。
一旦某层取得明确证据，就停止重复该层。例如服务器已返回格式错误，继续切换Wi-Fi的价值有限，应转向响应类型和客户端兼容性。
什么时候可以判断已经恢复
恢复至少要满足：地址仍属当前账户、一次请求在合理时间完成、解析无错误、列表显示可解释的新状态、重启后结果仍保留。若目标是连接，还需另做一项代表性连接测试。
一次按钮变绿或列表闪现不够。另一方面，也不要求所有节点逐个测试；过度测试会制造负载和新变量。
版本升级前先读迁移说明
客户端大版本升级可能更换配置目录、数据库结构或字段名称。旧列表自动迁移成功，不代表订阅刷新逻辑完全相同；升级后首次更新应作为新基线记录。
若发布说明提到格式迁移，先备份本机配置并确认回退方式。不要在升级、换地址和换网络同一轮完成，否则出现差异时无法判断来自哪项变化。
系统代理与客户端代理要避免互相套叠
有些客户端既能提供系统代理，又会在更新订阅时读取系统代理。配置错误可能让请求指向自己尚未启动的端口，表现为立即拒绝或循环等待。
记录更新时客户端连接是否开启，以及系统代理是否由同一应用管理。只在已了解设置含义时做一次开关对照，测试后恢复；不要随意填写网上提供的代理地址。
错误日志需要按时间截取
日志往往混有启动、测速、连接和更新事件。反馈时只截取点击更新前后的一小段，并核对时间与当前尝试一致。旧错误即使文字相同，也不能代替本轮证据。
先脱敏完整URL、查询参数、账户标识、本地用户名和节点地址。若无法确定某字段是否敏感，宁可只抄写错误类别和状态，不上传原日志。
建立恢复后的基线
确认刷新成功后，记录客户端版本、成功时间、列表更新时间和所用网络，不需要保存敏感内容。下一次异常可直接与这条基线比较，而不必重新猜测正常状态是什么。
基线不是永久保证。账户、客户端和服务端都可能变化；它只证明某一时刻、某一环境曾完成整条流水线。后续结论仍要受当前证据限制。
结论：把刷新看成一条可观察流水线
订阅更新不是一个按钮，而是地址授权、网络请求、HTTP响应、格式解析、本地提交和界面缓存连续合作。任何一层都可能返回自己的“成功”，只有最终状态与前面证据一致，才算完成。
保留旧配置、保护URL、单项差异的测试顺序，是整条排查链最重要的三条纪律。完成四层记录后，可转到本站配置手册或故障索引继续处理；不要把敏感订阅交给任何独立指南代测。