自签名无效证书下能否使用HTTP/2？Nginx环境性能疑问

一、自签名证书无效时还能用上HTTP/2吗？ #

首先得明确：Chrome提示证书无效，是因为自签名证书不在它的信任根清单里，但HTTP/2本身并不强制要求用权威CA颁发的证书。不过浏览器的安全策略卡了这一步：

• 你可以手动把自签名证书添加到Chrome的信任列表里，添加完成后浏览器就会认可这个证书，HTTP/2就能正常跑起来了。
• 要是不手动信任，Chrome会直接阻止建立安全连接（页面标红“不安全”），这时候就没法用HTTP/2了——因为现在主流浏览器几乎都只支持基于TLS（也就是HTTPS）的HTTP/2，明文HTTP/2基本被浏览器禁用了。

总结下：证书未被信任导致的“无效”，会让浏览器拒绝建立TLS连接，自然用不了HTTP/2；但只要手动信任自签名证书，就能正常使用HTTP/2。

二、为啥用了HTTP/2，6次请求后还要等TCP连接？ #

你遇到的这个6次请求限制，其实是HTTP/1.1的老问题了——HTTP/1.1默认同一域名下最多6个并发TCP连接，超过就得排队。但HTTP/2是基于单TCP连接多路复用的，所有请求都在同一个连接上处理，理论上不该出现这种情况。大概率是你的Nginx配置没正确开启HTTP/2，或者有其他配置冲突：

• 先检查Nginx的HTTP/2配置是否到位：
  必须在server块的listen指令里明确加上http2参数，比如：

  listen 443 ssl http2;
  

  要是只写了listen 443 ssl;，Nginx还是会用HTTP/1.1，那6次连接限制自然还在。

• 确认浏览器是否真的在走HTTP/2：
  打开Chrome开发者工具（F12），切到“网络”标签，看“协议”列——如果显示h2才是真的用上了HTTP/2；要是显示HTTP/1.1，那就是配置没生效，浏览器 fallback到了旧协议。

• 长耗时进程的额外建议：
  就算用上了HTTP/2，长耗时进程也可能占着连接里的流，影响其他请求。可以考虑：

  • 改成异步处理：返回一个任务ID，让客户端通过轮询或者WebSocket来获取结果，别让长请求一直占着HTTP/2的流。
  • 调整Nginx的超时参数：比如proxy_read_timeout，避免连接被过早断开。

内容的提问来源于stack exchange，提问作者Braham Shakti