2026 年 Cloudflare Tunnel 免公網 IP 穿透：安全發布本地服務
- TZ=Asia/Taipei
安裝好工具之後，接下來要建立 Tunnel 並把網域接上去。2026 年的 Cloudflare Dashboard 已經把整個流程做得很直覺，新手建議先走 Dashboard 路線；熟悉之後再改用 CLI 或設定檔模式，會更有掌控感。
4-1 路線 A：Dashboard 圖形化建立（推薦新手）
進入 Zero Trust → Networks → Tunnels，點選「Create a tunnel」。介面會問你幾個問題：
選擇連線器類型：選 cloudflared。
home-nas 或 office-web。這個名字只是給你辨識用，不影響功能。--token，它包含了 Tunnel 的 ID 與授權資訊。請把 token 當成密碼看待，不要貼到公開場合。連線成功後，切到「Public Hostname」頁籤，新增一筆路由。你需要填：
Subdomain：例如 nas。
Domain：選擇你的網域。
Path：通常留空。
localhost:5000 或 192.168.1.10:8080。儲存之後，Cloudflare 會自動幫你建立對應的 CNAME 記錄。這個自動化流程是 Dashboard 路線最大的價值——不用手動去 DNS 頁面設定，也不用記那些 UUID。
4-2 路線 B：CLI 本機建立與 token 管理
如果你偏好完全用命令列掌控，流程如下：
# 1. 登入並授權（會開啟瀏覽器，選擇你的網域）
cloudflared tunnel login
2. 建立 Tunnel（名稱自取）
cloudflared tunnel create home-lab
3. 列出 Tunnel，記下 ID 與憑證路徑
cloudflared tunnel list
4. 建立 DNS 路由
cloudflared tunnel route dns home-lab nas.example.com
5. 執行 Tunnel
cloudflared tunnel run home-lab
cloudflared tunnel login 會在 ~/.cloudflared/ 下產生憑證檔（cert.pem），而 tunnel create 會產生該 Tunnel 專屬的 JSON 憑證檔。這兩個檔案都是敏感資訊，權限建議設為 600。
如果你想把本機模式轉為遠端託管（也就是可以透過 Dashboard 管理），可以執行：
cloudflared tunnel token home-lab
這會輸出一串 token，你可以把它交給 systemd 或 Docker 使用，之後就能在 Dashboard 上調整路由與政策，不必登入主機改設定檔。
4-3 DNS CNAME 與 Public Hostname 設定
不管你走哪條路線，最終在 DNS 上看到的都是一筆 CNAME 記錄，指向 <tunnel-id>.cfargotunnel.com。這筆記錄的「代理狀態」（橘色雲朵）必須是開啟的，否則流量不會經過 Cloudflare 邊緣，Tunnel 也就不會生效。
有幾個實務上的小技巧：
nas、ha、media、dev，一眼就能看出用途。4-4 憑證與 config.yml 進階設定（ingress 規則）
當你的服務超過三、四個，用 Dashboard 一個個點就會開始煩躁。這時候本機設定檔模式會更有效率。典型結構如下：
tunnel: home-lab
originRequest:
connectTimeout: 30s
noTLSVerify: false
httpHostHeader: nas.example.com
ingress:
規則由上往下比對，第一條符合的就生效
- hostname: nas.example.com
service: http://localhost:5000
- hostname: ha.example.com
service: http://localhost:8123
- hostname: media.example.com
service: http://localhost:8096
originRequest:
影音串流建議拉長逾時
connectTimeout: 60s
disableChunkedEncoding: true
- hostname: ssh.example.com
service: ssh://localhost:22
最後一定要有這條，否則未匹配的請求會回傳錯誤
- service: http_status:404
幾個容易忽略的重點：
五、安全發布：把「有對外開放」變成「只有你能進」
這是整篇文章最核心的章節。很多人以為用了 Tunnel 就等於安全，其實不然。Tunnel 解決的是「網路層暴露」的問題，但你的應用程式本身仍然可能被任何人存取。真正讓安全性提升一個檔次的，是 Cloudflare Access。
5-1 Cloudflare Access 應用程式與政策設計
Access 的運作邏輯是：當使用者請求某個受保護的網域時，Cloudflare 邊緣會先攔截，要求通過身分驗證，通過之後才把請求轉進 Tunnel。也就是說，未經授權的人連你的服務登入頁面都看不到，更別說嘗試暴力破解。
建立流程：Zero Trust → Access → Applications → Add an application → Self-hosted。填寫你要保護的網域（例如 nas.example.com），然後在 Policies 區段新增規則。
政策的組成是「動作（Action）＋ 條件（Include / Require / Exclude）」：
Action: Allow — 符合條件者放行。
Action: Block — 符合條件者直接封鎖。
常見的 Include 條件有：Emails（特定 Email）、Emails ending in（整個網域）、IP ranges（特定 IP 段）、Country（國家）、Azure AD group、GitHub organization 等等。
一個務實的政策組合範例：
Allow：Email 等於 [email protected]（自己）
Allow：Email 結尾等於 @mycompany.com（同事）
Block：所有其他（或直接用預設拒絕）
最外層還有一個「Default Deny」的開關，建議保持開啟。這樣即使政策寫錯，預設行為仍然是拒絕，而不是意外放行。
5-2 三種身分驗證：Email OTP、SSO、Service Token
Access 支援的登入方式很多，以下是最常用的三種：
Email OTP（一次性密碼）：最簡單、零設定。使用者輸入 Email，Cloudflare 寄一組六位數驗證碼，輸入即可。缺點是體驗較差，而且如果 Email 被盜用就等於被攻破。建議搭配 TOTP 或將其視為最低限度的防護。
SSO（單一登入）：支援 Google、GitHub、Microsoft Entra ID、Okta 等。這是體驗最好的方式，而且安全性取決於你原本的帳號安全（通常已有 MFA）。個人使用推薦 Google 或 GitHub，企業環境則用 Entra ID 或 Okta。設定時需要建立 OAuth 應用程式並填入 Client ID / Secret。
Service Token：給程式呼叫用。你會拿到一組 Client ID 與 Client Secret，之後在請求標頭帶上 CF-Access-Client-Id 與 CF-Access-Client-Secret 即可通過驗證。這在串接 API、自動化腳本、監控系統時非常實用。記得 token 要以安全方式儲存，並且設定到期時間。
5-3 進階防護：WARP、mTLS、IP 白名單
如果你的安全需求再高一點，可以考慮這些做法：
5-4 常見錯誤：把 Tunnel 當成無風險的萬能鑰匙
最後要澆一盆冷水。以下這些錯誤我見過太多次：
六、十大實戰場景設定範例
6-1 自架網站與 Web 服務
這是最單純的場景。假設你的網站跑在 localhost:3000：
- hostname: blog.example.com
service: http://localhost:3000
如果網站需要處理上傳檔案或長時間請求，建議調整 originRequest 的逾時設定，避免大檔案上傳到一半被切斷。另外，如果你的應用會檢查 X-Forwarded-For 來取得真實 IP，Cloudflare 會自動帶入，這點通常不需要額外設定。
6-2 NAS 檔案存取（Synology DSM）
Synology DSM 預設走 HTTP 5000 或 HTTPS 5001。由於 DSM 是管理介面，強烈建議套用 Access 政策，並且只允許自己的 Email：
- hostname: nas.example.com
service: https://localhost:5001
originRequest:
noTLSVerify: true
httpHostHeader: nas.example.com
noTLSVerify: true 是因為 DSM 多半使用自簽憑證，Cloudflare 到本地這段驗證不過。這在內網環境是可接受的，因為外層到 Cloudflare 之間仍然是加密的。
6-3 Home Assistant 智慧家庭
Home Assistant 預設埠是 8123。這裡有幾個要注意的地方：
- hostname: ha.example.com
service: http://localhost:8123
首先，Home Assistant 有自己的身分驗證機制，所以在 Access 政策上可以選擇「不全部擋」，而是允許家庭成員登入。或者更嚴謹一點，用 Access 做第一層把關，再讓 HA 做第二層角色控管。
其次，如果要使用 HA 的手機 App 或語音助理整合（例如 Google Assistant 或 Alexa），要特別注意這些服務需要能直接連線，不能被 Access 攔截。常見做法是另外開一個子網域專門給這些整合使用，並用 Service Token 或較寬鬆的政策處理。這部分的設定眉角較多，建議先在社群查詢對應版本的官方文件。
6-4 Jellyfin / Plex 媒體串流
影音串流對頻寬與逾時比較敏感：
- hostname: media.example.com
service: http://localhost:8096
originRequest:
connectTimeout: 60s
disableChunkedEncoding: true
disableChunkedEncoding: true 在某些播放器與 CDN 組合下可以避免串流中斷。另外，串流服務通常不適合套用 Access，因為播放器客戶端不一定支援互動式登入。實務上常見的做法是：對網頁介面套用 Access，但對媒體串流路徑使用較寬鬆的政策，或搭配 Jellyfin 自身的使用者驗證。
也要提醒，透過 Cloudflare 免費方案傳輸大量影片，雖然技術上可行，但如果流量已經接近商業等級，建議評估付費方案，避免服務條款爭議。
6-5 SSH、RDP、資料庫等非 HTTP 服務
Tunnel 不只支援 HTTP，也支援 SSH、RDP、SMB、TCP 等協定。以 SSH 為例：
- hostname: ssh.example.com
service: ssh://localhost:22
設定好之後，用戶端需要安裝 cloudflared 並設定 ~/.ssh/config：
Host ssh.example.com
ProxyCommand cloudflared access ssh --hostname %h
User your-username
之後直接 ssh ssh.example.com 即可。整個過程會經過 Cloudflare 的 Access 驗證（如果有設定的話），安全性遠高於直接把 SSH 埠開到公網——後者幾乎每天都會被嘗試登入上千次。
RDP 的設定類似，service type 選 rdp://localhost:3389，用戶端則使用 cloudflared access rdp。資料庫則建議只在內網使用，或透過 Access + Service Token 嚴格控管。
6-6 多服務共用一條 Tunnel 的 ingress 寫法
當服務很多時，與其建立多條 Tunnel，不如一條 Tunnel 搭配完整的 ingress 規則。這樣管理起來更集中，也能共用同一組連線。範例：
tunnel: home-lab
ingress:
- hostname: www.example.com
service: http://localhost:3000
- hostname: nas.example.com
service: https://localhost:5001
originRequest:
noTLSVerify: true
httpHostHeader: nas.example.com
- hostname: ha.example.com
service: http://localhost:8123
- hostname: media.example.com
service: http://localhost:8096
- hostname: ssh.example.com
service: ssh://localhost:22
- hostname: db.example.com
service: tcp://localhost:5432
- service: http_status:404
搭配 systemd 執行：
sudo cloudflared --config /etc/cloudflared/config.yml tunnel run
如果要用 systemd unit 管理，記得在 ExecStart 中帶上 --config 參數，並設定 Restart=always。
七、效能、可靠性與維運
7-1 延遲與頻寬實測觀念
很多人會問：「透過 Cloudflare 繞一圈，會不會變慢？」答案取決於你的位置與 Cloudflare 節點的距離。Cloudflare 在全球有數百個節點，通常使用者會連到最近的節點，而你的 cloudflared 也會連到最近的節點。整體延遲大約增加 10 到 50 毫秒，對於一般網頁與檔案存取幾乎無感。
但對於即時性要求高的應用（例如遊戲伺服器、VoIP），這個額外延遲就可能造成影響。這種情況下，建議改用 Tailscale 或直連 VPN。
頻寬方面，Cloudflare 免費方案沒有硬性上限，實測上要跑滿家用上傳頻寬（例如 100Mbps 或 1Gbps）通常沒有問題。真正會成為瓶頸的，往往是你的本地機器效能或應用程式本身。
7-2 多條 Tunnel 複本與 Load Balancer
當你只有一台主機時，cloudflared 會自動建立多條連線到不同資料中心，這已經提供了基本的高可用性。但如果你的服務不能中斷（例如公司對外網站），可以考慮在兩台以上的機器上各跑一條 Tunnel，並透過 Cloudflare 的 Load Balancer 做流量分配與健康檢查。
不過 Load Balancer 是付費功能，個人使用未必需要。較經濟的做法是：在主機上用 systemd 設定自動重啟，並監控 Tunnel 狀態；若主機掛掉，至少 Cloudflare 會回傳錯誤頁面而不是讓使用者連到錯誤的地方。
7-3 日誌、監控與告警
維運的關鍵是「出事時你能多快知道」。建議至少做到：
Cloudflare Dashboard 的 Analytics：可以看到請求量、錯誤率、延遲分布。異常的流量尖峰或大量 4xx/5xx 都是警訊。
Access 的稽核日誌：記錄誰通過驗證、誰被拒絕。免費用戶的日誌保留時間較短，重要服務建議定期匯出。
本機日誌：cloudflared 的日誌可以看到與 Cloudflare 的連線狀態。建議設定日誌輪替，避免塞爆硬碟。
Uptime 監控：用外部服務（例如 UptimeRobot）定期檢查你的網域，一有異常就發通知。
7-4 自動更新與開機自啟
如果你用 APT 安裝，可以用 unattended-upgrades 自動更新；Docker 則建議搭配 Watchtower 或類似的工具，但要注意自動更新有時會帶來非預期的行為變化，重要環境建議改為手動更新並先測試。
開機自啟的部分，systemd 與 Docker 的 restart: unless-stopped 都能處理。Windows 服務則在安裝時就已設定為自動啟動。務必實際重開機測試一次，確認服務真的會自己回來。
八、疑難排解：最常見的 8 個錯誤訊息
1. 502 Bad Gateway
最常見的原因是你的本地服務沒在跑，或 ingress 規則裡的埠號／主機位址寫錯。先在主機上 curl localhost:埠號 確認服務正常，再檢查設定檔。若使用 Docker 且不是 host 網路模式，localhost 指的是容器自己，要改成服務名稱或 host.docker.internal。
2. 1033 Argo Tunnel error
代表 cloudflared 沒有跟 Cloudflare 建立連線。檢查網路是否允許對外 7844 埠（QUIC）或 443 埠（HTTP2）的連線。有些企業防火牆會阻擋 UDP，這時可以加上 --protocol http2 強制走 TCP。
3. 530 / 1016 Origin DNS error
通常是 DNS 記錄沒有正確建立，或 CNAME 指向錯誤。到 DNS 頁面確認 CNAME 是否指向 <tunnel-id>.cfargotunnel.com，且代理狀態為開啟。
4. Tunnel 顯示 Connected 但網頁連不上
檢查 Public Hostname 的設定是否與你實際訪問的網域一致。常見錯誤是設定了 nas.example.com，但使用者卻輸入 www.example.com。另外也要確認 ingress 規則的順序正確。
5. Access 登入後不斷重新導向
通常是應用的 cookie 設定與 Cloudflare 衝突，或是應用的 Session 網域設定不正確。檢查應用程式的 base_url 或 trusted_proxies 設定。
6. 上傳大檔案中斷
調整 originRequest.connectTimeout 與 proxyTimeout。另外某些語言的框架有自己的上傳大小限制，也要一併調整。
7. WebSocket 連不上
Cloudflare 預設支援 WebSocket，通常不需要特別設定。若連不上，檢查應用程式的 WebSocket 路徑是否被 Access 政策或 WAF 規則阻擋。
8. cloudflared 啟動時報 credentials 錯誤
檢查 JSON 憑證檔的路徑與權限。常見問題是使用 Docker 時沒有把憑證檔掛載進容器，或檔案權限不正確導致讀取失敗。
九、常見問題 FAQ
Q1：Cloudflare Tunnel 真的完全免費嗎？
Tunnel 本身在免費方案中沒有流量限制，Zero Trust 的免費方案也涵蓋基本的 Access 功能。但如果你的使用規模已達商業等級，或需要進階的日誌保留、SAML、Load Balancer 等功能，就會需要付費方案。
Q2：我的網域一定要放在 Cloudflare 嗎？
是的，這是硬性要求。因為 Tunnel 的路由依賴 Cloudflare 的權威 DNS 與邊緣網路。如果你不想轉移整個網域，技術上可以只把子網域的 NS 委派給 Cloudflare，但設定上會複雜不少。
Q3：透過 Tunnel 的流量會被 Cloudflare 看到嗎？
Cloudflare 在邊緣負責 TLS 終止，所以技術上 Cloudflare 可以看到明文內容（除非你使用 End-to-End 加密的進階設定）。對多數個人與一般企業來說，這是可接受的取捨；如果是高度敏感的資料，建議在應用層再加一道端到端加密。
Q4：可以用來做遊戲伺服器嗎？
技術上可以轉發 TCP/UDP，但 Cloudflare 的免費方案主要設計給 HTTP/HTTPS 流量，遊戲的即時性與協定特性可能造成體驗不佳。這種場景建議考慮 Tailscale 或直接租用有公網 IP 的 VPS。
Q5：手機上要怎麼存取受 Access 保護的服務？
手機瀏覽器可以直接使用，登入流程與桌面相同。若是原生 App，則需要該 App 支援 Cookie 或 Token 機制。部分 App 可以透過 WARP 用戶端繞過登入頁面，但設定較複雜。
Q6：Tunnel 斷線多久會自動恢復？
cloudflared 會自動嘗試重新連線，通常在幾秒到幾十秒內恢復。Cloudflare 邊緣也會在連線恢復後立即恢復導流。若長時間無法恢復，通常是本地網路或雲端服務本身有問題。
Q7：我需要為每個服務建立獨立的 Tunnel 嗎？
不需要。一條 Tunnel 可以透過 ingress 規則服務多個網域與服務。只有在需要隔離（例如不同環境、不同團隊）或需要獨立擴展時，才建議建立多條 Tunnel。
Q8：舊版的 Argo Tunnel 還能用嗎？
Argo Tunnel 這個名稱已經被淘汰，相關指令與服務也早已整合進 Cloudflare Tunnel。如果你還在用非常舊的版本，建議盡快升級，否則可能遇到相容性問題或安全性風險。
結語：把複雜留給 Cloudflare，把安全留給自己
回顧這整篇文章，Cloudflare Tunnel 真正解決的，是自架玩家長年以來的結構性困境：我們想要擁有自己的服務、自己的資料、自己的掌控權，但不想為此變成半個網路安全專家，也不想每天擔心被掃埠、被入侵。
透過 Tunnel，你把「網路暴露」這個最難處理的問題外包給了 Cloudflare 的全球邊緣網路；透過 Access，你把「誰能進來」這個最關鍵的決策權牢牢握在自己手上。而你唯一需要維護的，就是那台跑著 cloudflared 的機器，以及你對自己服務的了解。
2026 年的現在，這套方案已經成熟到幾乎沒有理由不用。無論你只是想把家裡的 NAS 安全地開放給自己，還是要為小型團隊建立一套對外的服務入口，Cloudflare Tunnel 都是那個「設定一次、長期受益」的選擇。花一個下午把它架好，接下來的好幾年，你都能省下無數次跟防火牆規則搏鬥的時間。
如果你在實作過程中遇到本文沒涵蓋的狀況，歡迎到「雅寶社區 · 頂客論壇」的 3C 科技教學板塊發文討論，把你踩到的坑與解法分享出來，讓更多人少走一點冤枉路。
```