維運 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 端 clone 倉庫，用常見編輯器寫筆記。
Android 端 clone 同一個倉庫，用 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。

首次 clone：

`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 使用者授權裡。然後在手機本地選擇一個目錄 clone 倉庫：

`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 不是單純「把套件放進倉庫」，而是把 ROCm 當成一套可維護的軟體堆疊來驗證。

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）

Fri, 03 Apr 2026 00:00:00 +0000

Let’s Encrypt 憑證有效期只有 90 天，正式站點一定要配置自動續期，避免憑證過期導致 HTTPS 報錯。

如果你已經用 Certbot 申請過憑證，通常只差兩件事：

配置定時任務
驗證續期流程是否真的可用

先確認 Certbot 是否已自帶定時任務

在不同系統中，Certbot 可能已經自動安裝定時任務（例如 systemd timer 或 /etc/cron.d/certbot）。

可以先檢查：

`1`	`systemctl list-timers \| grep certbot`

如果已經有有效定時器，一般不需要再重複加 crontab。

手動新增 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 --dry-run`

看到模擬續期成功，再交給定時任務長期運行。

常見注意點

如果你使用的是 webroot 或 nginx 插件，很多情況不需要停 Nginx，可改為續期後重載：

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

certbot renew 只會在憑證接近過期時才進行實際續期，因此每天跑一次是正常且常見做法。
建議把日誌改到可長期追蹤的位置（例如 /var/log/letsencrypt/），更利於維運。

總結

憑證自動續期的關鍵不是「把命令寫上去」，而是「確認命令能完整跑通」。

你只要完成這三步，通常就能穩定運行：

確認是否已有系統自帶定時任務
按需新增 crontab 並保留日誌
用 --dry-run 做一次完整驗證

維運 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`