提升Hysteria稳定性：集成TLS伪装机制应对QoS —— 借鉴ShadowTLS和Reality的经验

[hycxnas]

你的功能请求是否与某个问题有关？
是的。在中国，ISP对于TLS加密流量的优先级处理往往优于其他类型的流量，尤其是当流量与知名域名如CDN服务关联时。

这一做法从提高常规HTTPS流量速度的角度来看无疑是有效的，但对于我们这些使用自定义加密协议的用户就成了一个巨大的障碍。这就是为什么即使使用了基于QUIC的Hysteria，流量仍然可能会受到严重干扰。

我尝试了ShadowTLS[1]，并意识到其伪装tls流量的巧妙之处。ShadowTLS 不需要自行签发证书（可以直接使用大公司或机构的可信域名），也不需要自行启动伪装的 HTTP 服务（因为数据直接转发至可信域名对应网站），使用可信域名可以进一步弱化特征，藏木于林。

所以我在思考，是否可以融合这些优秀的技术实践到Hysteria中？

描述你希望的解决方案
我期待Hysteria能够实现一种TLS流量伪装机制，就是借鉴ShadowTLS为流量伪装提供的策略，使得流量在TLS握手阶段显示与用户群广泛的大厂域名[2][3]（如shopify.com）绑定的证书一致，从而享有对等的传输优先级。

具体来说，这涉及在建立Hysteria代理连接之前，先进行一个标准的HTTP/3 TLS握手过程，使用合法证书完成握手，并在确立了看似合规的TLS会话后才转为传输经过obfs的Hysteria流量。

这种策略将使得代理流量更像是合法的HTTP/3流量，使ISP难以简单通过流量特征进行服务区分。实现该功能有助于显著提升在网络环境强制QoS下的用户体验和稳定性。

有没有其他替代方案
替代方案包括加大对流量混淆的技术投入。考虑到当前TLS加密在通信中的普遍应用和对网络运营商限制手段的有效对抗，我认为ShadowTLS所采纳的TLS伪装机制是比现有混淆技术更优的选择。

这个机制的可行性基于HTTP/3自身也是建立在TLS基础上的，但它采用的是QUIC来加速和优化。而ShadowTLS项目已经证明了伪装成正常TLS流量的代理传输是可能的。

额外信息
衷心感谢Hysteria团队一直以来对项目的辛勤付出与维护，你们的工作使我们这类对网络速度和稳定性有高需求的用户得以持续工作和交流。期待与你们探讨这个提议的可能性，并愿意参与到更深入的技术交流中。
[1] https://www.ihcblog.com/a-better-tls-obfs-proxy/
[2] Websites using HTTP/3 - Wappalyzer
[3] How to Test if a Website Supports HTTP/3?

[JimmyHuang454]

shadowTLS 和 REALITY 都无法应用到 QUIC 上面，他们都有一个共同点，使用了 TLS 中的 Session ID 字段，这个在QUIC上被弃用了（必须设置为 0 ）。

而且，Server Hello 也没必要一定要真实的 Server 回复，我们可以自己模拟服务器指纹，但在开启了 TLS 的 0-RTT 且 是多服务器集群的情况下，才有被识别到的可能，所以选取模仿域名时有一定技巧；顺便提一嘴，觉得 GFW 有如此严格检查的人，大概是被迫害妄想症发作。

最后总结，目前用 Hysteria 翻墙是最佳实践，等 GFW 能解析 QUIC 的那一天到来才去想其他事情也不迟。

[hycxnas]

shadowTLS 和 REALITY 都无法应用到 QUIC 上面，他们都有一个共同点，使用了 TLS 中的 Session ID 字段，这个在QUIC上被弃用了（必须设置为 0 ）。

而且，Server Hello 也没必要一定要真实的 Server 回复，我们可以自己模拟服务器指纹，但在开启了 TLS 的 0-RTT 且 是多服务器集群的情况下，才有被识别到的可能，所以选取模仿域名时有一定技巧；顺便提一嘴，觉得 GFW 有如此严格检查的人，大概是被迫害妄想症发作。

最后总结，目前用 Hysteria 翻墙是最佳实践，等 GFW 能解析 QUIC 的那一天到来才去想其他事情也不迟。

This proposal is strictly supposed to bypass QoS instead of censorship.

[hycxnas]

话说如果服务器线路是 CN2GIA、CMI、CU Premium 还会有 QoS 吗

Mostly it depends on the QoS policy set for your home connection and YES.