Dairny Lab NAS、自架與數位工作流
遠端存取 2026.05.02 8 分鐘閱讀

讓陌生人看不到你的自架服務——不需要改一行程式碼。

Cloudflare Zero Trust Access 可以在你的自架服務前加一道 SSO 登入牆，用 Google、GitHub 帳號驗證身份，不需要改動服務本身。搭配 Cloudflare Tunnel 使用，是保護 NAS 服務最簡單的方式。

Cloudflare Zero Trust Access：自架服務加上 Google 登入牆，完全免費

你用 Cloudflare Tunnel 把 NAS 的服務對外開放之後，任何人只要知道網址就能看到登入頁。對於 Vaultwarden、Immich、n8n 這類服務，這樣的曝露程度你可能不太放心。

Cloudflare Zero Trust Access 解決的就是這個問題：在你的服務前面加一道驗證牆，訪客必須先用 Google、GitHub 或 Email OTP 通過驗證，才能看到服務的登入頁。整個過程你不需要改動服務本身的任何設定。

免費方案支援最多 50 個使用者，對個人和小團隊完全夠用。

Cloudflare Zero Trust Access 驗證流程

運作原理

使用者瀏覽器 → Cloudflare Access 驗證頁 → 通過 → 服務（NAS / VPS）
                        ↓
                    驗證失敗 → 403 拒絕

Cloudflare Access 在流量到達你的服務之前攔截，要求訪客向 Cloudflare 的 Identity Provider（IdP）驗證。驗證成功後，Cloudflare 發給瀏覽器一個 JWT Token，後續請求都帶著這個 Token 通過。

和自己在服務裡設定密碼有什麼不同？

項目 服務內建驗證 Cloudflare Access
設定位置 每個服務各自設定 集中在 Cloudflare 管理
驗證方式 帳號密碼 Google / GitHub / Email OTP
多服務統一管理 各自獨立 同一套規則套用多個服務
暴力破解防護 取決於服務 Cloudflare 層面阻擋
成本 免費 免費（50 人以下）

前置需求

  • 域名已由 Cloudflare 管理（NS 指向 Cloudflare）
  • 已設定 Cloudflare Tunnel，服務可透過子網域存取

還沒設定 Tunnel？先看 Cloudflare Tunnel 完整教學

設定流程

Step 1：進入 Zero Trust 控制台

  1. 登入 Cloudflare Dashboard
  2. 左側選單 → Zero Trust
  3. 第一次進入需要建立 Team name（例如 yourname），之後無法更改，隨意填即可
  4. 選擇 Free 方案

Step 2：設定 Identity Provider（IdP）

讓使用者可以用 Google 帳號登入：

  1. 進入 Settings → Authentication → Login methods
  2. 點擊 Add new → 選擇 Google
  3. 需要到 Google Cloud Console 建立 OAuth 2.0 用戶端憑證： - 建立新專案（或選既有專案） - 進入 API 和服務 → 憑證 → 建立憑證 → OAuth 用戶端 ID - 應用程式類型選 網頁應用程式 - 授權重新導向 URI 填入 Cloudflare 提供的 Callback URL（格式：https://yourteam.cloudflareaccess.com/cdn-cgi/access/callback） - 複製 Client ID 和 Client Secret
  4. 回到 Cloudflare，填入 Client ID 和 Client Secret，儲存

也可以用 Email OTP（最快，不需 OAuth 設定）： - 選擇 One-time PIN → 無需額外設定，使用者輸入 Email 收驗證碼即可

Step 3：建立 Access Application

這裡定義哪個服務要受保護：

  1. 進入 Access → Applications → Add an application
  2. 選擇 Self-hosted
  3. 填入設定： - Application name：服務名稱（例如 Immich） - Session Duration：登入有效時間（建議 24h 或 7 days） - Application domain：填入服務的子網域（例如 immich.yourdomain.com）
  4. 點擊 Next

Step 4：建立 Access Policy

定義誰可以通過驗證：

  1. Policy name：隨意（例如 Allow Owner）
  2. Action：選 Allow
  3. Include 規則： - 選 Emails → 填入你自己的 Email（只允許這個 Email 通過） - 或選 Everyone（讓所有驗證過的使用者都能進）
  4. 儲存

建議：用 Email 精確指定，避免任何有 Google 帳號的人都能存取。

Step 5：測試

用無痕瀏覽器開啟你的服務網址（例如 https://immich.yourdomain.com），應該會看到 Cloudflare 的登入頁面，輸入允許的 Email，收驗證碼或用 Google 登入後才能進入服務。

套用到多個服務

每個要保護的服務都建立一個 Application。常見的設定模式：

服務 建議 Session Duration 建議 Policy
Vaultwarden 1h（密碼管理器應嚴格） 指定 Email
Immich 7 days 指定 Email / 家人 Email
n8n 24h 指定 Email
Grafana 24h 指定 Email

進階：Bypass 特定路徑

有些服務有 API endpoint 需要直接存取（不通過瀏覽器驗證），例如 Immich 的手機 App API、n8n 的 Webhook。這種情況可以在 Policy 裡加一條 Bypass 規則：

  1. 在同一個 Application 的 Policy 區塊，新增第二條 Policy
  2. Action：選 Bypass
  3. Path：填入需要繞過的路徑（例如 /api/*）
  4. 確保 Bypass Policy 排在 Allow Policy 之前

這樣 /api/* 的請求直接放行，瀏覽器存取其他路徑才要驗證。

服務工作原理補充

Cloudflare Access 驗證是在 Cloudflare 的邊緣節點完成，你的服務完全不知道 Access 的存在。Access 通過後，Cloudflare 在 HTTP Header 裡加入 Cf-Access-Jwt-Assertion，如果你的服務支援讀取這個 Header 做二次驗證，可以進一步確認請求確實來自 Cloudflare Access。

一般用途不需要這一步，Cloudflare 的邊緣驗證已經足夠。

常見問題

Q：免費方案 50 個使用者是指什麼？ 是指 Cloudflare Access 裡的 Active User 數量，不是你的服務帳號。個人或家庭使用完全夠用。

Q：Access 和 Tunnel 一定要一起用嗎？ 不一定，但搭配使用是最常見的架構。Tunnel 負責把服務安全對外，Access 負責控制誰能存取。

Q：手機 App 會不會被 Access 擋掉？ 會。需要用 Bypass 規則放行 App 使用的 API 路徑，或讓手機 App 通過 Cloudflare WARP 客戶端驗證。

Q：設定完後服務還需要自己的登入嗎？ 建議保留。Access 是第一道門，服務本身的帳號密碼是第二道，兩層保護更安全。

小結

Cloudflare Zero Trust Access 是保護自架服務最省力的方式之一：不需要改服務設定、不需要自己管 VPN、免費支援 50 人，而且整個設定在 15 分鐘內就能完成。

如果你已經用 Cloudflare Tunnel 把服務對外開放，加上 Access 幾乎是必要的下一步。

🔗 延伸閱讀

這篇有幫助嗎？ 讓陌生人看不到你的自架服務——不需要改一行程式碼。
—