# 打造 TLS 、系統健康監控神器 ：Uptime Kuma + 底層 Shell 探針（雙層監控）

隨著資安標準越來越高，外部 API 紛紛強制升級 TLS 1.2 甚至 1.3，你是否也有這種焦慮：
* Q1：「那個跑了十年的舊系統，到底連不連得上新服務？」
* Q2：「是 Cloudflare 擋掉的？還是防火牆？還是我的 OS 太舊？」

為了找出這些**隱形的連線地雷**，我把一台僅支援 TLS 1.2 的 Windows Server 2012，改造成專門測試**最低安全相容性**的監控節點。

## 為什麼需要這WIN 20212？

如果用最新的 Windows 11 或 Linux 測試，因為支援度太好，往往會讓你產生「一切正常」的錯覺。

唯有使用 **Windows Server 2012（Schannel）** 這種對加密協定支援度有限的舊系統，才能模擬出真實世界中那些**老舊 Client 端**的連線困境。

情境：服務端仍是 TLS 1.2，但把 cipher suites 刪到只剩少數「看起來最安全」的那幾條。

結果：

* 新系統支援的 cipher 很多，總能挑到一條交集 → 🟢
* Win2012 支援集合比較小，交集一旦變成空集合 → 🔴

> 一句話版（超通俗）：

「兩邊都說要用 TLS 1.2，但其實是在『談用哪一種加密算法』。新系統選擇很多，Win2012 選擇少，*即便TLS連線成功，但加密算法沒交集，連線仍然會直接失敗*。」

## 獨家密技：「雙層」監控大法

一般的 Uptime Kuma 只能告訴你「網站活著」，但它適用的是 Node.js 的連線標準（OpenSSL），這跟 Windows 作業系統底層的行為（Schannel）是不一樣的！

為了抓出差異，我設計了**雙層驗證**機制：

### 監控準備項目

| 項目 | 設定 | 角色功能 |
| :--- | :--- | :--- |
| **OS** | Windows Server 2012 | **(主角)** 模擬老舊環境，僅開 TLS 1.2 |
| **監控核心** | Uptime Kuma (Node.js) | 現代化的 Dashboard，負責漂亮地顯示數據 |
| **資料庫** | SQLite (`kuma.db`) | 存放所有的監控網址 |
| **自動化手腳** | PowerShell 排程 | **(關鍵)** 每 5 分鐘繞過 Kuma，直接用 OS 底層測試連線 |

:::info
**💡 為什麼要分兩層？**
* **第一層 (Kuma/Node.js)：** 代表「現代瀏覽器/新系統」看得到的結果。
* **第二層 (OS/PowerShell)：** 代表「老舊系統/Legacy Code」看得到的結果。

**如果第一層通，第二層不通 👉 恭喜，你抓到 Cipher Suite 不相容的問題了！**
:::

flowchart LR
  Target["被監控服務<br/>API / Website<br/>(可能經過 Gateway / Cloudflare)"]

  subgraph Win2012["Windows Server 2012 監控節點"]
    DB["kuma.db<br/>(SQLite)"]

    Kuma["Uptime Kuma<br/>(Node.js)<br/>TLS: OpenSSL"]
    PS["PowerShell 探針<br/>(Invoke-WebRequest)<br/>TLS: Schannel (OS Native)"]

    Kuma --- DB
    PS -- 讀取監控清單 --> DB
    PS -- Push API 回報 up/down --> Kuma
  end

  Kuma -- L7 HTTP(S) 探測 --> Target
  PS -- L7 HTTP(S) 探測 --> Target

  Dash["Dashboard / Alert<br/>雙層燈號對照"]
  Kuma --> Dash

  Note["判讀：<br/>Kuma🟢 + PS🔴 → TLS/Cipher/憑證鏈相容性地雷<br/>Kuma🔴 + PS🔴 → 服務或網路真的掛了"]
  Dash -.參考.-> Note

▲ 圖 架構圖

---

## 運作流程圖解

### Step 1. 建立儀表板
在 Uptime Kuma 裡面設定好你要監控的 API 或網站（HTTP / TCP / Ping）。
▲ 圖 在 Uptime Kuma 裡面設定
### Step 2. 讓 PowerShell 去「抄作業」
我不想要兩邊維護清單。所以，我寫了一個 PowerShell 腳本，直接潛入 Kuma 的資料庫 (`kuma.db`)，把網址撈出來(下面有Code)，用 **OS 原生的網路環境能力** 再測一次！

### Step 3. 異常時「打小報告」
如果 OS 層連線失敗（例如 Cipher 喬不攏），腳本會呼叫 Kuma 的 **Push API**，在儀表板上亮起紅燈。

▲ 圖-透過 Push 機制，讓 OS 發現「我不支援這個加密演算法」時，主動告訴 Kuma。

---

## 實戰腳本：自動同步與測試

這段腳本的精髓在於：**不用手動維護兩份清單**。它會自己去讀 SQLite，發現新加的監控項目就自動納入測試。

# 引入 SQLite 函式庫
Add-Type -Path "C:/libs/System.Data.SQLite.dll"

# 連接 Kuma 的資料庫 (直接讀取設定)
$conn = New-Object System.Data.SQLite.SQLiteConnection("Data Source=C:/UptimeKuma/data/kuma.db;Version=3;")
$conn.Open()

# 撈出所有啟用中的監控項目
$cmd = $conn.CreateCommand()
$cmd.CommandText = "SELECT name, url, type, method, pushToken FROM monitor WHERE active=1"
$reader = $cmd.ExecuteReader()

while ($reader.Read()) {
    $url = $reader["url"]
    $token = $reader["pushToken"]

    try {
        # 關鍵動作：用 OS 原生指令 (Invoke-WebRequest) 測試連線
        # 如果 OS 的 TLS/Cipher 不支援，這裡就會報錯！
        Invoke-WebRequest -Uri $url -TimeoutSec 5 -UseBasicParsing
        
        # 成功：告訴 Kuma 這一層沒問題
        curl "[https://uptime.xxx.com/api/push/$token?status=up](https://uptime.xxx.com/api/push/$token?status=up)"
    }
    catch {
        # 失敗：OS 連不上 (可能是 TLS 版本太舊或 Cipher 不對)
        curl "[https://uptime.xxx.com/api/push/$token?status=down](https://uptime.xxx.com/api/push/$token?status=down)"
    }
}

$conn.Close()

### 第二部分（從 監控結果 到 結尾）

## 📊 監控結果：如何解讀燈號？

這個架構最有趣的地方，在於比較 **Uptime Kuma 原生燈號** 與 **Push API 燈號** 的差異：

| 狀況 | Kuma (Node.js) | OS (PowerShell) | 診斷結果 |
| :--- | :---: | :---: | :--- |
| **一切正常** | 🟢 | 🟢 | 服務健康，且兼容性良好。 |
| **Cipher 地雷** | 🟢 | 🔴 | **這是重點！** 服務活著，但你的老系統看不見它（Cipher/TLS 不支援）。 |
| **服務掛點** | 🔴 | 🔴 | 對方伺服器真的掛了，或是強制 TLS 1.3 導致全滅。 |

▲ 圖 看到這種紅燈，就知道不是網路斷了，而是**加密協定談判失敗**。

## 💡 結語：舊時代的守門員

透過這個機制，我能做到：
1. **預知災難**：在 Gateway 或 Cloudflare 修改加密政策前，先知道哪些舊系統會斷線。
2. **釐清責任**：是網路問題，還是加密協定問題？一看燈號便知。
3. **自動化**：不用手動跑 curl，全自動巡邏。

> **技術觀察不只在於功能 (Function)，更在於邊界 (Boundary)。**
> 一句話：用「Kuma 看服務健康」+「Win2012 看最低相容性」，把 TLS/Cipher 升級造成的隱形斷線 變成儀表板上可見、可告警的監控訊號。