Ainz
Ainz
window too large 一直出现，退出是发生在开启压缩之后。 现在已经关闭了压缩功能，后面如果继续出现退出的问题会继续反馈。
在连接数10000，5MB/s的速度下，nps支撑十分钟左右就会退出，此时内存仍有剩余
指的是qb自带的web UI吗?那个语言是通过读取cookie实现的，可能是cookie的原因。
个人感觉像是连接突然断开，然后frpc尝试重连的过程中，frps的数据没有完全更新（猜测），因此导致登陆超时。因为在重启frps之后服务立刻恢复正常。frpc所处的非公网移动网络出口ip可能会不定时发生变化。
个人感觉不是网络问题，因为frpc所在的服务器用基本相同的systemd的方式运行了两个frpc，正如上面提到的一样。那么这两个frpc所处的网络环境应该是几乎一致的。但是却出现了ssh对应的frpc的连接非常稳定，但是另一个frpc的连接经常断开且无法重连的问题。如果真的是网络问题的话，应该另一个frpc也出现问题，但是这样的问题一次都没有发生过。
之前有排查到过是openfile设置的问题，但是显示的的是too many open file的报错和这个错误应该没有关系，然后现在已经把open file 的约束调整到65535了，系统，用户，进程三个角度都确认过已经修改成功了。现在确实不再显示too many open file这个报错了。 不知道是不是这个问题的一些遗留问题。
目前重启后暂时工作正常，崩溃后我会尝试通过您提到的方法进行抓包检查
**tcpdump抓自frpc服务器 脱敏处理，9.9.9.9代表frps服务器, 192.168.0.2代表frpc服务器** 16:14:15.741757 IP 9.9.9.9.10086 > 192.168.0.2.49562: Flags [.], ack 1888, win 2323, options [nop,nop,TS val 2701991619 ecr 2778801468], length 0 16:14:15.742843 IP 9.9.9.9.10086 > 192.168.0.2.49562: Flags [.], ack...
从结果来看并没有发现超时的原因
dashboard 显示online frps可以看到重连的日志 8月 01 16:23:07 server frps[410136]: 2022/08/01 16:23:07 [I] [service.go:450] [758ef0a41bd5261f] client login info: ip [*.*.*.*:47918] version [0.44.0] hostname [] os [linux] arch> 8月 01 16:23:07 server frps[410136]:...