检查链接出现405：比较HEAD与GET请求

不要仅凭状态数字判定链接失效

浏览器可以打开页面，但检查工具返回405。遇到这种差异，应先调查，而不是立即删除链接。根据收到的响应，这个状态表示目标资源不支持所请求的方法。它并不确认内容确实存在、可以公开访问，或对每位访客都可用。保留完整且准确的地址，并记下是哪一个工具给出了这个结果。

Stack Overflow上有用户把链接检查从GET改为HEAD后遇到405；Reddit上也有人询问程序检查链接为何出现误报。这些是用户报告的问题，不是你当前故障的原因证明。本指南先比较请求，再核实内容，然后决定应修正链接、检查工具还是网站配置。

HEAD与GET有什么不同

GET请求资源的一种表示；HEAD请求与GET相对应的元数据，但响应不包含正文。MDN说明了这一区别。只请求响应头可能减少传输量，却不能读取网页，也不能确认网页中有预期文件。同时，它不能保证应用程序或中间环节会正确处理两种方法。遇到拒绝时，应记录实际使用的方法。

RFC 9110要求405响应包含Allow响应头，列出资源当前支持的方法。如果工具显示该响应头，就检查它；如果缺少，就记录缺失，不要编造其内容，也不要认为开放所有方法就能解决问题。示例响应只是演示，并非真实网站抓取结果。Allow也不能代替对所需方法的实际检查。

HTTP/1.1 405 Method Not Allowed
Allow: GET

比较能够解释的请求

如果你管理该网站并熟悉终端，可以对同一个公开、仅用于读取的地址比较HEAD与GET。示例命令显示响应头；第二条在收到正文后才丢弃正文，因此仍可能下载数据。请把example.invalid替换为你有权检查的页面。该域名是虚构的，不是可用的测试服务。不要测试购买、删除或退出登录等操作。

保持URL及可控制的条件一致，记录时间、方法、状态和可能的重定向。示例命令不跟随重定向；应先查看新目标，再决定是否在那里重试。不要添加凭据，也不要把私密Cookie复制到公共工具中。已登录的浏览器与另一台机器上的匿名请求并非等价比较；在归因于请求方法前，先说明这种差异。

curl --head --max-time 20 "https://example.invalid/guide"
curl --silent --show-error --max-time 20 --dump-header - --output /dev/null "https://example.invalid/guide"

不要对结果过早下结论

如果在可比较条件下观察到HEAD返回405、GET返回200，只能说这两个请求收到了不同响应。你仍需打开页面并检查内容。如果GET也返回405，就没有证明问题仅限于HEAD。如果GET返回404，先前的HEAD结果也未证明该页面存在。请把每项观察与推测分开。

不要为了消除错误提示，把表单从POST改为GET；这样可能改变功能，并让数据出现在地址中。也不要为了方便关闭安全控制或开放写入方法。对于自己的网站，把结果交给负责检查路由和服务器规则的人。对于他人的网站，请索取合适的公开链接，或在不泄露敏感数据的情况下报告故障。

加上WikiURL检查

把完整公开地址粘贴到WikiURL的URL检查工具，保存HTTP状态和检测到的最终地址。这是从该服务服务器进行的另一项观察。不要假定它复现了你的浏览器、登录会话或上述命令。界面不提供手动选择HEAD或GET的功能，因此不能声称它展示了两种方法的对比。

随后在浏览器打开真实目标，确认预期受众看到的是正确页面。如果工具和浏览器结果不同，就同时保留结果及其条件。200并不认证内容或安全性；单次405也不足以决定删除链接。目的是收集证据、修复具体环节，而不是把一项标签当成完整诊断。

分享前留下可核实的决定

制作简短记录：URL、日期、工具、已知方法或未观察到的方法、状态、最终目标以及核实过的内容。缺少的测试应标为待办检查，而不是填写成功。保留必要响应头时，去掉令牌、Cookie和个人数据。交给他人复核时，应提供这份摘要和预期行为，而不是证据尚不支持的结论。

在完成具体修正后，进行适度复查并确认内容，再用WikiURL缩短地址或生成二维码。这些格式便于分享，却不能改变服务器支持的方法或修复资源。把参考链接与发布文件一同保存，便能区分客户端差异、方法遭拒和目标错误，避免仅凭一次响应就丢弃有效地址。