外链平台：大量链接同日失效时如何区分源站故障与逐条失效
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d2ce76bdca86.html
📄
外链平台：大量链接同日失效时如何区分源站故障与逐条失效
先做一次全量抓取，把失效链接按“目标域名”和“首次发现时间”分组。如果同一域名下的链接几乎在同一时间点集体失效，且该域名首页或主要栏目也无法访问，优先怀疑源站故障；如果失效链接分散在多个互不相关的域名，且各自失效时间不同，则更可能是逐条失效，需要按链接逐条核对。
两种判断成立的条件
源站故障的判断成立，需要同时满足几个条件：失效链接指向同一主域名或同一 IP 段；失效时间集中在很短的时间窗口内，例如同一天或同一小时；该域名下原本正常的页面也出现无法访问或返回异常状态。此时问题不在你的外链平台记录，而在对方站点的可用性。
逐条失效的判断成立，则是另一种分布：失效链接分散在多个域名，失效时间跨度较大，或者同一域名下只有部分链接失效，其他页面仍然正常。这种情况下，更可能是对方删除了具体页面、修改了 URL 结构，或者单条链接被移除。
两种判断并非互斥。一个域名可能先出现源站故障，恢复后部分旧页面没有回来，于是变成逐条失效。所以分组之后还要看恢复情况。
把分歧转成可核对的项目
当多个角色对“到底出了什么问题”有不同理解时，不要停留在口头争论，而是把分歧拆成可核对的字段。建议在表格中为每条失效链接记录以下内容：
- 链接指向的完整 URL
- 目标域名
- 首次发现失效的时间
- 当前返回的状态码或错误类型
- 该域名下其他链接是否同时失效
- 该域名首页当前是否可访问
这张表的作用是让“源站故障”和“逐条失效”变成可以逐行验证的事实，而不是印象。任何人提出判断，都可以指向表中的具体行。
一个假设例子：同一天大量失效
假设你在同一天发现 40 条外链失效。其中 32 条指向同一个域名，且该域名首页返回超时；另外 8 条分散在 6 个不同域名，失效时间标注为过去两周内陆续出现。
在这个假设中，32 条应归入源站故障组，先等待对方站点恢复，暂不逐条处理；8 条归入逐条失效组，需要逐条确认是页面删除、URL 变更还是其他原因。这个分组动作本身就会改变下一步：源站故障组只需监控恢复，逐条失效组才需要联系对方或替换链接。
实施动作与例外
具体动作是：先按域名分组，再按时间排序，然后对每个可疑域名做一次首页和主要栏目访问测试。如果首页正常而只有部分链接失效，就转入逐条核对；如果首页也异常，就标记为源站故障并设置复查时间。
例外情况包括：某些域名可能屏蔽了你的抓取工具，导致误判为失效，此时需要用浏览器手动访问确认；另一些域名可能返回 200 但内容已完全改变，这属于内容替换而非链接失效，需要单独归类。
复查时间建议根据域名重要性设定，而不是统一等待。对核心引用来源，可以缩短复查间隔；对次要来源，可以延长。复查后如果源站恢复但链接仍未恢复，就把它从源站故障组移到逐条失效组，重新走逐条核对流程。
不要把抓取结果直接当成结论
抓取量归零或某次检测显示大量失效，本身不能单独证明源站故障。网络波动、抓取工具被限制、DNS 临时解析失败，都可能造成类似现象。因此，分组之后至少要用两种方式交叉验证：一种是用不同网络环境访问，另一种是手动打开目标页面。只有交叉验证一致，才把该组标记为确定故障。
最终要形成的不是“谁对谁错”的结论，而是一份可以继续更新的分组清单。源站故障组等待恢复，逐条失效组进入替换或联系流程，内容替换组另行评估是否保留引用。这样，同一天的大量失效就从争议变成了可执行的项目。
