整站都开了HTTP/3，可做SEO唯一在乎的那个请求，走的还是HTTP/2

摘要：用真实Chrome打开cloudflare.com，168个资源里有125个走了HTTP/3，唯独HTML文档本身走的是HTTP/2。刷新一次再看，文档才变成h3。中间唯一变的东西是浏览器记住了那条Alt-Svc。这就是整件事的要害：HTTP/3必须先从一个TCP响应里被告知存在，所以它永远赶不上一次访问的第一个请求——而爬虫抓一个页面，通常只发那一个请求。123个站查下来，声明了h3的有39个、DNS里查得到的只有17个、我这条线真连得上的又是49个，三种查法三个答案。还有11个站UDP上服务开着却一个字的广告都没打。

这件事是从一个很小的疑问开始的。保哥在给一个外贸客户看服务器配置的时候，看到运维在nginx里加了三行HTTP/3的配置，交付文档上写着已启用HTTP/3，页面加载更快。配置本身没写错，nginx -t 通过了，reload也成功了，UDP端口确实在监听。

但保哥当时想到一个问题：这个客户站的流量结构里，有相当一部分是搜索引擎的爬虫。那么爬虫抓页面的时候，走的到底是HTTP/3还是HTTP/2？

这个问题查不到现成答案。全网关于HTTP/3的中文文章，九成在讲QUIC的原理、讲UDP怎么解决队头阻塞、讲怎么在nginx里配那三行，剩下一成在跑测速对比。没有一篇回答一个更基础的问题：一个客户端要走HTTP/3，它是怎么知道这个站支持HTTP/3的。

而这个问题的答案，恰好把整件事的性价比翻了个面。

Chrome上量出来的第一件事：125个资源走了h3，文档没走

先不谈规范，直接看真实浏览器干了什么。

用一个干净的标签页打开 https://www.cloudflare.com/，等页面加载完，在控制台里读Performance API。PerformanceResourceTiming 有一个字段叫 nextHopProtocol，它给的是这条请求实际协商到的协议，不是猜的。

Cloudflare自己的官网，HTTP/3的推广者，一个页面里125个资源跑在h3上。而那个决定这个页面能不能被搜索引擎读到的HTML文档，走的是h2。

然后做一件很简单的事：在同一个标签页里，把同一个地址再打开一遍。

同一个浏览器、同一个地址、同一条网络，中间没有改任何配置。唯一的变量是这个浏览器之前来过一次。

换一个站再验一遍。shopify.com首次访问，文档 h2，同源资源全部 h3。规律一样。

这个规律不是Cloudflare特有的

保哥后来在自己的服务器上搭了一套完全可控的环境重做这个实验（下面第六节会详细写），结论一模一样：浏览器第一次碰到一个源，只能走TCP；从第二个请求开始，才有资格走UDP。

如果一个页面有一百个资源，那99个资源享受到了HTTP/3，只有1个没有——听起来损失很小。但如果一个客户端只发一个请求就走人，那它享受到的HTTP/3比例，是零。

为什么第一个请求注定走不到HTTP/3？

这不是实现的疏漏，是协议设计上的必然。

HTTP/2是通过TLS握手里的ALPN扩展协商出来的——客户端在ClientHello里带上我会h2，服务端在同一次握手里回那就h2。整个过程在一次TCP连接内完成，不需要额外往返，也不需要事先知道任何东西。

HTTP/3不行。它跑在UDP上，跟TCP是两条完全独立的通道，那次TLS握手根本不在同一个地方发生。RFC 9114第3.1.1节把发现机制写得很直白：

An HTTP origin can advertise the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 ALTSVC frame ([ALTSVC]) using the "h3" ALPN token.

On receipt of an Alt-Svc record indicating HTTP/3 support, a client MAY attempt to establish a QUIC connection to the indicated host and port; if this connection is successful, the client can send HTTP requests using the mapping described in this document.

拆开看这两句话，有三个地方值得停一下。

第一，广告牌挂在响应里，不是请求里

Alt-Svc 是一个响应头。要读到它，得先发一个请求；要发请求，得先建连接；而这个连接只能是TCP。所以整条链路是这样的：

换句话说，HTTP/3的入场券，得先坐着HTTP/2进场才能领到。

第二，那个词是MAY，不是MUST

规范说客户端可以去试试QUIC连接，没说必须。所以就算广告牌挂着，客户端也完全有权当没看见——比如它判断当前网络的UDP不可靠，或者它压根没实现QUIC。这一点对爬虫尤其重要：一个只想把HTML抓回去的程序，没有任何动机去多试一条协议。

第三，记住这件事是有期限的

Alt-Svc 里的 ma 参数（max-age）规定了这条广告能被记多久。保哥统计了123个站的实际取值：

中位数是24小时。这意味着一个正常用户如果隔了一天多再来，他的第一个请求又会退回TCP，整个升级过程从头再来一遍。

顺手发现：10个站的广告牌上还挂着2021年的版本号

统计版本token的时候冒出来一件挺有意思的事。39个声明了h3的站里：

HTTP/3在2022年6月就成了正式标准。这些草案版本对应的浏览器实现早就被删干净了，现在没有任何一个主流客户端会去连 h3-29。但这些token还老老实实地挂在响应头里，每一次响应都多发几十个字节，给谁看的没人知道。

这是一个很典型的配置化石：某年抄的一份配置，里面写着当时该写的东西，之后再没人回头看过。响应头这个地方特别容易长化石，因为它错了也不报错、多了也不报错。

这里还有个容易被忽略的细节：这份缓存是绑在浏览器配置文件上的。无痕窗口每开一次就是一张白纸，所以拿无痕窗口测出来的协议永远是h2，而你会以为是配置没生效。用错了工具就会查出错误的结论，这类事在协议这一层特别容易踩。

爬虫为什么永远停在第一个请求上？

现在把这个机制套到搜索引擎爬虫身上。

Googlebot抓一个页面的典型行为是：发一个GET请求，拿到HTML，解析出链接，然后把这个URL从队列里划掉。它不会为了拿到一张图片而在同一条连接上追加请求（渲染服务是另一套流程，稍后说）。所以从连接的角度看，它的行为特征是：

• 每个URL基本上就是一次请求
• 连接不长期保持，抓取任务之间没有会话延续
• 没有本地配置文件去持久化Alt-Svc这类信息

把这三条跟上一节的机制放在一起，结论就出来了：爬虫抓走的那份HTML，几乎不可能是通过HTTP/3传输的。它每次都是那个第一次，而第一次永远走TCP。

这跟Google官方说法对得上吗？

Google在抓取基础设施的文档里明确写过Googlebot支持HTTP/1.1和HTTP/2，并且说明抓取协议由Google侧决定、站点无法指定。至于HTTP/3，官方文档里没有承诺支持——而按照上面的发现机制，就算它支持，也用不上。

这跟保哥之前写过的另一件事结构上是同一类问题：Client Hints那套机制要求先有一次请求告诉浏览器要带什么，后续请求才带上，而爬虫每次都是第一次，所以那套机制对它天然失效。Alt-Svc是同一个形状的坑，只不过这次失效的不是内容协商，是整条传输协议。

那渲染的时候呢？

Google的渲染服务在执行JavaScript时确实会去抓页面引用的子资源，这个过程里理论上可以复用连接、也可以在拿到Alt-Svc之后升级。但这不改变一个事实：决定这个页面是否值得进索引、标题是什么、canonical指向哪里的那份HTML，是在渲染之前就被抓走的。那一份，走的是TCP。

所以真实的账是这样的：HTTP/3能帮到的是打开页面之后那一大堆资源的加载体验，帮不到的恰恰是抓取这一环。它是一个用户体验优化，不是一个抓取优化。两者在SEO里都算数，但不能混着说。

一个站到底开没开HTTP/3，为什么三种查法给三个答案？

为了把这件事量出来，保哥拉了一个125个域名的样本池，同时用三种方式去问同一个问题——这个站支持HTTP/3吗。

1. 问HTTP响应：发一个普通的HTTPS请求，看响应头里有没有 Alt-Svc 带h3
2. 问DNS：查HTTPS类型的资源记录（RFC 9460定义的SVCB家族），看alpn参数里有没有h3
3. 直接去敲门：用一个真正的QUIC客户端朝UDP 443发起h3握手，看握不握得上

三个数，而且它们互相不是包含关系。这里面藏着两组更有意思的差集。

11个站服务开着，广告一个字没打

有11个站——包括developer.mozilla.org、www.ebay.com、www.paypal.com、www.python.org、www.target.com——UDP 443上确确实实跑着HTTP/3，握手一次就通，但它们的HTTP响应里没有Alt-Svc头。

这意味着什么？意味着这些站的HTTP/3服务在那儿空转。浏览器没有任何途径知道它存在，于是永远不会去连。服务器为它分配了端口、进程和证书，收到的请求数是零。

这类站的常见成因是响应头被中间层洗掉了：源站发了Alt-Svc，前面一层反向代理或WAF没有透传。这跟保哥之前拆过的那类配置改完每次都通过、副作用却一声不吭的问题是一路的——配置是对的，链路把它吃掉了。

同一个CDN后面，19个站开了、20个站没开

还有一组数字值得单拎出来。把39个声明了h3的站按 server 头归类，再把84个没声明的也归一遍：

Cloudflare那一行几乎是对半开。同一个CDN、同一套边缘基础设施，一半的站声明了HTTP/3，另一半没有。这说明它不是CDN统一发下来的，而是每个站自己面板上的一个开关。

Netlify那一行是0比8，一个都没有。这类平台型托管的选择往往更整齐，因为它是平台层的决策而不是用户的决策。

这一栏数据的实际用处是：如果你在用Cloudflare而想确认自己开没开，别去查Cloudflare官方文档说支不支持，直接拿curl看你自己域名的响应头。厂商支持和你的站启用了，是两个独立的事实。

还有1个站，广告打了但敲不开

反方向也有一个：www.cloudflare.com声明了h3，保哥这条线上却握不上手。这个数只有1，样本太小不足以下结论，但它提醒了一件必须交代的事——

UDP 443这条路，本身就不像TCP 443那么畅通。保哥的125站里有26个h3握手报连接错误。这里面分不清哪些是站没开、哪些是路上被丢包。中国大陆方向的运营商网络对UDP高流量的处理策略跟TCP不一样，这是行业里公开讨论过很多年的事。

所以对做外贸独立站的人，这条要额外记一笔：你在国内测出来的HTTP/3可用性，跟你的海外用户测出来的可能完全是两回事。这跟海外用户说站点打不开时要分层排查网络路径是同一个方法论：先分清是服务的问题还是路的问题。

握手时长的分布也说明问题

中位155毫秒是个很漂亮的数字，但p90到了2.2秒。这条尾巴不是服务器慢，是UDP包在路上重传。协议再先进，也架不住路不通。

DNS里那条记录能不能救回第一个请求？

前面说HTTP/3赶不上第一个请求，其实留了个口子没堵：如果客户端在发请求之前就知道这个站支持h3呢？

这正是RFC 9460定义的HTTPS资源记录要解决的问题。它是一条DNS记录，跟A记录一起在解析阶段就返回，里面可以带alpn参数。客户端解析域名的时候顺手就知道了这个站会h3，于是可以跳过TCP那一轮，第一个请求就朝UDP去。

听上去完美。实际覆盖率是这样的：

最后一行是重点：39个声明了HTTP/3的站里，有23个没有配DNS记录。这23个站的每一次首访，都注定要先走一趟TCP。

就算配了，也不一定用得上

更扫兴的是，cloudflare.com和shopify.com这两个站的HTTPS记录都配得好好的、alpn里h3排第一位，而本文开头的Chrome实测里，它们的首次访问依然走的h2。

原因是浏览器要用上这条记录，得能查到它。而系统默认的DNS解析走的是操作系统的stub resolver，多数情况下只问A和AAAA记录，拿不到HTTPS类型。Chrome只有在开启了安全DNS（DNS over HTTPS）的时候，才有稳定的途径拿到这条记录。而这个开关的默认状态、以及企业策略下的实际生效情况，站长这一侧管不着。

所以这条路的实际情况是：它是唯一能让首次连接就走h3的机制，覆盖率13.6%，而且配了也要看客户端脸色。爬虫这一侧就更不用指望了——爬虫的解析器为什么要多查一条它用不上的记录。

那17条记录里还藏着一个附赠品

把这17条HTTPS记录的参数逐个解出来之后，有一个细节值得说：其中15条同时带了ipv4hint和ipv6hint。

这两个参数的作用是把IP地址直接塞进这条记录里，客户端解析到HTTPS记录的同时就拿到了IP，不用再单独发一次A记录查询。省下来的是一个完整的DNS往返。

换个角度看这件事：这条记录的价值并不全在HTTP/3上。就算你完全不打算开HTTP/3，配一条带IP提示的HTTPS记录，也能给支持它的客户端省掉一次解析往返。这是为数不多的、对首次访问也有效的优化——而首次访问，正是爬虫唯一会做的那件事。

代价是什么呢？多数DNS服务商的控制台上就是加一条记录的事。跟证书这类必须持续维护的东西不一样，这条配完基本不用管。

在自己的服务器上，这件事能不能复现？

测别人的站有个天然的弱点：你看不到服务端那一侧发生了什么。所以保哥在自己的服务器上搭了一套完整可控的环境，把这件事从两头都量一遍。

环境是这样的：nginx 1.28.3，独立实例跑在 /tmp 下的一套配置里，不碰生产站；证书直接用本站的真证书，这样浏览器不会因为证书问题拒绝QUIC；开了五个端口做不同的对照组。

为了保证服务端收到的东西跟客户端发出去的一致，每个端口的响应都用Lua把实际收到的内容回显出来——协议版本、Cookie的实际字节数、头字段条数、nginx记录的请求长度。这是这类实验的必备品：只要有一档回显对不上，整组数据就该作废。

用真实Chrome打自己的实验台

浏览器访问 https://zhangwenbao.com:18801/，服务端回显如下：

第一次h2、第二次h3，跟在cloudflare.com上看到的一模一样。这回是在完全自己掌握的服务器上复现的，配置是自己写的，日志是自己看的，没有任何中间层可以背锅。

顺带这张表还暴露了一件跟本题无关但很值钱的事：同一份529字节的Cookie，nginx在HTTP/2上把请求长度记成884，在HTTP/3上记成30。Cookie的回显两次都是529，说明请求内容一个字节没少，是日志失真。这个变量在HTTP/1.1和HTTP/2之间就已经不可横向比了，到了HTTP/3差距拉到29倍。任何按日志统计上行流量的脚本，切协议之后会直接给出错误的曲线。

配置写对了、nginx -t也通过了，服务为什么还是没人来？

实验台上剩下三个端口，回答的是同一类问题：哪些错误是配置检查抓不住的。

18803：不发Alt-Svc，服务照样在

这个端口开了QUIC，但一个字节的 Alt-Svc 都不发。保哥用QUIC客户端直接朝它敲门——握手成功，返回HTTP/3.0，一切正常。

所以 Alt-Svc 是一块广告牌，不是开关。不挂广告牌，服务照样在UDP上等着，只是没有一个浏览器会知道该往那儿去。这两件事在配置文件里是两行不相干的指令，删掉一行，另一行不会报错。

18804：只写了listen quic，没写listen ssl

这是一个真实存在的抄配置事故形态——教程里写了两行 listen，只抄了后面那行。结果是：

服务确实在跑，而且跑得挺好。但浏览器永远发现不了它——因为发现HTTP/3的唯一途径是从TCP响应里读Alt-Svc，而TCP这一侧压根没人应答。用户看到的是站点打不开，日志里干干净净什么都没有，因为请求根本没到达。

这个配置在语法检查里是完美的。这就是这类问题的性格：服务器没有说不，它只是做不到，而所有的检查工具都只会问它说了什么。

18805：ssl_early_data与0-RTT

0-RTT是HTTP/3宣传里最常被拿出来说的卖点——恢复一条之前的连接时可以零往返直接发数据。实验台上开了 ssl_early_data on，连了两次，两次都正常返回HTTP/3.0。

但这里有一个必须写清楚的前提：这台服务器的nginx是用OpenSSL 1.1.1编译的，走的是nginx提供的QUIC兼容层。nginx官方文档明确写过，用这个兼容层时不支持0-RTT。也就是说，配置文件里那行 ssl_early_data on 写了也不生效，而 nginx -t 一样通过、启动一样正常、错误日志里一行提示都没有。

这已经是这一节里第三个写了但不生效、而且完全静默的例子了。HTTP/3这块地方盛产这种配置。

本站开过HTTP/3，22分钟之后关掉了

写到这儿保哥去翻了一下自己服务器上的配置备份，发现了一件挺尴尬的事。

2026年6月21日11点57分，本站的nginx配置里确实有过这么几行：

listen 443 quic;
http3 on;
ssl_early_data on;
add_header Alt-Svc 'h3=":443"; ma=86400' always;

而同一天的配置备份文件名里，带着 disableh3 三个字，时间戳是11点57分30秒。开了不到半小时就关掉了。

当时关掉的原因已经无从考证，但这件事本身很能说明问题：一个自己写技术博客、自己管服务器的人，把HTTP/3开起来又关掉，中间没有留下任何一条为什么的记录。这大概是很多站的HTTP/3的真实生命周期——跟着教程开一次，遇到点说不清的现象就关掉，然后再也不提。

而这次做完实验之后，保哥反倒更倾向于先不开。理由在下一节。

那这个HTTP/3到底还要不要开？

把前面所有的数据摆在一起，答案不是要或不要，而是看你的流量结构里谁占大头。

先看这三个判据

这三条全都指向同一个方向：HTTP/3的收益，跟一次会话里请求数量的多少成正比，跟单次请求的重要性无关。而SEO关心的恰恰是那个数量为1、重要性为100的请求。

如果决定开，这几件事一件都不能少

1. 两行listen都要写。listen 443 ssl 和 listen 443 quic 缺一不可，缺前者用户直接打不开，缺后者广告牌指向一个空地址。
2. Alt-Svc必须真的发出来。配置里加了不等于用户收到了，中间任何一层代理都可能把它吃掉。判据是拿curl看响应头，不是看配置文件。
3. 云防火墙要放行UDP 443。很多云厂商的安全组默认只开TCP，UDP这条要单独加，加漏了的表现是端口在监听但外面连不上。
4. 配一条HTTPS类型的DNS记录。这是唯一能救回首次连接的东西，虽然只有13.6%的站配了，但配它的成本几乎为零。
5. 别指望0-RTT。先确认你的nginx是用什么TLS库编译的，用兼容层的话这个开关是装饰品。

那条最容易漏的：UDP在防火墙上是另一套规则

这一条单独拎出来，是因为它在实验台上真实卡了保哥一次。

服务器上的端口放行，习惯性写法是按端口号加规则。但TCP和UDP在防火墙里是两个完全独立的协议族——放行了 18801/tcp，不等于放行了 18801/udp。这两条规则得分别加：

firewall-cmd --add-port=443/tcp
firewall-cmd --add-port=443/udp

更麻烦的是云厂商那一层的安全组。多数云平台的安全组模板默认只给TCP，UDP要手动勾。而漏掉它的表现是最难排查的那一种：

三行全对得上，问题却真实存在。因为握手包连服务器的网卡都没摸到，服务端视角是完全干净的。这类问题只有一个查法：从外网、用一个真正的QUIC客户端去敲一次。

如果决定不开，会损失什么

损失的是回访用户从第二个请求开始的那部分传输效率，以及弱网环境下的连接韧性。这两样都是真实收益，但都不落在搜索引擎能看到的那一份HTML 上。

保哥的建议是：如果你的站正在为速度做优化，把力气先花在那些对第一个请求也有效的地方——服务端响应时间、缓存命中、压缩策略。这些每一样都直接作用在爬虫抓的那一次上。TTFB这一层的优化怎么同时作用在体验和抓取两端，那篇算过一笔完整的账。

说到底，HTTP/3是一项好技术，只是它的收益曲线跟很多人以为的位置不一样。它给的是一条路上第二辆车之后的所有车更好走，而搜索引擎那辆车，永远是第一辆。

常见问题解答

开了HTTP/3会直接提升排名吗？

不会有直接的排名加成。它可能通过改善真实用户的加载体验，间接作用在Core Web Vitals那几个指标上——但这条链路只对回访用户和资源密集的页面成立，而且首屏那个HTML文档拿不到这份收益。用一句话概括：它是体验侧的优化，不是抓取侧的优化。

怎么确认我的站的HTTP/3真的在工作？

三步，缺一步都可能给出错误结论。第一步用curl看响应头里有没有 Alt-Svc，这验证广告牌挂出来了；第二步在浏览器里连续打开两次同一个页面，看第二次的 nextHopProtocol 是不是h3，这验证客户端能升级；第三步从站外的网络（最好是海外线路）再测一次，这验证UDP 443路上通。只做第一步是最常见的误判来源。

Googlebot支持HTTP/3吗？

Google官方文档说明Googlebot支持HTTP/1.1和HTTP/2，并且抓取协议由Google侧决定、站点无法指定。HTTP/3没有出现在这个支持列表里。而按照本文拆的发现机制，即便未来支持了，只发一个请求的抓取行为也拿不到升级的机会——除非它去查HTTPS类型的DNS记录。

我用curl测不出HTTP/3，是配置有问题吗？

大概率不是。绝大多数系统自带的curl编译时没有带HTTP/3支持，可以用 curl --version 看Features那一行里有没有HTTP3字样。没有的话它连都连不上，跟你的服务器配置没关系。这也是很多人误判自己配置失败的原因。

CDN前面加了HTTP/3，源站还需要配吗？

不需要，也没用。用户是跟CDN边缘节点建立连接的，那一段用什么协议由CDN决定；边缘节点回源那一段是另一条独立连接，绝大多数CDN回源走的仍是HTTP/1.1或HTTP/2。所以在CDN后面的源站上开HTTP/3，既不会被用户用到，也不会被CDN用到。

那11个服务开着却不打广告的站，是不是配错了？

从结果看是无效配置，但成因不一定是配错。更常见的情况是响应头在链路上被某一层洗掉了，源站那边看自己的配置一切正常。判据很简单：在离用户最近的那一层拿curl看响应头，看不到就是没到用户手里，不管配置文件里写了什么。

UDP 443被网络限速或阻断了会怎么样？

浏览器会静默地回落到TCP，用户什么都感觉不到，你的日志里也不会有任何异常记录——因为那些UDP包压根没到你的服务器。这类问题的排查特点是只能从客户端一侧看到，服务端视角是完全空白的。这跟中间某一跳丢包但终点一个包不丢那类现象一样，观测点选错了就什么也看不见。

权威参考资料