LinkChecker插件需手动启用才能生效，路径为控制台→智能体设置→开启“网页健康检查”→高级配置中勾选“启用死链扫描”并保存，保存后实例自动重启，旧任务需重新部署；内网建议忽略HTTPS证书错误，并发数推荐设为6。
LinkChecker插件必须手动启用，否则所有扫描任务都无效
默认状态下MuleRun的LinkChecker模块是关闭的，哪怕你后续配置了完整任务流，也不会发起任何HTTP探测请求。这不是bug，而是设计上的安全默认——避免误触发大量出站请求。
启用路径很明确：登录控制台 → 智能体设置 → 找到“网页健康检查”开关 → 开启 → 点击高级配置 → 勾选“启用死链扫描” → 保存。注意，保存后系统会自动重启AI骡子实例，旧任务不会继承该能力，必须重新部署或触发新执行周期。
- 如果跳过这一步，
LinkChecker节点始终返回空结果，日志里看不到任何请求记录 - 内网环境建议勾选“忽略HTTPS证书错误”，否则自签名证书会导致大量误报为5xx
- 并发数设为6是平衡速度与服务器压力的经验值，超过10容易触发目标站的速率限制
URL提取器输入源类型决定扫描范围边界
URL提取器不是万能爬虫，它只从你指定的输入源中解析a、img、link等含href或src属性的标签，不会递归抓取页面外链。这意味着它的能力完全取决于你喂给它的“原料”。
常见输入源及影响：
立即学习“前端免费学习笔记（深入）”；
- HTML字符串（如爬虫输出）→ 只扫当前页内链接，不跳转
- 本地Markdown文件路径（如
/docs/README.md）→ 提取其中所有[text](url)和 - 飞书消息正文 → 仅提取纯文本中的URL（需正则匹配，不识别Markdown语法）
如果你希望覆盖全站，必须先用爬虫生成一份包含所有页面HTML的集合，再批量送入URL提取器。直接丢首页URL进去，它不会自动发现/about或/contact。
LinkChecker节点超时与重定向阈值必须按场景调优
LinkChecker默认用HTTP HEAD请求探测，但很多静态托管服务（如GitHub Pages、Vercel）对HEAD返回405，实际内容可用。这时必须改用GET，否则全部判为失效。
关键参数配置建议：
-
timeout设为8秒：CDN边缘节点响应通常在2秒内，超时过短会漏判慢响应站点 -
max_redirects设为5：防止重定向循环卡死，但像http → https → www → canonical这种合法跳转链可能刚好卡在第5次 - 务必开启
follow_redirects: true：否则301/302链接全被标为“重定向未处理”，而非“有效”
示例配置片段（YAML格式）：
linkchecker: method: GET timeout: 8 max_redirects: 5 follow_redirects: true
结果过滤器里404和5xx不能一刀切，要区分业务语义
直接筛出所有404链接看似合理，但会误伤正常场景：比如文档中引用的第三方API沙箱地址（https://api.example.com/v1/test）本就设计为404，或已下线但需保留在历史版本页中的旧资源。
推荐过滤逻辑分层处理：
- 硬性失效：状态码为
404、500、502、503、504→ 立即告警 - 软性失效：重定向次数>5 或 响应时间>10s → 记录但不告警，人工复核
- 白名单豁免：对
example.com、localhost等域名下的404不做处理
最终输出建议至少包含字段：url、status_code、redirect_chain、response_time_ms、source_file。没有source_file字段，你就无法定位是哪个HTML文件里的链接坏了。
真实巡检中最大的盲区不是技术配置，而是把“检测到死链”当成终点。链接失效背后往往是内容迁移遗漏、CI/CD流程没同步更新路径、或者文档作者手写URL拼错。自动扫描只是第一道防线，后续必须绑定修复闭环——比如把CSV结果自动转成Git Issue，或对接飞书机器人@对应负责人。否则报告堆得再漂亮，也只会躺在邮箱里吃灰。
