月份: 2026 年 3 月

使用 Mini PC 當 Proxmox 主機前，你一定要做的 BIOS / Kernel 設定

很多人為了省電、省空間，會選擇 Mini PC（像 Ryzen 7840HS、7940HS、Intel N100 之類）來跑：

  • Proxmox VE
  • ESXi
  • KVM
  • HomeLab
  • NAS + VM
  • 備份節點

👉 但如果你「沒有調整 BIOS 與 Kernel 參數」，
你可能會遇到：

  • ❌ 半夜自動重開機
  • ❌ 備份跑到一半整台 freeze
  • ❌ 完全沒有 kernel panic 記錄
  • ❌ journal log 直接中斷
  • ❌ 看起來像被拔電

而 log 裡 什麼都沒有。

這不是錯覺。

這是 Mini PC 常見的 PCIe / C-state / Power Management 硬體層級 freeze 問題。

為什麼會發生？

Mini PC 本質是「筆電級主機板」設計。

特點是：

  • Aggressive 省電策略
  • PCIe ASPM 深度省電
  • 深層 CPU C-State
  • IOMMU + PCIe 共享匯流排
  • 小型電源模組

當系統進入：

  • ✅ 高 I/O（vzdump 備份）
  • ✅ 高網路流量
  • ✅ NVMe 滿載
  • ✅ 多 VM 同時運作

就可能觸發：

PCIe Bus Hang
CPU 深層睡眠喚醒失敗
Root Complex Freeze

而這種 freeze：

  • 不會留下 kernel panic
  • 不會有 OOM
  • 不會有 MCE
  • watchdog 也來不及救

系統直接「硬死機」。

✅ Mini PC 當虛擬化主機的必要設定

請按照順序做。

🥇 Step 1：關閉 PCIe ASPM（最重要）

編輯：

/etc/default/grub

找到：

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

改成：

GRUB_CMDLINE_LINUX_DEFAULT="quiet pcie_aspm=off"

然後執行：

update-grub
reboot

為什麼？

ASPM 是 PCIe 省電機制。

在桌機主機板通常沒問題。

但在 Mini PC 上：

  • 高流量 + 省電切換
  • 可能導致 PCIe Link 無法正確喚醒
  • 整條 bus freeze

這是最常見原因。

🥈 Step 2：限制 CPU C-State

如果 BIOS 有以下選項：

  • ✅ Disable Global C-State Control
  • ✅ Disable CPPC
  • ✅ Disable ASPM

請全部關閉。

如果 BIOS 沒有提供，

可以改用 kernel 參數：

processor.max_cstate=1 idle=nomwait

變成：

GRUB_CMDLINE_LINUX_DEFAULT="quiet pcie_aspm=off processor.max_cstate=1 idle=nomwait"

然後：

update-grub
reboot

為什麼？

Mini PC 為了省電會讓 CPU 進入：

  • C6
  • C10

但在高 I/O 中斷情況下：

👉 CPU 可能喚醒失敗
👉 整台 freeze

🥉 Step 3：測試性關閉 IOMMU（排除法）

如果還是會發生，

可以暫時加入：

amd_iommu=off

完整變成：

GRUB_CMDLINE_LINUX_DEFAULT="quiet pcie_aspm=off processor.max_cstate=1 idle=nomwait amd_iommu=off"

⚠️ 注意：

如果你有做 PCI Passthrough，不能關。

🔎 為什麼這些設定對 Mini PC 特別重要？

因為 Mini PC：

  • 使用筆電等級主板
  • PCIe 通道少
  • 多裝置共享 Root Port
  • 電源模組小
  • BIOS 通常未針對長時間高負載優化

當你把它當成：

24 小時虛擬化主機

你必須把它從「省電模式」改成「穩定模式」。

🔥 常見錯誤判斷

很多人會以為是：

  • ❌ igc 網卡 driver
  • ❌ NVMe 壞掉
  • ❌ RAM 問題
  • ❌ Proxmox bug

但如果 log 是「乾淨消失」，

那 90% 是 Power Management 問題。

✅ 建議 Mini PC 虛擬化標準設定

建議至少包含：

pcie_aspm=off
processor.max_cstate=1
idle=nomwait

✅ 結論

Mini PC 當 HomeLab / Proxmox 主機完全可行。

但前提是：

❗ 你要先把「筆電省電策略」關掉。

否則你會在：

  • 半夜備份
  • RAID rebuild
  • 大量 VM I/O

時遇到神秘重開機。

而 log 裡什麼都沒有。

如果你正在用 Mini PC 跑虛擬化，
建議今天就檢查你的設定。

穩定，比省 3W 電重要得多。

使用 iptables hashlimit 限制 HTTP 流量與安全回滾方法

在高流量或遭受爬蟲攻擊時，Web Server（如 Apache / Nginx）可能會因為大量連線而消耗過多 PHP-FPM 或系統資源。
Linux iptables 的 hashlimit 模組可以有效限制「每個 IP 的連線速率」，是一種輕量且高效的防護方式。

本文說明：

  • hashlimit 的用途
  • 基本設定方法
  • 測試方式
  • 如何安全取消規則（回滾）

一、什麼是 hashlimit？

hashlimit 是 iptables 的一個 match module。

它的特色是：

✅ 針對「每個來源 IP」獨立計算流量
✅ 不會把所有訪客視為同一個來源
✅ 適合防止單一 IP 短時間內大量請求

與 -m limit 不同，limit 是全局限制，容易誤傷正常使用者。

二、基本 HTTP 限制範例

以下規則限制：

  • 每個 IP 每秒最多 30 個請求
  • 瞬間最多 80 個 burst
  • 超過後丟棄（DROP）

bash

iptables -A INPUT -p tcp --dport 80 \
-m hashlimit \
--hashlimit 30/sec \
--hashlimit-burst 80 \
--hashlimit-mode srcip \
--hashlimit-name http_limit \
-j ACCEPT

iptables -A INPUT -p tcp --dport 80 -j DROP

參數說明

參數說明
–hashlimit 30/sec每秒最多 30 個封包
–hashlimit-burst 80瞬間可達 80 個
–hashlimit-mode srcip以來源 IP 為單位計算
–hashlimit-name此限制規則的名稱

三、如何確認規則是否生效？

使用：

bash

iptables -L INPUT -n -v

可以看到每條規則的封包計數。

如需查看行號（刪除時會用到）：

bash

iptables -L INPUT -n --line-numbers

四、如何安全取消規則？

✅ 方法一（推薦）：使用行號刪除

先查看規則：

bash

iptables -L INPUT -n --line-numbers

假設顯示：

basic

num  target
1    ACCEPT  tcp dpt:80 hashlimit ...
2    DROP    tcp dpt:80

刪除方式：

bash

iptables -D INPUT 1
iptables -D INPUT 1

⚠ 注意：刪除第一條後，下面規則會往上移動。

✅ 方法二：使用完整規則刪除

bash

iptables -D INPUT -p tcp --dport 80 \
-m hashlimit \
--hashlimit 30/sec \
--hashlimit-burst 80 \
--hashlimit-mode srcip \
--hashlimit-name http_limit \
-j ACCEPT

iptables -D INPUT -p tcp --dport 80 -j DROP

⚠ 必須與建立規則時完全一致。

五、如果使用 iptables-persistent

若系統有安裝：

iptables-persistent

或使用：

netfilter-persistent

刪除規則後，請記得重新儲存：

bash

iptables-save > /etc/iptables/rules.v4

否則重開機後規則會恢復。

六、安全測試建議（避免誤封）

⚠ 在 Production 環境請勿直接啟用 DROP 規則。

建議測試流程：

1️⃣ 先只加入 hashlimit ACCEPT 規則
2️⃣ 觀察流量與錯誤日誌
3️⃣ 確認正常後再加入 DROP

或先於測試機驗證。

七、適用場景

  • WordPress 遭受爬蟲過度抓取
  • WooCommerce 頁面被大量請求
  • 想降低 PHP-FPM 壓力
  • 防止單一 IP 造成資源耗盡

八、注意事項

  • 若使用 Cloudflare，來源 IP 可能會變成 CDN IP
  • iptables 屬於 L3/L4 防火牆，無法判斷 URL
  • 規則順序非常重要

結語

hashlimit 是一種：

  • 高效
  • 核心層級
  • 不依賴應用程式

的流量控制方式。

但部署前務必測試，並確保有回滾方案，以避免影響正常使用者。

Linux 防火牆完整備份與還原教學（iptables + ipset）

在使用 Fail2Ban + ipset + iptables 的伺服器環境中，
很多人只備份了 iptables，卻忽略了 ipset。

結果在災難還原時發現：

  • ✅ 規則還在
  • ❌ 被封鎖的 IP 全部消失

這篇教學會完整說明：

  1. 為什麼要同時備份 iptables 與 ipset
  2. 正確備份方式
  3. 正確還原順序
  4. 建議自動化備份腳本

🔎 一、iptables 與 ipset 差在哪？

在 Fail2Ban 環境中實際架構是：

Fail2Ban
   ↓
ipset（存放被封鎖 IP 清單）
   ↓
iptables（引用 ipset）
   ↓
Linux Kernel 防火牆

✅ iptables 負責「規則」

例如：

-m set --match-set f2b-http-404-scan src -j DROP

意思是：

如果來源 IP 在這個 set 裡 → 就 DROP

✅ ipset 負責「IP 名單」

例如：

add f2b-http-404-scan 65.20.67.134

真正被封鎖的 IP 存在 ipset 裡。

🚨 二、常見錯誤

很多人只做：

iptables-save > /root/iptables.backup

但這只會備份規則，不會備份 ipset 內的 IP。

結果：

  • 重開機後
  • 或手動 restore 後

IP 清單消失。

✅ 三、正確完整備份方式

必須備份兩個部分。

✅ 1️⃣ 備份 iptables

bash

iptables-save > /root/iptables.backup

✅ 2️⃣ 備份 ipset

bash

ipset save > /root/ipset.backup

這個檔案會包含：

sql_more

create f2b-http-404-scan hash:ip
add f2b-http-404-scan 65.20.67.134
add f2b-http-404-scan 1.2.3.4

這才是真正的封鎖名單。

✅ 四、正確還原方式（非常重要）

⚠️ 還原順序不能錯。

✅ Step 1：先還原 ipset

bash

ipset restore < /root/ipset.backup

✅ Step 2：再還原 iptables

bash

iptables-restore < /root/iptables.backup

❗ 為什麼順序不能反？

因為：

iptables 規則會引用 ipset。

如果 ipset 不存在，會出現錯誤：

iptables: Set f2b-http-404-scan doesn't exist

✅ 五、建議每日自動備份

可以建立一個腳本：

nano /root/backup-firewall.sh

內容如下：

bash

#!/bin/bash

DATE=$(date +%F)

iptables-save > /root/fw-$DATE.iptables
ipset save > /root/fw-$DATE.ipset

給執行權限：

bash

chmod +x /root/backup-firewall.sh

加入 crontab：

bash

crontab -e

每天凌晨 3 點備份：

basic

0 3 * * * /root/backup-firewall.sh

✅ 六、如果發生誤封全站怎麼辦？

假設錯誤規則導致：

0.0.0.0/0 tcp dpt:80 DROP

網站全部無法連線。

只要執行：

bash

ipset restore < /root/ipset.backup
iptables-restore < /root/iptables.backup

30 秒內救回網站。

✅ 七、關於 Fail2Ban 的補充

如果你使用：

banaction = iptables-ipset-proto6-allports

Fail2Ban 重啟後會自動重建 ipset。

因此：

✅ 一般重開機不會遺失封鎖
✅ 但手動清空 firewall 會遺失

所以備份仍然是好習慣。

✅ 八、總結

項目是否需要備份
iptables✅ 必須
ipset✅ 必須
只備份 iptables❌ 不完整

🎯 最重要一句話

iptables 只是規則
ipset 才是黑名單

兩個都要備份，才算完整防火牆備份。

為什麼 AI 會「幻覺」？

一次長時間技術討論後，我發現真正的原因

很多人說，AI 用久了會開始「幻覺」。

對話越長，內容越偏離主題；
越討論，越覺得答非所問；
甚至會出現很自我、很確定但其實不準確的回答。

我過去也有這種感覺。

但最近一次長時間的技術討論，讓我發現——
問題可能不完全在 AI。

過去的討論方式：假設 AI 知道我在想什麼

以前，我和 AI 討論時，多半採用問答式對話：

  • 我問一個問題
  • 它回答
  • 我再延伸問

但我很少告訴它：

  • 我最後採用了哪個方案
  • 哪些建議我沒有使用
  • 我的架構實際上怎麼調整
  • 哪些假設其實不成立

我常常假設：

「它應該知道我想怎樣。」

結果對話一長，內容就開始偏移。

問題的核心：資訊沒有對齊

AI 並不是在「理解我腦中的設計圖」。

它只能根據我寫出來的文字做推理。

當我沒有說明：

  • 我已經改成 DROP
  • 兩台服務器不是同一台
  • 某個方案已經放棄

AI 就會自動補齊空白。

而只要補錯一次，
那個錯誤就會變成後續推理的基礎。

這不是胡說八道，
而是推理模型在「填補缺失因果」。

這一次，我改變了做法

這次的討論，我刻意改變了幾件事：

1️⃣ 在回覆前，先說明現況

我會清楚說：

  • 我現在採用了什麼方案
  • 哪個方向已經排除
  • 哪些前提不成立

2️⃣ 即時糾正誤解

如果 AI 出現錯誤假設，我會直接說：

不是同一台 server，不要誤會。

而不是默默覺得「又開始亂講」。

3️⃣ 不再假設 AI 會讀心

我不再期待它知道我「想要優化什麼」，
而是明確說出目標範圍。

結果：幻覺感幾乎消失

這次長時間討論下來，我發現：

  • 內容沒有越聊越歪
  • 建議是收斂的
  • 推理邏輯清晰
  • 沒有明顯自說自話的情況

這讓我開始思考：

AI 真的在幻覺？
還是我們讓它在沒有邊界的情況下自由推測？

真正的關鍵：誤差累積

長對話會變廢，通常不是因為時間。

而是因為：

  1. 某個錯誤假設沒有被糾正
  2. 那個假設變成新的基礎
  3. 後續推論全部建立在錯誤前提上

這叫做：

誤差累積。

只要不及時修正，
偏差就會越來越大。

AI 其實是「機率收斂系統」

從本質上來說，AI 是一種機率預測模型。

當資訊清楚時 → 它會收斂。
當資訊模糊時 → 它會發散。

如果使用者給出明確邊界：

  • 明確狀態
  • 明確目標
  • 明確排除項
  • 明確前提

那輸出就會穩定。

如果使用者讓背景模糊、假設共享、目標漂移，
那結果自然會混亂。

我的結論

這次經驗讓我理解一件事：

AI 並不是會「越聊越亂」。

真正會讓對話變亂的，是：

未被說出口的假設。

當我改變了對齊方式，
幻覺感幾乎消失。

AI 沒變。
我改變了使用方式。

給長時間使用 AI 的人的一個建議

如果你覺得 AI 越聊越歪，可以試試這幾點：

  • 不要假設它知道你的架構
  • 每次重大調整後回報現況
  • 即時糾正錯誤假設
  • 明確說出你「不想要什麼」

你可能會發現——
問題不是時間太長，
而是資訊沒有對齊。

Linux 指令教學：如何使用 ss -K 強制中斷指定 IP 的 TCP 連線

在 Linux 伺服器管理中，有時需要立即中斷某個 IP 的現有連線，例如：

  • fail2ban 已經 Ban IP
  • iptables 規則已生效
  • 但既存 TCP 連線仍在持續

這時不必重啟服務，可以使用：

ss -K

來精準關閉指定連線。

什麼是 ss？

ss（Socket Statistics）是用來查看 socket 連線狀態的工具，
功能比舊版 netstat 更完整、更快速。

ss -K 是什麼？

-K  = Kill

意思是：

強制關閉符合條件的 TCP 連線

它會透過 kernel 直接發送 TCP RST，立即中斷連線。

基本用法

中斷某個來源 IP 的所有連線

ss -K src 20.91.210.252

意思是：

關閉所有「來源為 20.91.210.252」的 TCP 連線

⚠ 在伺服器上，攻擊者是來源（source），
所以必須使用 src。

查看是否有連線存在

執行前可先確認：

ss -ant | grep 20.91.210.252

如果看到：

ESTAB

代表仍有已建立連線，可以使用 ss -K 中斷。

常見錯誤

❌ 錯誤寫法：

ss -K dst 20.91.210.252

在伺服器端通常應該使用 src，
否則可能找不到對應連線。

與重啟服務的差別

方法影響範圍
restart Apache所有使用者
ss -K src IP只有指定 IP

使用 ss -K 可以精準操作，而不影響正常流量。

權限需求

必須使用 root 執行：

Operation not permitted

代表權限不足。

小結

ss -K 是一個非常實用的進階網路管理指令：

  • 可立即中斷指定 IP 連線
  • 不必重啟服務
  • 不影響其他使用者
  • 適用於安全事件處理

在需要精準控制 TCP 連線時，是比重啟服務更優雅的做法。