没用直通网卡，两个 vmbr ，一个 wan ，3 个 lan ，很稳定，没遇到性能瓶颈，感觉没必要直通，增加网络复杂性，该 boom 时照样 boom ，PVE J4125

搜索 docker 获取宿主机硬件信息，用 dmidecode 获取宿主机硬件序列号，将硬件序列号和授权功能及授权日期等通过非对称加密算法加密后生成 license 文件，程序内解密验证

@cyaki 现在没那么严重了，如果你还存在这个问题，建议参考楼上的讨论丢弃 RST 包试试。

frp 不同版本之间也不兼容，建议这种关键的服务固定版本，不要自动更新，否则挂了很麻烦。

/t/970368 通过服务器和本地配置 iptables 丢弃 rst 包的方式可以暂时绕过，前提是用自己的服务器，我试用了几天，目前没发现对服务器有啥影响

@yinmin 谢谢，准备试几天看看会有什么影响

@YGBlvcAK 刚刚测试了，强制 tls 1.3 还是会阻断，我没找到 nginx 配置 esni 的方法，不过有说加密 sni 的直接一刀切，全部阻断，想想也是，墙不知道你干啥，直接阻断了事

@admin13579 #102 提到的文章说的就是 timestamp ，但在我这并不行，可能已经升级了

@admin13579 问了 claude.ai ，它这样说的：
如果完全丢弃所有 RST 包,可能会带来以下一些不良后果:
正常连接被终止时无法释放资源,从而造成资源泄漏。TCP 连接的正常终止依赖 RST 报文释放连接。
无法快速中止无效连接,资源被无效连接占用。对无效的连接请求,服务器会发送 RST 报文快速拒绝连接。
连接重置功能被破坏。RST 使得 TCP 连接立即重置,丢弃 RST 会导致错误连接状态持续存在。
防火墙和入侵检测系统功能被影响。许多防火墙和 IDS 依赖 RST 报文判断连接状态。
网络堵塞加剧。丢弃 RST 使得断开的连接持续占用网络资源,加重网络拥塞。
某些应用连接功能失效。像 FTP 被动连接需要 RST 报文正确关闭旧连接。
引发更多安全问题。攻击者可以利用丢弃 RST 来实现一些攻击行为。
所以,完全丢弃所有 RST 包会对网络功能和安全造成影响。应该根据实际需要,有针对性地处理 RST 包,不能简单地全面丢弃。同时,关键服务也需要有应对措施,避免依赖 RST 的功能被破坏。

@windrun 这篇文章或类似的说法我也查到过，但是在我这边无效了，可能是墙升级了

@admin13579 您说的很有道理，我查阅了相关资料，丢掉 rst 包这种做法在刚开始有 reset 墙的时候就有人做过研究，我刚才也试了，确实是可以的，在服务器和本地分别执行 iptables -I INPUT -p tcp --tcp-flags RST RST -j DROP 丢掉 rst 包后就能正常访问了，确实是一个思路，但是这种直接丢弃所有 rst 包的行为会不会导致其他问题，正常的 rst 包也被丢弃了

@fcbwalk eu.org 就申请到一个，不太舍得用怕被 reset 了.....我用的 cf 上注册的 win 域名，比较便宜，可能域名后缀小众，就这已经 reset2 个了，换其他主流后缀再被 reset 钱包有点受不了....

@admin13579 估计不太行，如果可以的话某墙的 reset 大法就能绕过了

@huihuilang 不是所有网络环境都能装 VPN 的