Xray会支持歇斯底里2么？

[toyo2333]

如题。不像再多弄一个docker或者服务了。不知道能否支持，白天网络正常用reality，晚上换歇斯底里2.

希望都在Xray里可以搞定。

[cary-sas]

用sing-box，啥协议都支持

[toyo2333]

用sing-box，啥协议都支持

我选择Xray有Xray独特的特性和一些设置需求。我问题是xray，不是sing-box。

[chika0801]

目前为止没有计划

[RPRX]

目前来说 Hysteria 等协议的目标是 通过激进的发包策略来提升弱网环境的代理可用性，但是有以下缺点：

1. 激进发包其实就是抢资源，会弱化其他人的体验，如果大家都用，那只会更爆炸
2. 它们的目标不是抗封锁，社区也没有 GFW 对 QUIC 动手的历史数据，尚不清楚 GFW 会如何针对性封锁这些协议

所以可以再观望一下，尤其是第一点要想清楚，这就跟补习一样，别人补，你看了也想补，最后大家都补了，就成了无意义内卷，而且既然它们成了主流，GFW 就会研究它们和普通 QUIC 的不同，最后大家只能回归普通 QUIC，反正预言是放这儿了

[toyo2333]

目前来说 Hysteria 等协议的目标是 通过激进的发包策略来提升弱网环境的代理可用性，但是有以下缺点：

1. 激进发包其实就是抢资源，会弱化其他人的体验，如果大家都用，那只会更爆炸
2. 它们的目标不是抗封锁，社区也没有 GFW 对 QUIC 动手的历史数据，尚不清楚 GFW 会如何针对性封锁这些协议

所以可以再观望一下，尤其是第一点要想清楚，这就跟补习一样，别人补，你看了也想补，最后大家都补了，就成了无意义内卷，而且既然它们成了主流，GFW 就会研究它们和普通 QUIC 的不同，最后大家只能回归普通 QUIC，反正预言是放这儿了

讲究，点赞！

[tobyxdd]

1. Hysteria 发包是否 "激进" 仁者见仁，不过绝对不是多倍发包（这个我相信 RPRX 知道，只是为了和路人强调下），详细的解释可以看这里 https://v2.hysteria.network/zh/docs/misc/Hysteria-Brutal/ 。我的观点是用户使用运营商承诺的带宽发包，没有破解限速就是合理的。至于拥塞控制即使是 TCP 不同的操作系统和配置也不同，BBR 也是在 "弱化 Cubic 的体验"。而且互联网上天然就有很多流量没有拥塞控制，比如联机游戏可不会因为延迟和丢包率高而降低 tickrate。

2. Hysteria 还是特意注意没有魔改 QUIC 基本协议层的东西的，毕竟还要作为普通 HTTP/3 server 处理浏览器请求。行为上应该和其他用 quic-go 实现的 HTTP/3 web server (比如 caddy) 一致。当然往深了说目前各种 QUIC 实现都是有细微差异的，像 quic-go, quiche, quinn, ngtcp2, neqo 在默认参数和行为上都不完全相同，如果一定要把服务端用的是什么库本身作为特征的话应该是可以的。但是正如你所说 "尚不清楚 GFW 会如何针对性封锁这些协议"，我不想提前修改，偏离 quic-go 而 potentially 造成新的特征。如果 GFW 真的能够针对性封锁了，我相信只要不是白名单或者完全封锁了 UDP 流量都是能解决的。人固有一死但是今天的饭还得吃

另外 RPRX 发了这个回复以后我看到两边的用户群都开始有站队的现象，我想声明一下我十分清楚 RPRX 的目的只是技术讨论，没有任何 "攻击 Hysteria" 的意思。无论是否加入 Hysteria 我都会继续支持 RPRX 和 Xray 这个项目。no hard feelings

[toyo2333]

1. Hysteria 发包是否 "激进" 仁者见仁，不过绝对不是多倍发包（这个我相信 RPRX 知道，只是为了和路人强调下），详细的解释可以看这里 https://v2.hysteria.network/zh/docs/misc/Hysteria-Brutal/ 。我的观点是用户使用运营商承诺的带宽发包，没有破解限速就是合理的。至于拥塞控制即使是 TCP 不同的操作系统和配置也不同，BBR 也是在 "弱化 Cubic 的体验"。而且互联网上天然就有很多流量没有拥塞控制，比如联机游戏可不会因为延迟和丢包率高而降低 tickrate。
2. Hysteria 还是特意注意没有魔改 QUIC 基本协议层的东西的，毕竟还要作为普通 HTTP/3 server 处理浏览器请求。行为上应该和其他用 quic-go 实现的 HTTP/3 web server (比如 caddy) 一致。当然往深了说目前各种 QUIC 实现都是有细微差异的，像 quic-go, quiche, quinn, ngtcp2, neqo 在默认参数和行为上都不完全相同，如果一定要把服务端用的是什么库本身作为特征的话应该是可以的。但是正如你所说 "尚不清楚 GFW 会如何针对性封锁这些协议"，我不想提前修改，偏离 quic-go 而 potentially 造成新的特征。如果 GFW 真的能够针对性封锁了，我相信只要不是白名单或者完全封锁了 UDP 流量都是能解决的。人固有一死但是今天的饭还得吃

另外 RPRX 发了这个回复以后我看到两边的用户群都开始有站队的现象，我想声明一下我十分清楚 RPRX 的目的只是技术讨论，没有任何 "攻击 Hysteria" 的意思。无论是否加入 Hysteria 我都会继续支持 RPRX 和 Xray 这个项目。no hard feelings

我也已经用上hysteria2了。使用的是官方的docker-composer.因为是全docker配置，和xray也是共存使用。我觉得是互补的选项。我的线路大部分时候都挺好的。在线路状况正常的情况，reality对比hys2的速度。目前看都差不多的。我打算试一试有时候晚高峰拥堵的时候的对比。

总体来说，挺好。我觉得，技术，就应该百花齐放。

[RPRX]

#3547 (comment)

[RPRX]

#3547 (comment)