适用场景
网站已经配置 HTTPS，管理界面也显示启用了 HTTP/2，但你想确认客户端访问时是否真正使用了它，可以通过 curl 做一次小范围验证。本教程在 Linux 的 Bash 环境执行，选择你有权访问的普通公开页面，不需要登录信息，资料核对日期为 2026 年 10 月 28 日。
操作成果是一组可解释的对照结果：客户端是否支持 HTTP/2、同一地址在两次请求中实际使用什么版本，以及出现异常时应该先检查哪一层。本文不修改服务器配置，也不进行并发压测。
原理：请求参数与实际协议是两回事
访问 HTTPS 时，HTTP/2 通常通过 TLS 中的应用层协议协商（ALPN）确定，其协议标识是 h2，标准依据见 RFC 9113 的连接建立说明。客户端和当前连接到的服务端必须具备对应能力，才能完成协商。
curl 的 --http2 表示尝试使用 HTTP/2；对于 HTTPS，如果对端只支持 HTTP/1.1，仍可能正常完成请求。因此，退出成功只说明传输完成，不能单凭参数判断最终版本。这个回退行为见 curl 项目的 HTTP/2 说明。
网页状态码与 HTTP 版本也不同。状态码表示请求处理结果，协议版本表示这次连接如何承载 HTTP 消息，两者应分别观察。
准备工作
准备支持 HTTP/2 的 curl，以及一个体积较小、无需登录的 HTTPS 页面。优先选择你管理的网站上的普通静态页面，避开大文件下载、搜索接口或会触发业务操作的地址。
先检查当前程序的版本和功能列表：
curl --version观察功能行是否包含 HTTP2。有些系统中的 curl 虽然版本较新，但编译时没有启用 HTTP/2，此时相关参数会报不支持。应通过系统认可的软件渠道取得合适构建，而不是仅根据版本号猜测能力。
如果终端使用了代理，记录“经过代理”这一条件即可，不要把包含认证信息的代理配置复制进报告。两次对照应在相同网络条件下执行。
分步骤操作
第一步：输入待检查地址
下面通过交互输入保存完整地址，避免在教程中预设任何服务器地址。
read -r -p '输入待检查的完整 HTTPS 页面地址：' target_urltarget_url 保存你实际输入的页面地址，需要包含 HTTPS 协议部分。后续双引号用于保护其中的特殊字符。选择的地址不应包含访问令牌、私人查询参数或其他敏感信息。
第二步：建立 HTTP/1.1 对照
先明确请求 HTTP/1.1，并丢弃响应正文，只显示实际协议和状态码。
curl --http1.1 --silent --show-error \
--connect-timeout 10 --max-time 30 \
--output /dev/null \
--write-out '实际协议=%{http_version} 状态码=%{http_code}\n' \
"$target_url"连接时限为十秒，整次请求上限为三十秒，避免排查长时间挂起。这里使用普通 GET 请求，可以减少某些服务对 HEAD 请求处理不同带来的干扰。
如果传输成功，实际协议应为 1.1。若首先遇到证书、域名解析或连接错误，先处理该错误，再继续协议对照。
第三步：尝试协商 HTTP/2
保持地址和其他参数一致，只改变协议选项。
curl --http2 --silent --show-error \
--connect-timeout 10 --max-time 30 \
--output /dev/null \
--write-out '实际协议=%{http_version} 状态码=%{http_code}\n' \
"$target_url"http_version 是 curl 报告的实际使用版本，具体变量定义见 curl 命令手册。输出为 2，表示本次传输采用 HTTP/2；输出为 1.1，表示本次仍使用 HTTP/1.1。
若状态码为重定向，当前结论只适用于这次响应所在的连接。先核对跳转目标，再把目标地址作为独立对象重复检查，避免自动跟随多个域名后只看到最后一个结果。
第四步：必要时查看握手线索
当结果与预期不同，可针对同一公开页面增加详细输出。
curl --http2 --verbose \
--connect-timeout 10 --max-time 30 \
--output /dev/null \
"$target_url"在诊断文字中查看 ALPN 提议和服务端选择。不同 curl 与 TLS 库的输出格式可能不同，应关注是否协商到 h2，而不是机械匹配某一整行。
详细输出可能包含响应头和连接信息，分享前应检查其中是否有会话信息或敏感地址。不要把诊断文字直接作为公开附件上传。
验证方法
把同一地址的客户端能力、两次实际协议、状态码和检查时间放在一起比较。如果 HTTP/1.1 对照显示 1.1，HTTP/2 请求显示 2，并且传输没有报错，就能说明当前客户端与其面对的 HTTPS 端点成功使用了 HTTP/2。
如果网站前面有内容分发网络、反向代理或负载均衡，这个结果描述的是客户端面对的连接，不能证明代理到源站也使用相同协议。不同节点也可能配置不同，一次成功不能代表所有地区、所有时间都相同。
本例只验证协议协商，没有建立性能基线。不能因为采用 HTTP/2 就宣称页面一定更快；页面资源、延迟、服务端负载和缓存都会影响速度。
常见错误
最常见的误判是把参数出现当成协商成功，或者把业务状态码非成功误认为协议失败。即使返回访问拒绝，连接仍可能已经使用 HTTP/2，但业务可用性需要单独排查。
另一个问题是工具没有 HTTP/2 支持，却反复更换服务器参数。应先完成客户端能力检查。若证书校验失败，也不能通过关闭校验来获得看似成功的结果，因为那会改变验证前提。
安全与回退
这些命令不持久修改系统或服务端设置，结束请求即可停止验证。若只需要在当前诊断中恢复 HTTP/1.1，对下一次请求使用对应的协议选项即可，不需要删除缓存或重启服务器。
保留必要的结果摘要即可，及时清理包含敏感响应信息的诊断记录。正式调整服务器协议支持属于另一个变更任务，应先准备配置备份及服务恢复方案，不应根据一次协商结果直接修改线上服务。
参考资料与转载说明
本文依据上述公开资料进行中文原创整理，不是逐句翻译，也不替代厂商手册。操作前请核对自己的版本、型号和备份。
评论一下？