yuyulei
yuyulei
another case: - I use cloud storage as local pv, after pvc&pod deleted, and cleanup pv successfully. But actually, cloud storage not works as expected. Then provisioner creates the pv...
如果你的需求简单，可以使用 command 模式，比如说 frpc tcp --server_addr=xxx --token=xxx --local_ip=xxx --local_port=xxx --remote_port=xxx
1. 构建可执行文件后的话，传 token 值给 frp 的方式，按你的说法，理论上都可能泄漏。 2. 构建可执行文件前的话，因为是你的 token，要么你自己构建？因为我们做的话，就不能对其他用户负责了。
"只接受第一个连接的 IP" 更像是指定用户访问的 proxy ，跟一次性的 proxy 不是同一回事。
可能需要更多点的信息： 1. “只接受,不应答“ 是否 frps 有哪些日志 2. 结合 frps dashboard 看看有没有信息，比如说 proxy connections 3. 能不能提供一个复现的场景或者思路
感觉受到了一波请求高峰（tcp 开始 listen 端口），然后导致了上述异常，“不应答”应该是最终现象。 要具体排查问题原因，比如说瓶颈是什么，需要通过一些调试命令（可能偏系统层面）采集案发当时的信息。 我建议从系统端口占用/分配，比如说TIME_WAIT 也会占用端口数，以及服务本身的承载能力（qps）等方面入手排查。 也建议做一些系统参数的优化，最好结合业务场景，看看网上有没有优化的示例。
从日志看当时 frpc 尝试连接 frps 的某个端口出现了问题，但是正如你所说，frpc 连接 frps的其他端口没问题。所以问题应该集中在出问题的端口上。但是，端口出问题的原因有很多，有可能是系统层面的原因。 “dial tcp 192.168.1.222:18080: connectex: No connection could be made because the target machine actively refused it.” 像这个错误看上去像是连接都没建立成功，换言之，很可能都没进入到 frps 代码逻辑或者直接被操作系统丢弃了。 我建议关注下当时网络层面的情况（重点 端口，tcp 队列相关）。
我随便举个例子，tcp 握手的时候需要经过 sync queue，如果高并发时候这个 sync queue 过小加之后端处理不及时，就会出现tcp层面的阻塞（详见 sync flood 攻击）。虽然表象是说 frp 中有错误日志，但是并不能证明是 frp 引起的。哪怕 frp 重启就恢复了，这个例子一样能解释，因为 sync queue 清空了。 你还可以模拟压测，看看能否复现，可以分为实验组和对照组，一组是你现在使用的后端，一组是 mock 的后端。这样能排除后端服务带来的影响。 上述只是个人经验，并不一定适合你的场景，具体你自己可以网上寻找下别人是否有类似问题。
感谢你提供的信息，我们这边也会压测分析下。
a websocket bug fixed by #2199 , now you can try new release v0.35.0 wss will be supported later. > Hello, I digg into this issue and found that websocket...