能否在不终止TLS的情况下使用HAProxy为QUIC/HTTP3连接实现负载均衡？

好问题！先直接给你结论：在当前的HAProxy和ingress-nginx组合下，不把TLS终止移到HAProxy的话，要实现HTTP/3的负载均衡确实非常困难，甚至可以说几乎不可行。下面给你拆解一下原因，以及可能的变通思路：

核心原因：QUIC的特性限制了无TLS终止的负载均衡 #

QUIC/HTTP3是基于UDP协议实现的，和TCP的HTTP/1.1、HTTP/2有本质区别：

• QUIC把TLS 1.3握手直接集成到了连接建立过程中，连接标识（Connection ID）和TLS会话密钥是绑定的。如果HAProxy不终止TLS，它根本无法解析UDP包中的Connection ID，也就没法跟踪某个QUIC连接对应的后端ingress-nginx Pod。
• UDP是无连接协议，HAProxy需要明确知道每个UDP包应该转发到哪个Pod才能维持QUIC连接的连续性。但没有TLS终止的情况下，HAProxy没有识别QUIC连接归属的依据，自然无法完成正确的负载均衡。
• 你提到的“ingress-nginx Pod共享状态”，本质上是要实现QUIC连接的会话粘滞，但目前ingress-nginx并没有内置能让HAProxy直接感知的QUIC状态共享机制，即使Pod之间能同步Connection ID映射，HAProxy也缺乏读取这些信息的集成能力。

可行的变通方案 #

1. 接受将TLS终止移到HAProxy（最成熟的生产级方案） #

HAProxy 2.2及以上版本已经原生支持QUIC/HTTP3，在HAProxy层终止TLS后，它可以直接获取QUIC的Connection ID，进而基于这个标识实现会话粘滞，把同一QUIC连接的所有UDP包转发到同一个ingress-nginx Pod。

• 这种方案的社区文档和实践案例都很丰富，稳定性有保障。你只需要把SSL证书从ingress-nginx迁移到HAProxy，再调整ingress-nginx的配置，让它处理来自HAProxy的明文HTTP/3（或继续用代理协议处理HTTP/1.1/2）流量即可。

2. 让ingress-nginx直接暴露QUIC/HTTP3端口到公网 #

如果你的k3s集群节点拥有公网IP，可以直接在ingress-nginx的Service上配置NodePort或者LoadBalancer类型，暴露UDP 443端口（QUIC默认端口）。这样客户端的HTTP/3请求会直接打到ingress-nginx Pod，由它处理TLS终止和QUIC连接，完全绕开HAProxy。

• 缺点是需要在所有集群节点上部署相同的SSL证书，并且可能需要额外的DNS负载均衡来分散客户端流量到不同节点。

3. 尝试基于eBPF的流量转发（实验性方案） #

部分新兴的eBPF工具可以在内核层解析QUIC的Connection ID，并基于这个标识完成UDP流量的转发。不过这种方式属于前沿技术，配置复杂度高，稳定性不如成熟方案，适合有内核和eBPF经验的团队尝试。

总结 #

如果坚持不想把TLS终止移到HAProxy，目前没有开箱即用的解决方案，只能考虑第二种或第三种变通方式。但从生产环境的稳定性、可维护性和社区支持来看，将TLS终止移到HAProxy是最推荐的路径。

备注：内容来源于stack exchange，提问作者koehn