高手，这么快就找到原因了。
非常感谢！

http3不是在引导完鉴权之后就不用了吗 后面是纯quic

http3不是在引导完鉴权之后就不用了吗 后面是纯quic

服务端是完全的 http3 handle，通过 ProxyStreamHijacker 来获取代理的 stream

对啊 server看到非http3请求把它移交给 StreamHijacker 没经过h3机制

但我本地测试确实是新 stream 可以 WriteTCPRequest，但是收不到 ReadTCPResponse

服务端那边也能看到新的代理请求，就是在回写出了问题

文档里提了双向流的 close 和 go 的 Conn.Close() 行为不一致 这个close更像是 CloseWrite()

多线程顶多多开十几条流，也远不到 hy 服务端默认的 MaxIncomingStreams，按文档来说关闭后仍可以读，所以难道是客户端的读流满了读不了新的

https://quic-go.net/docs/quic/streams

可以抓包看看到底是服务端写阻塞了没能发过来还是发过来了但是客户端读阻塞了
我之前在Windows上观察的mux.cool压力应该在30~100不等 hy2正常工作的时候应该也不会差太远 因为十几条被造死也不应该

也可能是这边close后因为downlink还是存活 服务端发了一些残余数据来 但是客户端这边以为close了没人consume这些数据 卡在buffer里把客户端readbuffer占满了

直接套个 mask 也可以确认是服务端没发还是客户端 quic 不让 stream 读 不过也懒得去求证了，才注意到 hy 这里也注明了，总之干净的关闭是把读方向也关了

@hedsbj 你方便确认下 21244017631 还会出现卡死吗

直接套个 mask 也可以确认是服务端没发还是客户端 quic 不让 stream 读 不过也懒得去求证了，才注意到 hy 这里也注明了，总之干净的关闭是把读方向也关了

@hedsbj 你方便确认下 21244017631 还会出现卡死吗

刚测试了一下，正常了。连续测试了2遍。我用v2rayN 在win11平台上，服务端是s-ui 中的hy2
非常感谢！

用的是这样的配置
{
"protocol": "hysteria",
"settings": {
"version": 2,
"address": "xx",
"port": xx
},
"streamSettings": {
"network": "hysteria",
"hysteriaSettings": {
"version": 2,
"auth": "xx",
"congestion": "bbr"
},
"security": "tls",
"tlsSettings": {
"serverName": "xx",
"allowInsecure": false,
"alpn": ["h3"]
}
}
}
]