应该优先测试 iptables limit+tcp-reset ，这个基本是秒级的断开连接回应。平时会这样给内网丢包。

-A BLOCK_CHECK -p tcp -j REJECT --reject-with tcp-reset
-A BLOCK_CHECK -j REJECT --reject-with icmp-net-unreachable

AI 了一下，认为是上传方向 syn tcp 重传导致的并发数暴涨。

解决方案包括设定，这些参数得小心测试，当年将一个参数有 65 降为 60 就影响 ios 的在线更新。

# 1. 扩大连接跟踪表上限，防止表满断网
sysctl -w net.netfilter.nf_conntrack_max=524288
sysctl -w net.netfilter.nf_conntrack_buckets=131072

# 2. 极致缩短建立连接和关闭连接的超时时间（单位：秒）
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_sent=10
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_recv=10
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_fin_wait=15
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=15
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close_wait=15

# 3. 大幅缩短正常通行的 TCP 连接在无流量时的存活时间（默认 5 天，改为 10 分钟）
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=600

# 4. 优化 TCP Keepalive 保活探测，死连接快速释放
sysctl -w net.ipv4.tcp_keepalive_time=180
sysctl -w net.ipv4.tcp_keepalive_intvl=10
sysctl -w net.ipv4.tcp_keepalive_probes=3

进行上传方向 syn 限制，limit 这个模块还是非常温和的，不会是那种断开的感觉

# 全局限制转发的 TCP SYN 并发速率
iptables -I FORWARD -p tcp --syn -m limit --limit 150/s --limit-burst 200 -j ACCEPT
# 超额的直接通过 tcp-reset 熔断，强制客户端释放连接
iptables -I FORWARD -p tcp --syn -j REJECT --reject-with tcp-reset

清空，从来没试过，也没必要
# 1. 假设丢包在晚上发生，在丢包期间的 20:30, 21:30, 22:30 分别暴力清空一次连接跟踪表
30 20,21,22 * * * conntrack -F

# 2. 在丢包预计结束的时间点（例如 23:05 ），彻底清空一次连接表，让网络瞬间满血复活
5 23 * * * conntrack -F


看起来对于 openwrt ，这些方法都是可以应用的。

600 秒。。。

有点看不懂入站还是出站，
不是限制速度而是丢弃?

一般对于 openwrt 来说。connmark 表会受 tcp/udp 消亡时间影响，目前自己设置的网络最高的一个是 600ms 。这些会导致并发数不断的累积，直到触碰到它的上限。这个上限，比如 256MB 的 erx 刚刚这个月从 16384 改为 32768 。这是路由硬件的限制，据说受制于内存。至于触碰到 ISP 的上限，那还是使用 4/8M ADSL 时。

网络不通确实会导致一些异常问题，比如内网一些 PLC 设备连接外部的 auth 网站，给它网络它的并发下降到 20 以内。不给它网络全部发起的是 dns 查询，竟然每 ip 高达 1400+查询并发出现在主路由 connmark 表上。最后只能在接入交换机上屏蔽。

即然你已经发现了，不同地级的人根本没有权限问这个问题。只能投诉，有用嘛?一般不会这么不聪明，有流量刚好匹配这个策略，会导致网络 100%丢包，这不是给自己找投诉。

之前主路由是 erx 刷 openwrt 21.05 ，已经运行 676 天了，一直对 256MB 内存能换算多少并发不清楚。目前针对 440 个 dhcp 地址，目前并发已经设置到 32768 ，并发通过眼睛看已经高过 22000+。
本来觉得买 N60 Pro 512MB 够了，基于本来并发增长，直接上 2GB 。昨天才发现有 10 台 PLC 设备通过 8.8.8.8 一直在查询一个 auth 网址，每台浪费 1400+并发。。。

目前对于新硬件刷 21.05 以后的版本，唯一要注意的是要花时间将 iptables 转换为 nftables ，通过 Gemini 转换还算顺利。

以前写文档，都要通过搜索网站，通过阅读别人的文章来写自己的理解。存在的主要问题，别人的知识点也有限。

AI 知识倒是蛮全面的，唯一不好的地方今天和明天问的问题，回复的有变化。或者干脆把之前的结论推翻了。

不过目前都是对话式的问答，提问者也要有相关知识经验才能让 AI 优化性能，这年头还要啥上限，以后看谁能发明个人脑 CPU ，人人都是诸葛亮。想一下，AI 就给出一堆方案，使用人员也要有经验才能应用这些方案。

当年 iptables INPUT 默认不是 DROP 也是这效果。。。

这开孔，还是向下的，确实小了。
之前买的铁机柜向上开孔，后来换成左侧上方开孔，12cm 散热效果还是差点。

也许可以试试用个障碍物让柜门留出一条缝，然后试试暴力风扇向外排风，怎么固定又是个问题。

公司里买过 2 台 h3c nx30 是 mtk 版到底带不带 pro ，作为办公室覆盖设定每天一重启，原版固件没人反应有问题。

在我固有的认知里做无线覆盖应该买高通，有线主路由应该买 mtk 。最近买了个磊科 N60 Pro 2G 版，固件太新了，学习 nftables 等等新知识头大。

无线已经不考虑开源能刷固件，这些年都买华为 airengine 系列。

乳胶枕头外套塑料薄膜，外面有枕头套，枕头巾，平时能洗的也只有枕头套，枕头巾。当时只交待不能晒太阳，会风化的。能不能洗还真没研究过。。。

啊，当时这个泰国品牌是妹妹的店开在云南总代附近，然后就在朋友圈销售了 1 回，包括给那些单位当奖品发。

这么多年按照要求用塑料袋包好，没晒太阳，倒一直从 2016 年使用至今。淘宝上也有，应该不会有假货的说法。

乳胶的主要是会回弹，按重量挤压，比以前用的那些枕头好用。

环境异常，墙外墙内瞬移？
因为这个原因废了一个 7 位的 qq ，进入死循环验证。
自从手机用了 NekoBox 分流，再也没出过安全问题。

还是太年轻了，眼光太窄，穷人常常因为生一场大病倾家荡产。有钱可以熬，没钱连等死都做不到。

新闻里有宇树机器人，按定位应该是个街头机器人巡警，能跳能跑，外国用它来驱赶街头野生动物。小时候那电影叫啥来着,终结者。一看送外卖都被抢了。
一直以为机器人的手部不行，可是人家的机器人能在工厂里做衣服。。。

人类以后是不是智商比不过 AI ，体力活干不过机器人，还靠什么赚钱生存。还要被机器人抓捕。科幻片都成现实了。以后无家可归的人组成反机器人反 AI 同盟嘛，专门搞破坏。。。

之前收集了将近 30 个路由器，后来 3 大网也提供设备，现在手头的东西一文不值。。。

买个东西要考虑再三，不然摆在家里吃灰看着难受。

和网管搞好关系。

另外 openwrt 的无线一直认知里只有高通好用。或者更精确点越老的设备支持的越好。至于 mtk 不知道算不算好用，mtk7620 直到 21.02 才算彻底正常。

无线桥接应该是连接特定 bssid 并不像 mesh 只要 meshid 统一就好了。所以原则上它的上联 ap 固定，呑吐受信号最差的终端影响，和距离无关。

无法连接要嘛 ap 有终端连接数限制，要嘛 dhcp ip 地池不够,要嘛信号不好被 ap 反复踢除。高通的无线就是要比其它品牌强。适用的教程应该是 openwrt relay
https://github.com/kstenerud/openwrt-relayd-wireless-bridge

早就有明确的标准允许读用户软件安装列表，至于这是啥。我记得当时给同事 vivo 装 tvbox 就是死活装不上。什么中兴华为 vivoopple 小米，统统看不上，这些都是起草单位。

手机装了个 install with options ，似乎要调用 root 。