新到手的 Linux 服务器，我这样设置

博客干净简洁，内容行文严谨细致，完美。

@94nb 我就是这样的，只用安全组控制了
不过做了备份，就算是全没了应该也问题不大

@totoro625 一直以为 apt-get 和 apt 的关系相当于 version 和-v

直接 opensuse-leap-micro 6.2 爽歪歪

很好的指南，但是有几个地方可以更新一下
1.net-tools 对于 debian13 来说有点老了，现在都有系统自带的 ss 之类的可以替代了
2.nginx 推荐使用 n.wtf 已经打包好了 quic zstd brotli 模块了
3.fail2ban 有一点过时了，对于低配置的服务器用 sshguard 就足以，性能好一点的用 crowdsec 配合 nftables 更好

@alex177027 感谢指正

@ibegyourpardon 是啊

都用 cloudflare 的话，其实没必要开端口给 cloudflare ，原站迟早会被找出来（即使限制了 cf 段的访问，攻击者还是可以用 worker 来定位）
直接用 cloudflare tunnel 即可（
甚至于 ssh 也可以用 zero trust
这样甚至不需要有一个公网 ip ，想找原站也找不到

@bodayw #2 大兄弟 2 楼的说法在 2026 的今天还有效吗？我感性地说，曾经用 fq_codel 列队看油管 connection speed 没有问题，即是说吞吐量 OK ，稳定性也可以，但感觉爬升好像略差（相对 fq 、cake 列队），不过能够保证稳定对我来说更重要，我打算删掉 net.core.default_qdisc = cake 试试，虽然没有条件测试，但我觉得人的第六感有时挺准的，我当时感觉就是 fq_codel 好像更稳，所以一度很好奇这些列队究竟哪个更好，但我没有这些大佬的技术来验证。

@kimwang #49 我也没有技术和条件来测试这些，所以也只能再复读一下我上面贴的那个 systemd 的 issue 里最后那条回复：要结论得先有数据；而 Dave Täht 去年已经过世，接下来要靠后继者了……

@kimwang @bodayw 去年看了 2#说的话这个以后就一直使用默认的 fq_codel+bbr ，挺稳定的，关于速度爬升，可能没有其他的那么激进（这个受到地区、运营商、线路的影响因素比较多），但是总体是比较稳定的。

@bodayw 确实，一般人还真比较难对测试进行验证，就算是开发者日常也是工作为主，要验证得像科研一样，严谨且需兼顾所有可能影响结果的因素一并考虑才行，加上我换过的所谓“优化”方案也很多了，确实比较玄学，有像你提供的文献参考，加上实际应用效果较佳就算了，想起那句话，改装尽头是还原……

@DejavuMoe 非常同意，这个爬升速度跟你提及的地区、运营商、线路这些因素关系很大，空闲时段和繁忙时段往往就两个样，采用了某一种列队，如果空闲时吞吐量极高，繁忙时段又降低了，那么很大机会，无法通过其它类型的列队或内核参数“优化”获得满意的提升，实际效果往往难以有所突破，弄了一大堆换来的只是无谓的折腾，所以还是追求稳定。稳定+平滑>爬升+极速

不过有一种看似也是很有想法的方案，发出来给各位看看，如果已经知道就忽略吧。

>nodeseek(信息来源)
拥抱 xanmod ，实现 tcp 自动调优+bbrv3
https://www.nodeseek.com/post-245291-1

>优化 TCP 以实现高吞吐、低延迟
https://blog.cloudflare.com/optimizing-tcp-for-high-throughput-and-low-latency/

我试了，xanmod 内核天然较高资源占用，加上所谓“优化”过后，还不如直接 fq_codel ，fq_codel 无论 cubic 还是 bbr 方案都是对应的默认队列，方便之极。一个明显的不足是，BBR V3 反而容易看视频“打圈圈”，所以以后都不折腾了。

@kimwang BBRv3 如果没有特殊需求感觉没必要上，目前对大多数人来说 fq_codel+bbr 就是不折腾切够用的选择。