运维 on KnightLi的博客

用 NAS 自建 Git Server 同步本地 Markdown 笔记

Sat, 30 May 2026 16:14:19 +0800

如果已经有一台本地 NAS，又希望笔记尽量保存在自己手里，可以把 Markdown 笔记放进 NAS 上的 Git Server，再用 Android 和 Windows 客户端同步。这个方案不依赖公共云盘，适合 Obsidian、Markor、VS Code、Typora 这类以本地 Markdown 文件为核心的笔记工具。

它的基本思路很简单：

NAS 上创建一个 Git 裸仓库，作为笔记的中央仓库。
Windows 端克隆仓库，用常见编辑器写笔记。
Android 端克隆同一个仓库，用 Git 客户端拉取和推送。
每次换设备前先 pull，写完后再 commit 和 push。

这种方式不是最傻瓜的同步方案，但可控性很好，历史版本也清楚。只要养成提交习惯，就能把笔记、配置、图片附件都放在自己的 NAS 上长期保存。

方案适合谁

这套方案适合下面几类人：

家里或办公室已经有 NAS。
笔记主要是 Markdown 文件。
希望笔记数据保存在本地网络里，而不是只放在商业云盘上。
需要 Windows 和 Android 多设备同步。
能接受 Git 的基本操作，例如 clone、pull、commit、push。

如果你希望完全自动、完全无感同步，Syncthing、WebDAV 或笔记软件自带同步可能更省心。Git 更适合重视版本历史、可回滚、可迁移和可控性的笔记库。

一、在 NAS 上安装 Git Server

不同 NAS 系统的入口不一样，但目标都一样：让 NAS 提供一个可以通过 SSH 访问的 Git 仓库。

常见做法有三种：

方式	适合场景
NAS 套件中心安装 Git Server	群晖、威联通等成品 NAS，想少折腾
Docker 部署 Gitea	想要 Web 界面、账号管理和更完整的 Git 服务
直接用 SSH + 裸仓库	只给自己用，追求简单稳定

如果只是个人笔记同步，SSH + 裸仓库已经够用。假设 NAS 上有一个专门的 Git 用户 git，仓库存放目录为 /volume1/git，可以在 NAS 终端里执行：

1
2
3

mkdir -p /volume1/git/notes.git
cd /volume1/git/notes.git
git init --bare

裸仓库不直接编辑文件，只作为同步中心。实际写笔记的目录在 Windows 或 Android 本地。

接着确认 SSH 可以访问 NAS：

`1`	`ssh git@192.168.1.10`

如果 NAS 支持 SSH 公钥登录，建议配置公钥，避免每次推送都输入密码。Windows 和 Android 可以分别生成自己的 SSH key，再把公钥加入 NAS 的 authorized_keys 或 Git Server 用户设置里。

二、Windows 端设置

Windows 端建议安装 Git for Windows，然后选择一个本地目录存放笔记，例如 D:\Notes。

首次克隆：

`1`	`git clone git@192.168.1.10:/volume1/git/notes.git D:\Notes`

进入目录后，可以创建基本结构：

1
2

cd D:\Notes
mkdir inbox, daily, projects, resources

然后用 Obsidian、VS Code、Typora 或其他 Markdown 编辑器打开 D:\Notes。写完第一批笔记后提交：

1
2
3

git add .
git commit -m "初始化笔记库"
git push origin main

如果仓库默认分支是 master，就把命令里的 main 换成 master。也可以统一改成 main：

1
2

git branch -M main
git push -u origin main

日常使用时，Windows 端可以保持这个节奏：

git pull --rebase
git add .
git commit -m "更新笔记"
git push

三、Android 端设置

Android 端可以使用支持 Git 的客户端来同步本地 Markdown 目录。常见选择包括：

工具	用法
Termux	最灵活，接近 Linux 命令行
MGit	图形界面 Git 客户端，适合不想敲太多命令
GitJournal	更像笔记应用，适合简单 Markdown 笔记

如果选择 Termux，可以先安装 Git 和 OpenSSH：

1
2

pkg update
pkg install git openssh

生成 SSH key：

`1`	`ssh-keygen -t ed25519 -C "android-notes"`

把生成的公钥加入 NAS 的 Git 用户授权里。然后在手机本地选择一个目录克隆仓库：

`1`	`git clone git@192.168.1.10:/volume1/git/notes.git ~/notes`

如果想让普通 Android 编辑器访问这个目录，可以把仓库放到共享存储目录，例如：

1
2

cd /sdcard
git clone git@192.168.1.10:/volume1/git/notes.git Notes

之后可以用 Markor、Obsidian Android 或其他 Markdown 编辑器打开 /sdcard/Notes。手机端修改后，再回到 Termux 执行：

cd /sdcard/Notes
git pull --rebase
git add .
git commit -m "手机更新笔记"
git push

Android 上最容易出问题的是权限和路径。Termux 自己的家目录更稳定，但部分编辑器不一定能直接访问；/sdcard 方便编辑器访问，但权限、文件监听和性能可能受系统限制。可以先用少量笔记测试，再决定最终目录。

四、Obsidian 和 Joplin 怎么落地

NAS Git Server 只解决“文件放在哪里、怎么同步”的问题。真正写笔记时，还需要选择笔记应用。这里可以分成 Obsidian 方案和 Joplin 方案。

方案	同步方式	适合人群	注意点
Obsidian + Git	笔记目录就是 Git 仓库，Windows 和 Android 都拉取同一个仓库	想要双链、知识图谱、插件生态和纯 Markdown 文件的人	Android 上最好先测试 Git 客户端和 Obsidian 对同一目录的访问权限
Joplin + Git	不建议直接把 Joplin 数据库放进 Git；更适合用 Joplin 自带同步，或定期导出 Markdown 到 Git	想要网页剪藏、端到端加密、传统笔记本结构的人	Joplin 的本地数据不是普通 Markdown 文件夹，不适合直接当 Git 笔记库同步

Obsidian 方案

Obsidian 最适合这套 NAS Git 同步方案。原因是它的 vault 本质上就是一个普通文件夹，里面是 Markdown 文件、图片附件和配置文件。你可以直接把 D:\Notes 或 /sdcard/Notes 作为 Obsidian vault。

Windows 端流程：

`1`	`git clone git@192.168.1.10:/volume1/git/notes.git D:\Notes`

然后在 Obsidian 里打开 D:\Notes。

Android 端流程：

1
2

cd /sdcard
git clone git@192.168.1.10:/volume1/git/notes.git Notes

然后在 Obsidian Android 里打开 /sdcard/Notes。

Obsidian 方案建议：

单人使用时，可以提交 .obsidian/，让主题、插件和部分设置在多设备间同步。
如果 Android 和 Windows 插件差异很大，可以只提交笔记正文，不提交 .obsidian/workspace.json 这类设备状态文件。
图片附件建议统一放到 attachments/，避免散落在各级目录里。
每次打开 Obsidian 前先 git pull --rebase，写完后再 commit 和 push。

可以准备一个 .gitignore，减少设备状态文件造成的冲突：

1
2
3

.obsidian/workspace.json
.obsidian/workspace-mobile.json
.trash/

Joplin 方案

Joplin 的思路和 Obsidian 不一样。它虽然使用 Markdown 语法，但本地数据主要由应用数据库管理，不是一个可以直接拿来 Git 同步的普通 Markdown 文件夹。因此，不建议把 Joplin 的配置目录或数据库目录直接放进 Git 仓库。

如果你更喜欢 Joplin，有两种更稳的做法：

做法	说明
使用 Joplin 自带同步	通过 WebDAV、Nextcloud、Joplin Cloud、Dropbox、OneDrive 等方式同步，NAS 可以提供 WebDAV 或 Nextcloud
定期导出 Markdown 到 Git	Joplin 作为主力笔记应用，定期把笔记导出为 Markdown，再提交到 NAS Git 仓库做备份

如果 NAS 上已经有 WebDAV 或 Nextcloud，Joplin 直接连 NAS 同步会比 Git 更顺滑。它还可以启用端到端加密，适合不想处理 Git 冲突、但又希望数据尽量在自己控制范围内的人。

Joplin + NAS 的推荐路线是：

NAS 上开启 WebDAV 或部署 Nextcloud。
Joplin Windows 端配置同一个同步目标。
Joplin Android 端配置同一个同步目标。
需要版本备份时，再定期导出 Markdown 到 Git 仓库。

简单判断：

想要“本地 Markdown 文件夹 + 双链 + Git 历史”，选 Obsidian。
想要“传统笔记应用 + 网页剪藏 + 加密同步”，选 Joplin。
想把 NAS Git Server 作为主同步中心，Obsidian 更合适。
想把 NAS 当成私有云同步后端，Joplin 更合适。

五、推荐的笔记目录结构

笔记库不要一开始就设计得太复杂。可以先用下面这种结构：

Notes/
  inbox/
  daily/
  projects/
  resources/
  attachments/
  README.md

含义很直观：

inbox/ 放临时记录。
daily/ 放日记、日志和每日流水。
projects/ 放项目笔记。
resources/ 放长期资料。
attachments/ 放图片、PDF 和其他附件。

如果使用 Obsidian，可以把这个目录直接作为 vault。.obsidian/ 配置是否提交，要看个人习惯。单人多设备使用时可以提交；如果不同设备插件差异很大，也可以只提交部分配置。

六、避免同步冲突

Git 同步笔记的关键不是命令多复杂，而是习惯要稳定。

建议遵守几条规则：

换设备写笔记前，先执行 git pull --rebase。
写完一轮后，及时 commit 和 push。
不要在两台设备上同时长时间编辑同一个文件。
图片和大附件不要无限塞进 Git 仓库。
定期在 NAS 外再备份一份仓库。

如果出现冲突，Git 会标出冲突文件。Markdown 文本冲突通常不难处理，但手机上处理体验比较差，所以尽量在 Windows 上解决冲突。

七、是否需要自动同步

可以给 Windows 写一个简单脚本，把 pull、add、commit、push 串起来。但笔记同步不建议完全无脑自动提交，因为误删、空提交、冲突和大附件都可能被自动推上去。

更稳妥的方式是半自动：

打开笔记前先手动拉取。
写完后运行一个脚本提交。
每次提交信息简单说明这次改了什么。

例如 Windows 可以准备一个 sync-notes.ps1：

git pull --rebase
git add .
git commit -m "更新笔记"
git push

如果没有变更，git commit 会提示 nothing to commit，这不是问题。

八、这个方案的优缺点

方面	说明
优点	数据在本地 NAS，版本历史清晰，可回滚，可迁移，适合 Markdown
缺点	需要理解 Git，冲突需要手动处理，移动端体验不如云同步顺滑
适合	技术用户、本地优先笔记、个人知识库、项目文档
不适合	完全不想接触命令行、需要多人实时协作、频繁同步大附件

我的建议

如果只是想在 Android 和 Windows 之间同步普通 Markdown 笔记，可以先从最小方案开始：NAS 上一个裸仓库，Windows 上 Git for Windows，Android 上 Termux 或 MGit。不要一开始就引入复杂权限、自动化脚本和过度分类。

等这套流程跑顺以后，再考虑 Gitea、自动备份、SSH key 分设备管理、附件分仓库、定时任务等扩展。笔记系统最重要的是长期稳定可用，而不是第一天就把所有功能堆满。

一句话：NAS Git Server 适合把 Markdown 笔记做成本地优先、可追溯、可迁移的个人资料库；它不如云同步省心，但控制权更清楚。

2026 年 Linux 服务器发行版怎么选：Debian、Rocky Linux、AlmaLinux 和 Ubuntu Server 对比

Thu, 07 May 2026 21:03:12 +0800

2026 年选 Linux 服务器发行版，核心问题不是“哪个最好”，而是“哪个最适合你的运维模型”。

如果你需要最稳的社区发行版，Debian 仍然是首选之一。如果你需要 RHEL 兼容生态，但不想直接购买 RHEL，Rocky Linux 和 AlmaLinux 是 CentOS 之后最自然的替代者。如果你重视云端镜像、文档、快速部署和新软件包，Ubuntu Server 仍然最省事。

下面按服务器场景做一次实用对比。

快速结论

发行版	最适合	主要优点	主要注意点
Debian	长期稳定、自托管、基础服务	稳定、简洁、社区强、自由软件传统深	默认软件版本偏保守，企业商业支持不如 RHEL/Ubuntu 明确
Rocky Linux	RHEL 兼容生产环境	接近 RHEL 使用习惯，适合企业迁移 CentOS	软件包更新节奏保守，桌面/新技术体验不是重点
AlmaLinux	RHEL 兼容生产环境、云和企业替代	RHEL 兼容、社区活跃、生命周期清楚	与 RHEL 仍有少量差异，要关注 release notes
Ubuntu Server	云服务器、容器、开发部署	云平台支持好，资料多，部署快，LTS 周期长	Snap、内核/HWE、PPA 等机制需要团队统一规范

一句话：

最稳妥通用：Debian。
企业 RHEL 生态替代：Rocky Linux / AlmaLinux。
云端和开发效率优先：Ubuntu Server。

Debian：坚如磐石的稳定性

截至 2026 年 5 月，Debian 当前 stable 是 Debian 13 trixie。Debian 12 bookworm 已经进入 oldstable 阶段，仍有安全和 LTS 支持，但新部署服务器更建议优先看 Debian 13。

Debian 的特点一直很清楚：

默认包选择保守；
系统结构干净；
不强绑定商业厂商；
社区治理成熟；
适合长期运行的基础服务。

如果你的服务器主要跑这些东西，Debian 很舒服：

Nginx / Apache；
PostgreSQL / MariaDB / Redis；
Docker / Podman；
WireGuard / Tailscale；
文件服务、备份服务、监控服务；
小型自托管应用。

Debian 的优势不是“最新”，而是“少折腾”。很多服务器装好之后，几年内只需要正常安全更新和小版本维护。

适合 Debian 的场景：

你希望系统尽量朴素，不想被发行版厂商策略影响太多。
你熟悉 apt、systemd、Debian 文件布局。
你可以接受软件版本不是最新。
你更重视稳定、安全更新和可预期升级。

不太适合 Debian 的场景：

你需要某些厂商只认证 RHEL 或 Ubuntu。
你需要企业级商业支持 SLA。
你依赖最新内核、最新 GPU 栈或新硬件支持。
团队内部已经全面围绕 RHEL 系生态写了运维规范。

我的判断：个人服务器、自托管、轻量 SaaS、小团队基础服务，Debian 仍然非常值得优先考虑。

Rocky Linux：CentOS 之后的稳健替代

Rocky Linux 的定位很明确：面向需要 RHEL 兼容生态的用户，延续过去 CentOS Linux 在企业生产环境中的角色。

2026 年，Rocky Linux 9 和 Rocky Linux 10 都在支持周期内。Rocky Linux 9 适合更保守的生产环境，Rocky Linux 10 则适合新项目、新硬件和更长未来周期。

Rocky Linux 适合这些场景：

原来跑 CentOS 7 / CentOS 8 的企业环境；
需要 RHEL 系目录结构、包名和运维习惯；
依赖 dnf、RPM、SELinux、firewalld；
软件供应商明确支持 RHEL-compatible 发行版；
内部自动化脚本围绕 Enterprise Linux 编写。

它的优点是迁移阻力小。很多团队过去多年围绕 CentOS 积累了 Ansible playbook、监控规则、审计脚本和安全基线。换到 Rocky Linux，整体心智负担比迁到 Debian 或 Ubuntu 小很多。

Rocky Linux 的注意点：

包版本偏保守，这是 Enterprise Linux 的设计目标，不是缺点。
如果你需要非常新的用户态组件，可能要依赖 EPEL、第三方仓库或容器。
RHEL 兼容不等于所有商业软件厂商都自动提供正式支持，要看厂商认证列表。
Rocky Linux 10 对硬件基线和第三方生态会有新的要求，新上生产前要验证。

我的判断：如果你的服务器环境本来就是 CentOS / RHEL 系，Rocky Linux 是非常自然的替代方案，尤其适合稳定生产环境和企业内部服务。

AlmaLinux：更主动的 RHEL 兼容路线

AlmaLinux 也是 CentOS 之后的重要替代者，定位同样是企业级、长期支持、RHEL 兼容。

它和 Rocky Linux 的共同点很多：

都面向 RHEL 兼容生态；
都适合服务器生产环境；
都有 8、9、10 代长期支持路线；
都适合从 CentOS 迁移；
都能使用大量 Enterprise Linux 生态工具。

不同点在于，AlmaLinux 在 RHEL 兼容之外，会更主动记录和处理上游差异。例如 AlmaLinux 10 提供了面向旧硬件的 x86-64-v2 架构选择，并在 release notes 中明确说明与 RHEL 的差异。

这对一部分用户很有用：他们既想留在 RHEL 生态，又希望社区发行版能在硬件支持、包构建、EPEL 兼容等问题上更灵活。

适合 AlmaLinux 的场景：

你需要 RHEL 兼容，但不想完全被 RHEL 发布策略限制。
你重视社区治理和透明 release notes。
你在云平台、容器镜像、企业工作负载中需要稳定基础系统。
你想从 CentOS 或旧 Enterprise Linux 平滑迁移。

需要注意的是，AlmaLinux 不是“闭眼等于 RHEL”。对严格合规、厂商认证、数据库认证、硬件认证场景，仍然要检查软件供应商是否明确支持 AlmaLinux。

我的判断：Rocky Linux 和 AlmaLinux 都能作为 CentOS 替代。更保守、更贴近传统 CentOS 叙事，可以看 Rocky；更重视社区透明和兼容路线灵活性，可以看 AlmaLinux。

Ubuntu Server：云端支持和部署效率最好

Ubuntu Server 的优势很现实：云平台、文档、社区教程、镜像、自动化工具和开发者生态都很强。

2026 年服务器新部署，主力仍然是 Ubuntu 24.04 LTS。Ubuntu LTS 通常有 5 年标准支持，并可通过 ESM 延长支持周期。对云服务器、容器宿主机、开发环境、CI/CD 节点来说，Ubuntu Server 往往是最快上手的选择。

Ubuntu Server 适合这些场景：

AWS、Azure、Google Cloud、Oracle Cloud、阿里云、腾讯云等云服务器；
Docker、Kubernetes、GitLab Runner、CI/CD；
AI / GPU / CUDA 开发环境；
需要大量教程和社区方案的团队；
开发与生产都希望尽量一致的环境。

Ubuntu 的优点：

云镜像质量高；
官方和第三方文档多；
新硬件支持通常更积极；
LTS 节奏清楚；
开发者工具链更新更方便；
很多商业软件会优先给 Ubuntu 安装说明。

Ubuntu 的注意点：

Snap 在服务器上不是所有团队都喜欢，是否使用要提前规范。
PPA 很方便，但生产环境滥用会增加维护风险。
HWE 内核、云内核、标准内核之间要选清楚。
对极简稳定派来说，Ubuntu 默认系统组件会比 Debian “更热闹”。

我的判断：如果你主要跑云服务器、容器、开发部署、AI 工具链，Ubuntu Server 通常是效率最高的选择。它不是最“纯”的发行版，但它能让很多事情少查资料、少踩坑。

四者怎么选

个人 VPS / 自托管

优先推荐 Debian 或 Ubuntu Server。

如果你想稳定、省心、少折腾，选 Debian。如果你经常照着教程部署新项目，或者需要较新的软件栈，选 Ubuntu Server。

企业生产环境

优先推荐 Rocky Linux、AlmaLinux 或 RHEL。

如果公司过去使用 CentOS，迁移到 Rocky / Alma 成本最低。如果涉及商业数据库、硬件认证、安全合规和厂商支持，要优先确认认证清单。

云原生和容器宿主机

Ubuntu Server、Debian、Rocky / Alma 都能胜任。

如果团队偏开发效率，选 Ubuntu Server。如果追求极简稳定，选 Debian。如果企业标准围绕 RHEL 系，选 Rocky / Alma。

AI / GPU 服务器

优先看 Ubuntu Server，其次看 Rocky / Alma。

原因很简单：NVIDIA、CUDA、PyTorch、TensorFlow、驱动安装教程和社区经验里，Ubuntu 通常最多。企业 GPU 集群如果已经围绕 RHEL 生态建设，则可以选 Rocky / Alma，但要提前验证驱动、CUDA、容器运行时和监控工具。

传统业务系统

优先看 Rocky Linux / AlmaLinux。

传统 Java、数据库、中间件、商业软件、审计和运维规范往往更偏 RHEL 系。此时选择 Rocky / Alma，会比 Debian / Ubuntu 更容易贴合旧体系。

选择时看这几个指标

不要只看发行版名字。服务器选型时，建议按下面几个问题判断：

生命周期：这个版本能维护到哪一年？
升级路径：大版本升级是否成熟？是否支持平滑迁移？
软件来源：是否依赖第三方仓库？第三方仓库谁维护？
安全更新：安全公告、补丁节奏、CVE 处理是否清楚？
硬件支持：CPU、网卡、RAID、GPU、存储控制器是否验证过？
团队经验：团队熟悉 apt 还是 dnf？熟悉 Debian 系还是 RHEL 系？
厂商认证：业务软件是否明确支持该发行版？
自动化资产：现有 Ansible、Terraform、镜像构建脚本是否可复用？

真正决定成本的，往往不是安装 ISO，而是后续五年的升级、审计、排障和交接。

我的推荐组合

如果让我给 2026 年服务器选型一个默认建议：

场景	推荐
个人 VPS、自托管	Debian 13
云服务器、快速部署	Ubuntu Server 24.04 LTS
CentOS 迁移	Rocky Linux 9 / AlmaLinux 9
新企业项目	Rocky Linux 10 / AlmaLinux 10，先验证生态
AI / GPU 开发	Ubuntu Server 24.04 LTS
强合规商业生产	RHEL，或确认厂商支持后使用 Rocky / Alma

简短结论

Debian 的关键词是稳定、简洁、社区和自由软件传统。它适合长期运行的基础服务器。

Rocky Linux 和 AlmaLinux 的关键词是 RHEL 兼容、企业生产和 CentOS 替代。它们适合已有 Enterprise Linux 运维体系的团队。

Ubuntu Server 的关键词是云端、文档、开发效率和生态完整。它适合快速部署、容器、AI/GPU 和云服务器。

没有永远正确的发行版，只有和团队、业务、硬件、生命周期最匹配的发行版。服务器上最好的选择，通常不是最热门的那个，而是五年后你还愿意维护的那个。

Nginx 限速设置：对高频 404、400 扫描请求加 rate limit

Fri, 01 May 2026 05:41:31 +0800

网站日志里如果突然出现大量 404、400，常见原因不是正常用户点错链接，而是自动扫描器在探测 .env、.git、wp-admin、phpmyadmin、xmlrpc.php 这类路径。

这类请求会带来几个问题：

access log 被快速刷大
错误日志里充满无意义记录
静态站点或反代服务被大量无效请求占用连接
真正的问题被扫描噪音淹没

Nginx 可以用 limit_req 和 limit_conn 做限制。不过要先说明一点：Nginx 原生不能直接按“响应状态码是 404 或 400”再限速，因为限速发生在响应生成之前。

实际做法是：对容易产生 404 / 400 的扫描路径、异常来源和全站高频请求提前限速。

基本思路

推荐先分成三层：

全站温和限速，避免单个 IP 高频刷站。
对常见扫描路径严格限速，并直接返回 404。
对单 IP 并发连接数做限制。

更稳妥的上线顺序是：先加扫描路径规则和 access_log off，观察一天；如果还有大量随机路径 404，再加全站 limit_req。

先在 http 里定义限速池

limit_req_zone 和 limit_conn_zone 必须放在 http {} 里，不能放进单个站点的 server {}。

可以直接写到 /etc/nginx/nginx.conf 的 http {} 中：

http {
    # 按客户端 IP 限速，普通页面请求
    limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;

    # 更严格：疑似扫描路径
    limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;

    # 并发连接限制
    limit_conn_zone $binary_remote_addr zone=addr_conn:20m;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

也可以新建一个文件：

`1`	`sudo nano /etc/nginx/conf.d/limit-zones.conf`

写入：

1
2
3

limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;
limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;
limit_conn_zone $binary_remote_addr zone=addr_conn:20m;

前提是你的 nginx.conf 里确实在 http {} 中包含了：

`1`	`include /etc/nginx/conf.d/*.conf;`

再在 server 里使用限速池

站点配置文件一般在 /etc/nginx/sites-enabled/www.example.com，里面通常是 server {}。这里不能再写 limit_req_zone，只能使用前面已经定义好的 zone。

示例：

server {
    root /srv/www/example.com;
    index index.html;
    server_name example.com www.example.com;
    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;

    # 全站温和限速：允许短时突发，降低误伤正常用户的概率
    limit_req zone=perip_general burst=30 nodelay;
    limit_conn addr_conn 20;

    # 对常见扫描路径严格限速，并关闭访问日志
    location ~* ^/(\.env|\.git|\.svn|wp-|wp/|adminer|phpmyadmin|pma|vendor|backup|config|server-status|cgi-bin|xmlrpc\.php) {
        access_log off;
        limit_req zone=perip_scan burst=5 nodelay;
        return 404;
    }

    # 你原来的 location /、listen ssl 等配置继续放这里
}

如果担心全站限速误伤，可以先只加扫描路径这一段：

location ~* ^/(\.env|\.git|\.svn|wp-|wp/|adminer|phpmyadmin|pma|vendor|backup|config|server-status|cgi-bin|xmlrpc\.php) {
    access_log off;
    limit_req zone=perip_scan burst=5 nodelay;
    return 404;
}

这些参数是什么意思

这一行：

`1`	`limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;`

含义如下：

limit_req_zone：定义请求限速用的计数池。
$binary_remote_addr：按客户端 IP 做限速 key，比 $remote_addr 更省内存。
zone=perip_general:20m：创建名为 perip_general 的共享内存区，大小为 20m。
rate=5r/s：每个 IP 平均每秒允许 5 个请求。

这一行：

`1`	`limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;`

和上面类似，只是更严格：

perip_scan：专门给疑似扫描路径使用。
rate=1r/s：每个 IP 每秒只允许 1 个请求。

这一行：

`1`	`limit_conn_zone $binary_remote_addr zone=addr_conn:20m;`

含义如下：

limit_conn_zone：定义并发连接限制用的计数池。
$binary_remote_addr：仍然按客户端 IP 统计。
zone=addr_conn:20m：创建名为 addr_conn 的连接计数共享内存区。

真正限制并发连接数的是：

`1`	`limit_conn addr_conn 20;`

意思是：每个 IP 同时最多 20 个连接。

burst 和 nodelay 怎么理解

例如：

`1`	`limit_req zone=perip_general burst=30 nodelay;`

可以这样理解：

rate=5r/s：长期平均速率是每秒 5 个请求。
burst=30：允许短时间多出来 30 个请求。
nodelay：超过平均速率但还没超过 burst 时，不排队等待，直接处理；超过 burst 才拒绝。

没有 nodelay 时，Nginx 会尝试把部分请求排队延迟处理。对普通网页来说，nodelay 通常更直观；对 API 或特别敏感的接口，可以按实际情况调整。

常见错误：limit_req_zone 放错位置

如果看到这样的报错：

`1`	`2026/04/30 21:33:48 [emerg] 2290771#2290771: "limit_req_zone" directive is not allowed here in /etc/nginx/sites-enabled/example.com:9`

意思就是：limit_req_zone 写进了不允许的位置。

常见错误写法是把它放在 server {} 里：

server {
    root /srv/www/example.com;
    index index.html;
    server_name example.com www.example.com;

    limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;
    limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;
    limit_conn_zone $binary_remote_addr zone=addr_conn:20m;
}

这不行。

一句话记忆：

limit_req_zone 是“定义池子”，放 http {}。
limit_req 是“使用池子”，放 server {} 或 location {}。
limit_conn_zone 是“定义连接池子”，放 http {}。
limit_conn 是“使用连接池子”，放 server {} 或 location {}。

临时封禁明显异常 IP

如果日志里已经确认某几个 IP 持续刷请求，也可以先临时封掉：

deny 45.95.42.164;
deny 185.177.72.51;
deny 185.177.72.5;
deny 185.177.72.56;
deny 185.177.72.58;

这类 deny 可以放在 server {} 里，也可以放在具体 location {} 里。是否长期保留，要看误伤风险和访问来源。

检查并重载

改完先检查配置：

`1`	`sudo nginx -t`

没有问题再重载：

`1`	`sudo systemctl reload nginx`

不要直接重启服务。reload 会让 Nginx 平滑加载新配置，风险更小。

Ubuntu 26.04 LTS 的 GPU 与硬件支持更新：CUDA、ROCm、DPC++ 和更多平台变化

Sun, 26 Apr 2026 19:35:57 +0800

如果上一篇更像是 Ubuntu 26.04 LTS 的桌面总览，那这篇可以看作是它的硬件和算力补充版。官方在 26.04 这一轮里，把不少和 AI、GPU 计算、平台兼容性直接相关的内容都推进了主仓库或正式支持范围里。

先说结论：这次最值得关注的，不只是桌面和内核升级，而是 Ubuntu 正在把 Intel、NVIDIA、AMD 三家的 GPU 计算栈都更系统地纳入发行版生态。

1. Intel DPC++ 与相关组件进入 Ubuntu Archive

从 26.04 开始，Intel 开源的 oneAPI DPC++ 编译器已经可以直接从 Ubuntu Archive 获取，用来构建 SYCL 代码。运行时里也包含了面向 Intel GPU 的适配器。

同时进入 Ubuntu 仓库的，还有两个相关组件：

oneDPL，也就是 DPC++ library，提供更高生产力的开发接口
oneDNN，并且是基于 dpclang-6 构建，可在 Intel GPU 上运行

这意味着，如果你本身就在看 SYCL、异构计算或者 Intel GPU 上的 AI 工作负载，Ubuntu 现在给出的路径更直接了，不用再完全依赖单独维护的一套外部环境。

官方还特别提醒了一点：如果要实际调用这些 Intel GPU 相关能力，用户需要在 render 组里。

2. NVIDIA CUDA toolkit 现在也能直接 `apt install`

对很多开发者和运维来说，这可能是这份更新里最实用的一条。

从 26.04 开始，NVIDIA CUDA toolkit 已经可以直接通过 Ubuntu Archive 安装。命令就是：

`1`	`sudo apt install cuda-toolkit`

这背后的意义，不只是“少输几条命令”。

对面向 Ubuntu 分发软件的开发者来说，新的模式意味着可以直接声明对 CUDA runtime 的依赖，后续安装与兼容性由 Ubuntu 在发行版层面处理。这会让 CUDA 在 Ubuntu 上的可获得性更高，也更接近系统原生能力，而不是额外叠一层单独维护的外部软件栈。

3. AMD ROCm 7.1.0 进入 Universe

AMD 这边，Ubuntu Universe 里现在已经包含 ROCm 7.1.0。

这套库主要提供的是：

面向 AMD GPU 的 AI 训练与推理后端能力
机器学习与高性能计算相关的软件基础设施

官方还提到，Canonical 在自己的 CI/CD 流程里会持续测试 ROCm 相关组件，除了 autopkgtests，还覆盖了一些用户态应用，包括：

llama.cpp
pytorch
Blender
Lemonade Server

这条信息其实很关键，因为它说明 Ubuntu 不是单纯“把包放进仓库”，而是在按一个可维护的软件栈去验证它。

4. 这一轮的重点，其实是三家 GPU 生态都在落地

把 DPC++、CUDA 和 ROCm 放在一起看，会更容易理解 26.04 的方向：

Intel：推进 SYCL / oneAPI 相关能力进入官方仓库
NVIDIA：让 CUDA toolkit 具备发行版级的安装路径
AMD：把 ROCm 7.1.0 纳入 Universe，并做持续测试

如果你平时会在 Ubuntu 上碰这些场景，这一轮更新会比较有感：

本地大模型推理
GPU 加速训练或微调
Blender、科学计算、HPC
需要在多种 GPU 平台之间切换的开发环境

换句话说，Ubuntu 现在不只是“能装显卡驱动”，而是开始更完整地承接 AI 和 GPU 计算所需的用户态软件栈。

5. NVIDIA Dynamic Boost 默认启用

从 25.04 开始，支持的 NVIDIA 笔记本已经默认启用 Dynamic Boost。

这个功能的逻辑很直接：系统会根据当前负载，在 CPU 和 GPU 之间动态分配功耗。对游戏场景来说，常见收益就是在需要的时候把更多功率给 GPU，以换取更高性能。

不过它有两个前提：

设备接着交流电
GPU 负载足够高

在电池供电状态下，它不会介入。

6. Intel 新一代核显和独显支持继续往前走

Ubuntu 这一轮也把对新 Intel GPU 的支持继续往前推，重点包括：

集成显卡：

Intel Core Ultra Xe2
Intel Core Ultra Xe3

独立显卡：

Intel Arc 5 B570
Intel Arc 5 B580
Intel Arc Pro B50
Intel Arc Pro B60
Intel Arc Pro B65
Intel Arc Pro B70

围绕这批设备，官方还列出了一些已经到位的特性：

基于 Intel Embree 的 GPU 和 CPU 光线追踪渲染性能提升，像 Blender 4.2+ 这类应用可受益
“Battlemage” 设备支持 AVC、JPEG、HEVC 和 AV1 的硬件视频编码
Intel Compute Runtime 引入新的 CCS 优化
Intel Xe GPU 调试支持已启用

如果你更关注后续版本，25.10 还会继续把一些新能力带进来，例如：

借助 Linux kernel 6.17 初步支持代号 Panther Lake 的下一代 Intel 客户端平台
改进 IOMMU、PCIe 子系统和多 GPU 支持
Mesa 25.2.3 为 Battlemage 和 Panther Lake 打开 VK_KHR_shader_bfloat16
intel-media-driver 25.3.0 增加 Panther Lake 解码和 VP9 编码支持
intel-compute-runtime 25.31 调整 Level Zero 的 USM 池和本地显存事件分配策略
level-zero 1.24 与 level-zero-raytracing 1.1.0 带来更完整的规范与 RTAS 扩展支持

7. Nvidia 桌面机的挂起恢复也更稳了

从 25.10 开始，Ubuntu 在专有 Nvidia 驱动里启用了挂起恢复支持，以减少桌面机唤醒后的损坏和卡死问题。

这类改动不算“看得见的新功能”，但对实际日用稳定性很重要，尤其是长期开机、经常挂起恢复的桌面环境。

8. ARM、树莓派、RISC-V 和 IBM Z 也有硬门槛变化

除了 GPU 软件栈，这份发布说明里还有几条平台层面的变化很值得单独记一下。

ARM64 桌面平台

从 25.10 开始，linux-generic 的 ARM64 内核会提供更广泛的桌面兼容性，覆盖那些使用 UEFI 启动的 ARM64 桌面平台。

Raspberry Pi 新启动布局

25.10 引入、26.04 继续调整的一个变化，是树莓派启动分区的新布局。

它的目标是提升启动可靠性：新写入的启动资源会先被“测试”，确认没问题后才会提交为新的 “known good” 集合。

这里最需要注意的是固件时间要求：

Pi 3 / 3+ / CM3+ / Zero 2W：不需要额外操作，固件在镜像内
Pi 4 / 400 / CM4：启动固件日期不得早于 2022-11-25
Pi 5 / 500 / CM5：启动固件日期不得早于 2025-02-11

检查命令是：

`1`	`sudo rpi-eeprom-update`

如果固件太旧，并且你使用的是 Ubuntu 24.04 LTS 或更新版本，可以这样更新：

1
2

sudo rpi-eeprom-update -a
sudo reboot

Raspberry Pi 桌面镜像转向 desktop-minimal

从 25.10 开始，树莓派版 Ubuntu Desktop 镜像改为基于 desktop-minimal，而不是完整的 desktop seed。

官方给出的收益很明确：默认预装应用更少，未压缩镜像和实际系统都能节省大约 777MB 空间。

如果升级后想批量移除这批默认应用，可以使用：

`1`	`sudo apt purge ubuntu-desktop --autoremove`

如果你想保留其中某些应用，先用 apt 把它们标记为手动安装即可。

树莓派 swap 交给 cloud-init

从 25.10 开始，树莓派桌面镜像里的 swap 文件创建改由 cloud-init 负责。
如果你想在首次启动前自定义 swap 大小，可以直接修改启动分区上的 user-data。

RISC-V 门槛上调

从 25.10 开始，Ubuntu 26.04 LTS 的 RISC-V 版本要求硬件实现 RVA23S64 ISA profile。

不满足这个要求的设备，已经不能运行 Ubuntu 26.04 LTS。如果你手里还是较早的 RVA20 处理器板卡，那还得继续留在 Ubuntu 24.04 LTS 这一代支持线上。

按照官方说明，截至 2026 年 4 月，现实里还没有可用的 RVA23S64 硬件，因此当前唯一受支持的平台，其实是基于 QEMU 并使用 -cpu rva23s64 配置的虚拟化环境。

IBM Z 最低要求提升到 z15

从 26.04 开始，s390x 架构最低要求提升到 z15。

这意味着：

z14 / LinuxONE II 以及更早平台，已经不能安装 Ubuntu 26.04 LTS
z15 / LinuxONE III 及更新平台，会得到更好的性能表现

9. 这篇内容更适合哪些人先看

如果你属于下面这些场景，这篇比桌面总览更值得优先看：

在 Ubuntu 上做 CUDA、ROCm、SYCL 或本地 AI 推理
用 Intel、NVIDIA、AMD GPU 做开发或计算任务
维护 Raspberry Pi、ARM64、RISC-V、IBM Z 等非标准 x86 平台
对升级后的驱动、运行时、仓库可用性和平台门槛更敏感

10. 一句话总结

Ubuntu 26.04 LTS 在硬件和 AI 软件栈上的重点，不是某一家显卡单独增强了什么，而是 Intel 的 DPC++、NVIDIA 的 CUDA、AMD 的 ROCm 都开始以更官方、更多仓库内、也更可维护的方式进入 Ubuntu 生态。

如果你过去把 Ubuntu 当作“先装系统，再自己拼 GPU 环境”的底座，那从 26.04 开始，它已经更像一个愿意主动承接 AI 与异构计算工作负载的发行版了。

Ubuntu 26.04 LTS 发布：桌面大更新，GNOME 50 和 Linux 7.0 全来了

Sun, 26 Apr 2026 16:10:25 +0800

Ubuntu 26.04 LTS 已在 2026 年 4 月 23 日 发布，代号是 Resolute Raccoon。这次是新的长期支持版，官方支持周期到 2031 年 4 月；如果使用 Ubuntu Pro，安全维护可延长到 10 年。

如果你是从 Ubuntu 24.04 LTS 升级上来，这一版不只是一次常规更新，而是把 24.10、25.04、25.10 之间的主要变化一起带了进来。所以这篇更适合当一份“升级前先看什么”的快速摘要。

如果只看这版最核心的更新，可以先记住四件事：

GNOME 50 进入 LTS，桌面体验和显示支持明显往前走了一步
Linux kernel 7.0 成为新基线，底层硬件支持和后续维护周期一起更新
Ubuntu Desktop 正式全面转向 Wayland
默认应用集体换新，Firefox、LibreOffice、Thunderbird、GIMP 都是大版本更新

1. 重点更新先看这几项

Ubuntu 26.04 LTS 是长期支持版，标准支持到 2031-04
桌面环境升级到 GNOME 50
通用内核升级到 Linux kernel 7.0
Ubuntu Desktop 会话现在只提供 Wayland
从更老版本升级时，不能直接跨太多版本跳到 26.04

如果你现在还在 Ubuntu 22.04 LTS 或 25.04，官方建议先升到 Ubuntu 24.04 LTS 或 25.10，再继续升级到 26.04 LTS。

2. 最大变化一：GNOME 50 进 LTS 了

这次桌面侧最明显的变化，是 GNOME 50 终于进了 LTS。对普通用户来说，它带来的不是某一个单点新功能，而是整套桌面体验一起变顺了：

小屏设备和窄窗口的可用性更好
通知支持按应用分组
HDR、VRR、分数缩放这些显示相关能力继续完善
远程桌面、Wayland、NVIDIA 驱动下的流畅度和稳定性都在往前走
无障碍支持继续增强，Orca 屏幕阅读器也有明显更新

Ubuntu 自己也补了一些更实用的改动：

GNOME Shell 全局搜索可以直接搜可用的 snap 应用
也可以在搜索里直接发起网页搜索
Yaru 主题继续向上游 GNOME 风格靠拢
snap 应用和桌面的权限、文件访问、拖放体验更自然

如果你平时主要用桌面版，这一代 LTS 的重点其实不是“样子大变”，而是很多过去零散的小摩擦在这一版里一起被磨平了。

3. 最大变化二：默认应用大面积换新

和 24.04 LTS 相比，26.04 LTS 自带应用整体更新幅度不小：

Firefox 升到 150
LibreOffice 从 24.2 升到 25.8
Thunderbird 升到 140
GIMP 从 2.10 跨到 3.2

另外还有几项和日常使用关系很大的替换：

PDF 查看器改为 Papers，替代 Evince
图片查看器改为 Loupe
终端改为 Ptyxis
系统监视器改为 Resources
默认视频播放器改为 Showtime

这些变化背后的共同方向很明确：Ubuntu 正在更彻底地拥抱新一代 GTK4、libadwaita 和部分 Rust 重写过的 GNOME 应用栈。

4. 最大变化三：Wayland 成了唯一桌面会话

这一条对很多老用户最关键。

从 25.10 开始的变化，在 26.04 LTS 上正式落稳：Ubuntu Desktop 现在只运行在 Wayland 后端上，因为 GNOME Shell 已经不能再作为 X.org 会话运行。

这不等于老应用全都不能用了。官方说明里明确提到，面向 X.org 的应用仍然可以通过 XWayland 兼容层继续运行。但如果你的工作流里还依赖某些老显卡驱动、远程桌面方式、录屏工具或输入法细节，这一条依然值得你在升级前先确认。

5. 最大变化四：Linux kernel 7.0 和底层栈一起升级

Ubuntu 26.04 LTS 的 GA generic 栈从 Linux 6.8 升到 Linux 7.0，HWE 栈也统一到 7.0。

官方点到的几项底层变化里，比较值得普通用户和运维注意的是：

桌面版和服务器版默认启用 crash dump
sched_ext 带来新的调度扩展机制，方便开发者用 eBPF 方式实现调度策略
linux-lowlatency 二进制包退出，改由 linux-generic 配合 lowlatency-kernel 用户态包实现低延迟调优
amd64v3 架构变体可选启用，但默认仍然是 opt-in

如果你机器比较新，amd64v3 是一个可以关注的点。官方给出的启用方式是：

1
2
3

echo 'APT::Architecture-Variants "amd64v3";' | sudo tee /etc/apt/apt.conf.d/99enable-amd64v3
sudo apt update
sudo apt upgrade

不过这项能力默认不会自动打开，Ubuntu 还是优先把兼容性放在第一位。

6. 硬件要求和安装门槛

官方给出的 Ubuntu Desktop 26.04 LTS 推荐底线是：

2 GHz 双核处理器或更高
至少 6 GB RAM
至少 25 GB 可用存储空间

如果机器配置偏低，官方更建议考虑 Xubuntu、Lubuntu 这类官方风味版本。
服务器版门槛更低，文档里提到可以低到 1.5 GB RAM 和 4 GB 存储起步，具体还是要看你的服务负载。

7. 这版适合谁优先升级

如果你现在就在 24.04 LTS，并且想要这些东西，26.04 LTS 会很值得看：

更新一代完整桌面栈，而不只是补丁修修补补
更成熟的 Wayland 和显示支持
更新的默认应用生态
新一代内核与更长的后续支持周期

但如果你高度依赖老 X11 工作流、特殊驱动、定制桌面插件，或者你现在的生产环境对“能跑就别动”非常敏感，那升级前最好还是先过一轮兼容性验证。

8. 一句话总结

Ubuntu 26.04 LTS 的价值，不在于某一个特别炸眼的新功能，而在于它把过去两个年的桌面、内核、应用和兼容性演进，一次性沉淀进了新的 LTS 基线里。

如果你要找一句最简短的判断，那就是：这是一版偏“整体变稳、整体变新”的 Ubuntu LTS，而不是只靠单个卖点撑起来的版本。

理解 nftables 框架：表、链、规则和集合

Sat, 18 Apr 2026 10:31:12 +0800

学习 nftables 时，容易一开始就陷入命令细节：怎么添加规则、怎么删除 handle、怎么写端口匹配。命令当然重要，但如果先把框架概念理清楚，后面读规则、排查问题和设计规则集都会轻松很多。

可以把 nftables 理解成一套分层结构：

table 负责隔离规则空间。
family 决定规则处理哪类网络协议。
chain 决定规则在什么阶段执行。
rule 负责具体匹配和动作。
set、map、verdict map 用来减少重复规则，让规则集更易维护。

下面按概念逐层说明。

table：规则的命名空间

table 是 nftables 里最外层的规则容器。不同 table 之间相互隔离，因此常见做法是把一组相关规则放进同一个 table。

例如，你可以把过滤规则、NAT 规则或自定义测试规则分开放。这样做的好处是边界清晰：调试时知道自己在改哪一组规则，清理时也不容易误删无关内容。

table 本身不会直接处理数据包。真正参与数据包处理的是 table 里面的 chain 和 rule。

family：规则面对哪类协议

创建 table 时需要选择 family。它决定这张表里的规则适用于哪类数据包。

常见 family 可以这样理解：

ip：只处理 IPv4。
ip6：只处理 IPv6。
inet：同时处理 IPv4 和 IPv6。
arp：处理 ARP。
bridge：处理桥接层流量。
netdev：更靠近网络设备入口，适合较早阶段处理流量。

日常写普通防火墙规则时，inet 很常用。它可以把 IPv4 和 IPv6 规则放在同一个 table 里，避免维护两套结构相似的规则。

chain：规则执行的位置

chain 是 rule 的列表。数据包进入某个 hook 后，会按顺序经过 chain 里的规则。

chain 大致可以分为两类：

基本 chain：挂到内核网络路径的某个 hook 上，会被数据包流程主动调用。
常规 chain：不直接挂 hook，需要被其他规则跳转调用。

基本 chain 通常会指定几个关键属性：

type：这条 chain 的用途，例如 filter、nat、route。
hook：挂在哪个处理阶段，例如 prerouting、input、forward、output、postrouting。
priority：同一个 hook 上有多条 chain 时，谁先执行。
policy：没有规则匹配时的默认动作，常见是 accept 或 drop。

理解 chain 的关键是：规则不是“随便写在哪里都能生效”。同一条规则放在 input、forward 或 output，含义完全不同。

rule：匹配条件加动作

rule 是 nftables 里真正做判断的地方。它通常由两部分组成：

匹配条件：例如源 IP、目标 IP、协议、端口、接口、连接状态。
动作：例如 accept、drop、reject、counter、jump、return。

规则会按顺序求值。数据包命中某条会终止流程的动作后，就不会继续执行后面的规则。没有命中时，则继续往下走，直到 chain 结束或触发默认策略。

这也是为什么规则顺序很重要：更具体的规则通常要放在更宽泛的规则前面，否则可能永远没有机会被执行。

set：把一组值放在一起

如果有很多 IP、端口或接口需要匹配，直接写多条规则会很难维护。set 用来把一组同类型的值集中管理。

例如，一组可信 IP、一组禁止访问的端口、一组需要限速的地址，都可以放进 set。规则只需要判断某个值是否属于这个 set。

set 的好处是：

规则数量更少。
可读性更好。
后续增删元素更方便。

当规则里出现大量重复条件时，通常就该考虑用 set。

map：把匹配值映射成结果

map 可以理解成“查表”。它根据一个输入值返回一个结果。

例如，不同端口映射到不同标记，不同地址映射到不同处理参数，都可以通过 map 表达。相比写多条 if/else 式规则，map 更集中，也更容易维护。

set 关心的是“是否在集合里”，map 关心的是“这个值对应什么结果”。

verdict map：把匹配值映射成动作

verdict map 是 map 的一个重要用法：它把匹配值映射成 verdict，也就是规则动作。

例如，不同 IP 段可以对应 accept、drop 或跳转到不同 chain。这样可以把很多分支判断压缩到一个结构里。

当规则集开始变复杂时，verdict map 很有用。它能减少重复规则，也能把策略表达得更像一张表，而不是一长串判断语句。

从概念看规则设计

设计 nftables 规则时，可以按这个顺序思考：

先确定规则属于哪个 family。
再决定放进哪个 table。
然后选择合适的 hook 和 chain。
最后编写具体 rule。
如果重复条件很多，再引入 set、map 或 verdict map。

这样写出来的规则会更容易维护，也更容易排错。

小结

nftables 的概念并不复杂，但层级很重要：

table 管规则边界。
family 管协议范围。
chain 管执行位置。
rule 管匹配和动作。
set、map、verdict map 管复杂度。

先理解这些概念，再去看具体命令，会比直接背命令更稳。尤其是在规则集变多以后，概念清楚能帮助你判断：问题到底出在协议范围、执行阶段、规则顺序，还是匹配条件本身。

参考

https://docs.redhat.com/zh-cn/documentation/red_hat_enterprise_linux/10/html/configuring_firewalls_and_packet_filters/concepts-in-the-nftables-framework

nftables 快速入门：表、链、规则和常用操作

Sat, 18 Apr 2026 10:22:07 +0800

nftables 是 Linux 上常用的包过滤和防火墙规则管理工具。如果只是做设备联网控制、流量统计、端口匹配或简单限速，不需要一开始就把完整规则体系全部学完，先理解三个概念就够了：

table：规则的容器。
chain：规则执行的位置，通常会挂到某个 hook 上。
rule：真正的匹配条件和动作。

下面整理一套最小可用的入门流程，适合先在测试环境里做实验。

基础结构

先准备几个变量，后面的命令会复用：

table=customtable
chain=custom_control
target=drop
ip=192.168.18.251
mac=00:00:01:02:03:04

创建一个同时支持 IPv4 和 IPv6 的 inet table：

`1`	`nft add table inet $table`

再创建一条挂在 forward 阶段的 chain：

`1`	`nft add chain inet $table $chain { type filter hook forward priority 0\; }`

这里的 type filter 表示做过滤规则，hook forward 表示处理经过转发的数据包。

常见匹配方式

按源 IP 匹配，通常可以理解为设备上传方向：

`1`	`nft add rule inet $table $chain ip saddr $ip $target`

按目标 IP 匹配，通常可以理解为设备下载方向：

`1`	`nft add rule inet $table $chain ip daddr $ip $target`

按 MAC 地址匹配时，可以用 ether saddr 控制上行：

`1`	`nft add rule inet $table $chain ether saddr $mac $target`

需要注意的是，在经过桥接、转发或地址转换的网络里，下行包未必能可靠用目标 MAC 过滤。实际做设备联网控制时，优先从 ether saddr 或 IP 规则开始验证。

匹配端口时，可以同时覆盖 TCP 和 UDP：

`1`	`nft add rule inet $table $chain { tcp, udp } dport 22 $target`

如果要匹配端口范围，可以使用比较表达式：

`1`	`nft add rule inet $table $chain tcp dport \>= 1024 $target`

统计单个设备流量

如果只是想统计某个 IP 的上下行流量，可以用 counter return。这样命中后记录计数并返回，后面还有其他统计规则时，能减少继续匹配的开销。

1
2

nft add rule inet $table $chain ip saddr $ip counter return
nft add rule inet $table $chain ip daddr $ip counter return

查看统计结果：

`1`	`nft list chain inet $table $chain`

如果需要看到每条规则的 handle，加上 -a：

`1`	`nft -a list chain inet $table $chain`

handle 很重要，因为 nftables 删除单条规则时通常要靠它定位。

简单限速

限速可以用 limit rate over。例如按 MAC 地址限制超过指定速率的流量：

rate=10
unit=mbytes

nft add rule inet $table $chain ether saddr $mac limit rate over $rate $unit/second drop

这里的 mbytes、kbytes 可以按日常理解的 M、K 来看，不需要再手动做 8 倍换算。实际使用时建议先用较宽松的值测试，确认命中方向和效果后再收紧。

删除和清理规则

先查看带 handle 的规则：

`1`	`nft -a list chain inet $table $chain`

再按 handle 删除某条规则：

`1`	`nft delete rule inet $table $chain handle <handle>`

清空某条 chain：

`1`	`nft flush chain inet $table $chain`

删除 chain：

`1`	`nft delete chain inet $table $chain`

删除整个 table：

`1`	`nft delete table inet $table`

日常调试时，建议先只清理自己创建的 table，不要直接改系统或其他服务自动生成的 table。这样即使规则写错，也更容易回滚。

使用建议

使用 nftables 时，可以优先自己创建独立的 table 和 chain。这样做有两个好处：

不容易和系统已有规则混在一起。
调试、清空和删除都更安全。

另外，规则写完后一定要用 nft list chain 看实际命中情况。尤其是 MAC、接口、端口和限速规则，不同设备、桥接方式和系统版本下表现可能不同，先小范围测试比一次性写复杂规则更稳。

参考

https://www.right.com.cn/forum/thread-8369750-1-1.html

go2rtc 直连小米摄像头 RTSP：接入 NVR、HomeKit 与 Frigate

Sat, 11 Apr 2026 08:14:47 +0800

这篇记录如何用 go2rtc 直接拉取小米摄像头流，并统一分发给 NVR、HomeKit、Frigate。

Docker 部署示例

services:
  go2rtc:
    container_name: go2rtc
    image: alexxit/go2rtc:master-hardware
    restart: always
    network_mode: host
    privileged: true
    environment:
      - TZ=Asia/Shanghai
    volumes:
      - /vol1/1000/docker/go2rtc:/config

go2rtc 后台地址：

`1`	`http://192.168.3.217:1984/`

流配置示例

streams:
    micam1:
     - xiaomi://xxx
    #H265转H264,Homekit预览会用到
    #micam1_h264:
     #- ffmpeg:micam1#video=h264#width=1280#height=720#hardware#raw=-r 15
    micam2:
     - xiaomi://xxx
    micam3:
     - xiaomi://xxx

RTSP 流地址格式：

`1`	`rtsp://192.168.3.217:8554/micam1`

画质与参数

画质由 0 到 5 指定：

0 通常表示自动
1 表示 sd
2 表示 hd（go2rtc 默认）

有些新摄像头的 HD 可能在 3。旧型号在 3 可能出现损坏的编解码配置，所以不建议一刀切。

你可以通过 subtype=hd/sd/auto/0-5 指定画质：

1
2

streams:
  xiaomi1: xiaomi://***&subtype=sd

双摄场景可使用第二通道参数 channel=2：

1
2

streams:
  xiaomi1: xiaomi://***&channel=2

小结

用 go2rtc 统一拉流后，RTSP 可以同时供 NVR 录像、Frigate 分析、HomeKit 预览，维护成本会低很多。

参考链接

摄像头支持列表：https://github.com/AlexxIT/go2rtc/issues/1982
官方说明出处：https://github.com/AlexxIT/go2rtc/blob/master/internal/xiaomi/README.md
Docker 镜像：https://hub.docker.com/r/alexxit/go2rtc

Windows 任务管理器数据暂停不刷新，通常是更新速度被设为已暂停

Thu, 09 Apr 2026 18:15:53 +0800

有时候打开 Windows 任务管理器，会发现“进程”或“性能”页里的数据像是卡住了一样，CPU、内存、磁盘或网络数值长时间没有变化。乍一看很像系统异常，但实际运行中的程序、网络传输和资源占用都还在正常变化。

这种情况通常不是系统真的停住了，而是任务管理器的刷新频率被改成了“已暂停”。

现象

常见表现包括：

“进程”页的 CPU、内存等数据不再跳动
“性能”页的曲线长时间不更新
明明还有程序在运行，但任务管理器看起来像是静止状态

下面是问题出现时的界面示例：

原因

任务管理器支持调整“更新速度”，可以设置为高、正常、低，或者直接暂停。

如果这里被设成了“已暂停”，界面上的各项统计数据就不会继续刷新，因此看起来像是 CPU、内存或网络信息全部停住了。

如下图所示，这个选项通常可以在任务管理器顶部菜单里的“查看”中找到：

远程访问飞牛 NAS 的两种方式与对比

Sat, 04 Apr 2026 11:00:00 +0800

飞牛 NAS 常见的远程访问方式主要有两种：

公网 IP 直连
FN Connect 远程访问服务

下面按“怎么用 + 注意点 + 适用场景”做一个可直接参考的整理。

方式一：公网 IP 直连

适用于家用网络有公网 IP的场景，需要在路由器中配置端口转发。之后在浏览器或飞牛 App 中，输入公网 IPv4/IPv6 地址和端口号即可访问。也可以进一步使用DDNS，然后通过域名访问。

注意事项

飞牛私有云 fnOS 默认端口： HTTP = 8000，HTTPS = 8001
如果已配置端口转发，访问地址必须带端口号，否则无法正确访问到飞牛 NAS。
公网 IP 直连通常没有额外中继，速度折损更小。
若未正确配置安全证书，HTTP 为明文传输，请仅在可信网络环境使用。
很多宽带会阻断常用端口如 80, 8080等，如常用端口无法联通，可尝试冷门端口。

方式二：FN Connect 远程访问服务

FN Connect 是飞牛提供的远程访问服务。
使用后你会获得唯一的 FN ID，用于标识你的飞牛 NAS，并通过其对应方式进行远程访问。

注意事项

使用 FN Connect 需要注册或登录飞牛账号。
FN Connect 会为你的 FN ID 对应子域名提供 SSL 证书，可通过 HTTPS 安全访问。
FN Connect 会根据当前网络环境自动选择更优连接方式。
当可公网直连时，网页端可选择是否使用公网 IP 直连。
FN Connect 的中继转发会产生流量成本，因此存在限速策略。

两种方式对比

维度	公网 IP 直连	FN Connect
上手难度	需要公网 IP + 路由器端口转发	登录账号后按引导配置，门槛更低
访问速度	通常更快、链路更直接	直连时接近直连；中继时可能限速
安全性	取决于你自己的证书与暴露策略	默认支持证书，HTTPS 访问更省心，依赖于飞牛本身的安全
维护成本	需要自行维护网络与安全配置	日常维护成本较低
适合人群	有网络配置经验、追求性能	追求易用与稳定的普通用户

选择建议

如果你熟悉网络配置、希望更高带宽和更低延迟，优先考虑公网 IP 直连。
如果你更重视易用性和安全接入体验，优先考虑 FN Connect。
实际使用中可以混合：默认 FN Connect，条件允许时切换公网 IP 直连。

Ubuntu 上自动更新 Let's Encrypt 证书（Certbot + Nginx）

Thu, 02 Apr 2026 00:00:00 +0000

Let’s Encrypt 证书有效期只有 90 天，线上站点必须配置自动续期，避免证书过期导致 HTTPS 报错。

手动添加 crontab（推荐示例）

如果你希望自己显式管理续期任务，可用 root 用户添加：

`1`	`sudo crontab -e`

加入下面一行（每天凌晨 3 点执行一次）：

`1`	`0 3 * * * certbot renew --pre-hook "systemctl stop nginx" --post-hook "systemctl start nginx" >> /tmp/certbot-renew.log 2>&1`

这条命令的含义：

0 3 * * *：每天 03:00 执行
certbot renew：检查并续期即将过期的证书（不会每天都真正续期）
--pre-hook：续期前停止 Nginx，避免 80/443 端口冲突（常见于 standalone 模式）
--post-hook：续期后启动 Nginx
>> /tmp/certbot-renew.log 2>&1：把日志追加写入文件，方便排查

建议先做一次模拟续期

定时任务加完后，先手动验证流程是否可用：

`1`	`sudo certbot renew --pre-hook "systemctl stop nginx" --post-hook "systemctl start nginx" --dry-run`

看到模拟续期成功，再交给定时任务长期运行。

常见注意点

如果你使用的是 webroot 或 nginx 插件，很多场景下不需要停 Nginx，可改为续期后重载配置：

`1`	`certbot renew --deploy-hook "systemctl reload nginx"`

certbot renew 只会在证书接近过期时才执行实际续期，所以每天跑一次是正常且常见做法。
建议把日志目录改成长期可追踪位置（如 /var/log/letsencrypt/），便于长期运维。

运维 on KnightLi的博客

用 NAS 自建 Git Server 同步本地 Markdown 笔记

方案适合谁

一、在 NAS 上安装 Git Server

二、Windows 端设置

三、Android 端设置

四、Obsidian 和 Joplin 怎么落地

Obsidian 方案

Joplin 方案

五、推荐的笔记目录结构

六、避免同步冲突

七、是否需要自动同步

八、这个方案的优缺点

我的建议

2026 年 Linux 服务器发行版怎么选：Debian、Rocky Linux、AlmaLinux 和 Ubuntu Server 对比

快速结论

Debian：坚如磐石的稳定性

Rocky Linux：CentOS 之后的稳健替代

AlmaLinux：更主动的 RHEL 兼容路线

Ubuntu Server：云端支持和部署效率最好

四者怎么选

个人 VPS / 自托管

企业生产环境

云原生和容器宿主机

AI / GPU 服务器

传统业务系统

选择时看这几个指标

我的推荐组合

简短结论

相关链接

Nginx 限速设置：对高频 404、400 扫描请求加 rate limit

基本思路

先在 http 里定义限速池

再在 server 里使用限速池

这些参数是什么意思

burst 和 nodelay 怎么理解

常见错误：limit_req_zone 放错位置

临时封禁明显异常 IP

检查并重载

推荐参数

Ubuntu 26.04 LTS 的 GPU 与硬件支持更新：CUDA、ROCm、DPC++ 和更多平台变化

1. Intel DPC++ 与相关组件进入 Ubuntu Archive

2. NVIDIA CUDA toolkit 现在也能直接 apt install

3. AMD ROCm 7.1.0 进入 Universe

4. 这一轮的重点，其实是三家 GPU 生态都在落地

5. NVIDIA Dynamic Boost 默认启用

6. Intel 新一代核显和独显支持继续往前走

7. Nvidia 桌面机的挂起恢复也更稳了

8. ARM、树莓派、RISC-V 和 IBM Z 也有硬门槛变化

ARM64 桌面平台

Raspberry Pi 新启动布局

Raspberry Pi 桌面镜像转向 desktop-minimal

树莓派 swap 交给 cloud-init

RISC-V 门槛上调

IBM Z 最低要求提升到 z15

9. 这篇内容更适合哪些人先看

10. 一句话总结

Ubuntu 26.04 LTS 发布：桌面大更新，GNOME 50 和 Linux 7.0 全来了

1. 重点更新先看这几项

2. 最大变化一：GNOME 50 进 LTS 了

3. 最大变化二：默认应用大面积换新

4. 最大变化三：Wayland 成了唯一桌面会话

5. 最大变化四：Linux kernel 7.0 和底层栈一起升级

6. 硬件要求和安装门槛

7. 这版适合谁优先升级

8. 一句话总结

相关链接

理解 nftables 框架：表、链、规则和集合

table：规则的命名空间

family：规则面对哪类协议

chain：规则执行的位置

rule：匹配条件加动作

set：把一组值放在一起

map：把匹配值映射成结果

verdict map：把匹配值映射成动作

从概念看规则设计

小结

参考

nftables 快速入门：表、链、规则和常用操作

基础结构

2. NVIDIA CUDA toolkit 现在也能直接 `apt install`