故障排查

curl -I 返回 405，但浏览器能打开：别把 HEAD 测试当成代理故障

区分 HEAD、GET 与代理隧道响应，用同一目标和同一代理入口做有限对照，避免看到 405 就重装客户端或关闭证书校验。

发布于 2026/10/21 · 更新于 2026/10/21 · 2 项可核验来源

先看请求方法：curl -I 发的是 HEAD，不是浏览器通常用来取页面的 GET。405 表示这个资源不支持所用方法，不能仅凭这一行判定节点失效。先保留响应，再对允许访问的小页面做一次 GET 对照。

大写 -I 与小写 -i 不一样

curl 的 -I / --head 选择 HEAD；-i 则把响应头和响应正文一起输出，并不会单独把 GET 改成 HEAD。看起来只差大小写，实际测试的问题不同。默认普通 HTTP URL 请求通常使用 GET，额外传入数据等选项会改变行为。

HEAD 用于查看资源的响应元信息而不取正文；正常支持它的服务应保持与 GET 一致的语义。不过遇到按方法设置的应用路由、网关或实现差异时，HEAD 可能被拒绝。因此“HEAD 不通、浏览器能开”首先是一个方法对照线索，不足以证明同一代理下所有应用都正常。

405 与连接失败分属不同层

RFC 9110 将 405 定义为目标资源不支持请求所用方法，并要求响应通过 Allow 列出当前支持的方法。可以记录这个字段，但不要把缺失的 Allow 自动解释为网络断开：响应也可能来自中间网关，单凭状态码无法定位生成它的设备。

HTTP 405 与 Connection refused、TLS 失败、等待超时不同：你已经收到了一份 HTTP 响应，但仍要确认它来自哪一跳。通过 HTTP 代理访问 HTTPS 时，终端可能先出现 CONNECT 隧道的状态，后面才是目标资源的响应；前面的 200 Connection established 不等于页面最终返回 200。相关区别见连接错误的分层排查。

固定目标和代理，只改一个变量

先确认客户端中实际监听的 HTTP 或 mixed 端口；下例的 7890 只是示例，不是所有客户端的默认值。
选择你有权访问且体积小的普通页面。不要用付费下载、订阅凭据链接或会改变账户状态的接口做示例。
固定 URL、代理入口和网络，先记录 HEAD 结果；若只是 405，再用 GET 对照。遇到 401、403 或明确的访问限制，停止并处理授权，不用更换方法、账号或出口绕过。

curl --proxy http://127.0.0.1:7890 --max-time 15 --head https://example.com/

这条命令用于展示参数，不保证 example.com 在你的网络一定返回某个状态。需要复现自己的问题时，换成同一个获准测试的目标地址，并记录时间、curl 版本与所选节点。Windows PowerShell 下使用 curl.exe，避免把其他命令别名当成 curl。

想用 GET 看响应头，不必用 -I

在 macOS / Linux 上，下例发出普通 GET，将正文写入空设备，同时把响应头显示在终端。它仍会接收正文，所以不会因为丢弃输出就省下下载流量；只用小页面，并保留超时限制。

curl --proxy http://127.0.0.1:7890 --max-time 15 --dump-header - --output /dev/null https://example.com/

Windows 的空设备为 NUL，同样用明确的可执行程序名：

curl.exe --proxy http://127.0.0.1:7890 --max-time 15 --dump-header - --output NUL https://example.com/

不要为了“测试通了”加 --insecure。证书错误需要单独解释；也不要一上来追加 --location 追随所有跳转。先看当前响应的 Location 和目标域名是否符合预期，再决定下一步。若输出要用于求助，先删除 Cookie、认证字段和带令牌的 URL。

怎样读这组对照

HEAD 为 405、GET 返回预期页面：更符合方法支持差异，不应仅因此重置客户端或更换全部节点。
HEAD 与 GET 都在本地代理端口失败：先检查监听端口与客户端是否运行，参考HTTP、SOCKS 与 mixed 端口。
GET 收到 401 或 403：HTTP 通信已有结果，但当前请求没有得到所需访问权限；不要继续把它当作普通超时反复重试。
GET 是 200，内容却是登录页或错误页：状态成功不等于业务内容正确，继续核对页面内容与最终目标。
浏览器与终端仍不同：浏览器可能带登录状态或使用不同代理设置。先核对路径，不复制整份浏览器 Cookie 到公共命令，参见浏览器正常、终端失败。

修复与恢复到什么程度算完成

先恢复你原本需要的普通页面访问，再验证实际应用。若根因是监测脚本只接受 HEAD，可在有权修改的监测配置中选择合适的 GET 检查及小型健康页面；不要把“任何状态码都算成功”作为修复。若你只是普通访问者，向维护者提供方法、状态、时间和脱敏响应即可。

一次对照只说明这一时刻、这一入口与这一资源的表现，不代表整条线路稳定，也不能推出下载速度。保留原始错误和改变过的单个参数，测试完停止临时请求，无须为此永久修改系统代理、DNS 或证书设置。本文提供操作方法，不声称完成了你设备或节点上的实测。

资料来源

以下官方资料于 2026/10/21 核对；示例端口和目标需按实际环境调整。

持续更新

收到新教程，也欢迎纠错

想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。

关注 TG 频道 Telegram 纠错邮件纠错

读者互动

这篇内容对你有帮助吗？

— 次访问— 累计日独立访问— 条评论

直接说出你的问题