应要求创建了一个TG群，帮助大家交流使用hysteria过程中遇到的问题
这里可能有你解决问题的提示，有些时候hysteria的配置新版本和旧版本无法兼容导致出错
很多时候出问题了更新服务端和客户端配置都能解决
请使用wechat-video且hysteria Core版本低于1.2.1的用户更新双端
因为hysteria 1.2.1修复了不开obfs导致wechat-video失效的bug,如果不更新 会导致无法连接
这里整理了一些常见的关于hihy使用过程中的问题，你如果遇到请不要急着开issue请在这里找一下说不定能解决。不要再开一些没有意义的issue了
这个问题很笼统，你需要知道客户端和服务端都有瓶颈，如果需要极高的网络带宽服务端和客户端都要有相应的硬件支持和带宽支持。
QUIC比原生TCP对硬件的开销要大很多，往往很多时候限制你的是你的CPU
如果你使用的是udp协议(wechat-video/udp)这时就需要保证你本地的ISP没有对udp传输做限制，而且少部分IDC提供者也会对udp做限制，防止用户拿来滥用
不要随便填写上行带宽和下行带宽，按照自己真实水平填写，大于你cpu处理能力和网络带宽能力的期望也会有这个问题
最后对于某些用这种lxc/openvz虚拟化无法更改 net.core.rmem_max，会导致在填写过高带宽时无法很好支持
首先你要保证你的服务端能正常启动
其次能保证你客户端配置没有报错
如果日志还表现为 [error:timeout: no recent network activity] Failed to initialize client
请查看你的IDC是否在黑名单里,如果以上都不满足请看下方
- 你没有打开云平台的防火墙，很多时候本机防火墙和云防火墙是分开的，hihy会自动打开本地防火墙，云防火墙需要你手动启动，关于启动说明看这里
- 你本地使用的ISP限制严格无法通行非常规udp协议，请切换协议类型尝试或者用faketcp
- 配置错误没有察觉，请重新检查一遍
- 你的IDC未被黑名单收集，请到此issue提交
你的系统太老了，不是主流社区维护的版本，比如软件更新源已经不支持更新了，这种系统单靠脚本是很难支持全的，这里就自己解决了
或者你的系统经过了服务提供商魔改，hihy无法识别系统类型这就无法进行接下来的步骤，也会报错
这种问题请自己安装成当前主流的镜像，方法很多这里就不说明了
每次运行 hihy都需要通过github获取最新信息，你的ip可能被github拉黑了或者根本无法连接github
目前未被针对，不知道以后如何，就算被针对由于是开源项目也会有很多人贡献代码对抗封锁的，参考隔壁ss。在这里感谢hysteria的开发者做的无私贡献。
请在github或者google play商店装上Hysteria-plugin并且允许被其他应用启动 现在不推荐使用sagernet,已经停止更新好长时间了,建议使用Matsuri
:)
所有渣代码没有加密，短链接使用的git.io，无法根据client不同返回不同值
即均可查，童叟无欺
占用高是QUIC的特点
obfs是用来混淆流量成未知流量的选项，开启它将会最大程度的对抗封锁，但是有优点和缺点 优点：
- 抗封锁
- 未知流量安全性强
- 能够隐藏证书握手信息，可以配合使用自签证书
缺点：
- 对cpu开销大，如果性能不好会影响速度
- 对某些有协议白名单的IDC来说，未知udp流量往往被认为是攻击，遭到阻断，客户端无法连接到服务端
目前自签证书使用的CA是固定的，是Tencent Root CA，这肯定是不合法的
之前一段时间使用自签证书完全没有任何问题，但是自从202210开始，观察到自签证书流量会遭到一定规模的阻断，也就是说会断流
所以你在希望自签证书时，我推荐你使用obfs，折损性能换来稳定
如果可能的话，推荐使用sing-box配置hysteria使用其中的shadow-tls
注意：下面的内容没有经过大量调查，仅说说我碰到的情况，仅供参考
众所周知，GFW是黑盒，我们只能通过猜来解释一些现象
hysteria用到现在了，也确实该被它针对了
不同地区不同运营商对UDP的策略都不同，举个例子：
可能同地区电信没事，移动有事
北京的电信没事，上海的电信有事
这个我没办法帮你总结，只能靠你自己测试，总的来说至少还有faketcp兜底
我描述一下我遇到的udp被限制的问题:
-
协议: wechat-video
-
证书: ACME申请的可信证书
-
是否多端口: 否
-
是否使用obfs混淆: 否
-
网络: 电信 -> 一个冷门机房
-
现象: 服务器A用hihy搭的，使用了好几个月，一直是单端口连接，后来突然发现不能用了，换其他节点之后用很短的一段时间又被阻断了，udp连接不上，faketcp没问题
这个现象使用PPPoE重新网络拨号之后解决了，然后第二天正常用，晚高峰时（九点左右）相同的现象又出现了
具体就是，所有的udp连接都在连接成功后，短时间内被阻断了，换节点无效，无论换的节点（服务器B、C、D，均是其他机房）是否使用了obfs、是不是多端口，只有用faketcp能连上。
后来我换了协议成udp开启了obfs还是一样的现象
- 原因猜测: 这次阻断是根据连上服务器A的源IP进行的，也就是说只要检测到连服务器A该端口udp流量有异常就会对连接该端口的所有源地址进行UDP限制
虽然听着绕，但是经过我半个月的测试，也确实是这么个情况
不确定是不是hysteria不开obfs的情况下流量被识别的问题，这个可能性我认为很小，应该是针对udp流量的通杀
- 解决办法：我这里给出我的解决办法，还是相同的服务器A更换其他端口并打开obfs，然后没出现过上面的现象