如何為 n8n 自架設環境配置 HTTPS？Caddy/Nginx 反向代理 SSL 教學

作者: /
n8n https

當你成功地自架設 (Self-Host) 了一套 n8n 實例，你就等於擁有了一把能夠串接公司所有敏感資料的萬能鑰匙。從客戶關係管理 (CRM) 的 API 金鑰、資料庫密碼，到金流服務的憑證，全都集中在這個強大的自動化中樞裡。

但你是否想過：如果這把萬能鑰匙的通訊過程沒有加密，會發生什麼事？這就如同在人來人往的大街上，高聲喊出你的銀行帳戶與密碼。任何在網路中間的人，都能輕易地竊聽到你傳輸的所有機敏資訊。

這就是為什麼為你的 n8n 實例配置 HTTPS (SSL 憑證)，從來都不是一個「選項」，而是一個「絕對的必要」。一個沒有 HTTPS 加密的 n8n 實例，在任何正式的生產環境中都是極度危險且不專業的。

這篇文章將是你的 n8n 安全設定終極指南。我們將帶你理解為何 HTTPS 如此重要，並手把手教你使用業界標準的「反向代理 (Reverse Proxy)」架構，透過 Caddy 或 Nginx 這兩種主流工具，為你的 n8n 實例配置免費的 Let’s Encrypt SSL 憑證，確保你的所有自動化流程與資料傳輸都受到最高等級的安全保護。

為什麼 n8n 絕對需要 HTTPS？不只是網址列上的綠色鎖頭

在你的 n8n 網址前加上那把小小的綠色鎖頭，帶來的好處遠超你的想像。它不僅是專業的象徵，更是保護你數位資產的核心防線。

保護敏感的憑證 (Credentials)

當你在 n8n 介面上新增或修改 API 金鑰、Bearer Token、帳號密碼等憑證時，這些資訊會在你的瀏覽器和 n8n 伺服器之間傳輸。如果沒有 HTTPS，這些 credential 就會以明文的形式在網路上傳輸，極易被中間人攻擊 (Man-in-the-middle attack) 竊取。

加密工作流中的數據

你的工作流中流動的資料——客戶個資、訂單詳情、財務報表——同樣會在瀏覽器和伺服器之間交換。HTTPS 會對這些資料進行端到端的加密，確保它們在傳輸過程中不會被窺探或篡改。

啟用安全的 Webhook

這是最實際的需求之一。越來越多的第三方服務（例如 Stripe, Shopify, Google）強制要求它們發送 Webhook 的目標 URL 必須是 https:// 開頭。如果你的 n8n Webhook 節點 URL 是 http://，這些服務會直接拒絕發送資料給你，讓你的事件驅動自動化從一開始就無法運作。

瀏覽器安全限制

現代瀏覽器（如 Chrome, Firefox）會對非 HTTPS 的網站顯示「不安全」的警告，甚至會限制某些功能的執行。這不僅會影響你和你團隊的使用者體驗，也傳遞出一個不專業的訊號。

最佳實踐架構：使用「反向代理 (Reverse Proxy)」

要啟用 HTTPS，最專業、最安全、也最靈活的方式，並不是直接在 n8n 本身進行複雜的 SSL 設定，而是透過一個名為「反向代理 (Reverse Proxy)」的架構。

什麼是反向代理？

你可以把反向代理想像成你公司的「總機或前台保全」。

  • n8n 服務： 就像公司內部的某個部門（例如 5678 號分機）。它專心處理自己的業務（自動化流程），但不直接對外接聽電話。
  • 反向代理 (例如 Nginx 或 Caddy)： 就像公司總機。所有外部打來的電話（來自網際網路的流量）都會先經過總機。總機負責過濾、接待、並處理一些通用事務（例如 SSL 加密解密），然後再將電話轉接到正確的內部分機。

在這個架構中，只有反向代理會暴露在公網上，n8n 服務本身則安全地待在內部網路中，大幅提升了安全性。

n8n https

方法一 (推薦新手)：使用 Caddy 自動化 HTTPS 設定

Caddy 是一個現代化的網頁伺服器，它最大的特色就是「預設自動化 HTTPS」。你幾乎不需要做任何複雜的 SSL 設定，只要給它一個網域名稱，它就會自動幫你向 Let’s Encrypt 申請、配置並續簽免費的 SSL 憑證。

前置作業

  1. 購買一個網域名稱 (Domain Name): 例如 yourdomain.com。
  2. 設定 DNS: 到你的網域註冊商後台，新增一筆 A 記錄，將你想要給 n8n 使用的子網域（例如 n8n.yourdomain.com）指向你伺服器的公開 IP 位址。

docker-compose.yml 完整設定範例

這是一個包含 n8n 和 Caddy 兩個服務的完整 docker-compose.yml 範本。你可以直接使用。

YAML

version: '3.7'

services:
  n8n:
    image: n8nio/n8n
    restart: always
    environment:
      - GENERIC_TIMEZONE=Asia/Taipei
    ports:
      - "127.0.0.1:5678:5678"
    volumes:
      - n8n_data:/home/node/.n8n

  caddy:
    image: caddy:2
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config

volumes:
  n8n_data:
  caddy_data:
  caddy_config:

注意： n8n 的 ports 設定為 127.0.0.1:5678:5678，這讓 n8n 只對本機開放，確保所有外部流量都必須經過 Caddy。

Caddyfile 設定檔解析

在 docker-compose.yml 檔案的同一個目錄下，建立一個名為 Caddyfile 的純文字檔案，內容只有短短兩行：

n8n.yourdomain.com {
    reverse_proxy n8n:5678
}
  • n8n.yourdomain.com: 請換成你自己的網域名稱。
  • reverse_proxy n8n:5678: 告訴 Caddy，將所有送到這個網域的流量，全部轉發給一個叫做 n8n 的服務的 5678 埠口。（n8n 這個名稱對應了 docker-compose.yml 中的服務名稱）。

啟動與驗證

在伺服器上，將這兩個檔案放好後，執行 docker-compose up -d。等待幾分鐘後，Caddy 就會自動完成所有 SSL 憑證的申請與設定。現在，打開你的瀏覽器，直接訪問 https://n8n.yourdomain.com，你就應該能看到安全、加密的 n8n 登入介面了！

方法二 (傳統主流)：使用 Nginx + Certbot 進行設定

Nginx 是業界最穩定、功能最強大的網頁伺服器和反向代理。搭配 Certbot 工具，同樣可以實現免費的 Let’s Encrypt 憑證自動化。這個組合功能更強大，但設定也相對複雜一些。

nginx.conf 設定檔解析

你需要一個 Nginx 的設定檔，內容大致如下：

Nginx

server {
    listen 80;
    server_name n8n.yourdomain.com;

    # 用於 Let's Encrypt 驗證
    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    # 將所有 HTTP 請求重定向到 HTTPS
    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    server_name n8n.yourdomain.com;

    # SSL 憑證路徑
    ssl_certificate /etc/letsencrypt/live/n8n.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://n8n:5678;
        # ... (其他 proxy header 設定)
    }
}

使用 Certbot 取得憑證

你需要另外執行 Certbot 的 Docker 容器來申請憑證，並將憑證目錄掛載 (mount) 到 Nginx 容器中。這個過程涉及的指令較多，建議參考 n8n 官方文件或相關的 Nginx + Certbot Docker 教學來完成。

常見問題與除錯 (Troubleshooting FAQ)

  • Q1: 為什麼我的 HTTPS 沒有生效，瀏覽器無法訪問？
    • A: 最常見的原因是 DNS A 記錄尚未生效，或設定錯誤。請確保你的網域已正確指向伺服器 IP。其次，檢查你伺服器的防火牆是否開放了 80 和 443 這兩個埠口。
  • Q2: Caddy 或 Certbot 憑證申請失敗，顯示 Domain Challenge 錯誤。
    • A: 這幾乎 100% 是因為 Let’s Encrypt 的伺服器無法從公網透過 HTTP (80 埠口) 訪問到你的 Caddy/Nginx 服務來進行驗證。請再次確認 DNS 和防火牆設定。
  • Q3: 我看到「502 Bad Gateway」錯誤。
    • A: 這是一個好消息，代表你的反向代理（Caddy/Nginx）已經正常運作了！這個錯誤的意思是，反向代理無法連接到後端的 n8n 服務。請檢查你的 docker-compose.yml，確保 n8n 和反向代理服務在同一個 Docker network 中，並且 reverse_proxy 後面的服務名稱 (n8n:5678) 是正確的。
n8n https

結語

為你的自架設 n8n 實例配置 HTTPS，是從「能用」到「專業可用」的關鍵一步。它不僅僅是為了安全，更是為了穩定性、相容性與專業形象。

今天我們學到了業界最標準的「反向代理」架構，並介紹了兩種主流的實現方式：

  • Caddy: 極度推薦給絕大多數使用者，它的自動化 HTTPS 功能讓你幾乎可以忘記 SSL 憑證的存在。
  • Nginx: 功能強大、穩定可靠的傳統選擇，適合需要高度客製化設定的進階場景。

你的自動化流程是你寶貴的數位資產，處理的更是公司或個人的敏感數據。請像對待你的銀行帳戶一樣，謹慎地保護它的安全。今天就動手，為你的 n8n 實例加上那把不可或缺的安全鎖吧！

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

返回頂端