Caddy Server 是什麼？有主機和固定 IP，裝了它就能把程式公開上網嗎

Caddy 是一套開源的網頁伺服器，最常被拿來當「反向代理」：它站在你的程式前面，替程式接收來自網路的連線，還會自動幫網站申請並續期 HTTPS 憑證。所以回答標題那個問題：有一台主機、有固定 IP、裝好 Caddy，離「別人打網址就看得到你的程式」已經很近，但還差幾件事要湊齊：一個指向這個 IP 的網域、讓 80 和 443 這兩個 port 從外面打得進來（路由器、防火牆、ISP 三關都要過）、程式本身只對內開放，以及一台能長期穩定開著的主機。

這篇用初學者的角度，把整條路從頭講一遍。你會看到 port 是什麼、80 和 443 為什麼特別、ISP 是誰、為什麼有人明明照教學做了卻怎樣都連不進來，最後再談公司到底該不該自己架主機。每個新名詞第一次出現時，都會配一個生活化的比喻。

先說一下我們為什麼會寫這題。我們公司自己幾乎所有系統（官網、SalesKing、會員中樞等約 40 個專案）都放在雲端部署平台上，官網前面再擋一層 Cloudflare。每天處理的就是「程式怎麼安全地被外面看到」這件事，所以對新手卡在哪裡特別有感：卡關的地方幾乎都在 Caddy 之外。

下面這張表先把整篇的答案濃縮起來，三十秒看完就知道自己還缺哪一塊。

五個條件裡，Caddy 只負責最後一段的「櫃台工作」。其他四個條件，一個屬於網域商，三個屬於網路線那一端。理解這個分工之後，後面所有的設定都會變得很好懂。

Caddy 是什麼？用一棟大樓的櫃台來理解

先給一句話的定義：Caddy 是一個用 Go 語言寫成的網頁伺服器與反向代理，特色是設定檔很短，而且預設就會自動開啟 HTTPS。

網路上的名詞很多，我們乾脆把整台主機想成一棟商辦大樓，所有角色都能找到對應：

用這個比喻來看「反向代理」就很直覺了。訪客（瀏覽器）只認得大樓正門，他不知道也不需要知道你的程式在幾號房。Caddy 坐在櫃台，收到「我要找 example.com」的訪客，就把他帶到 3000 號房；收到「我要找 api.example.com」，就帶到 8080 號房。對外只有一個門口，對內可以有很多間辦公室。

Caddy 在市場上算是小眾但成長中的選擇。W3Techs 的網頁伺服器統計寫得很清楚：在已知伺服器軟體的網站裡，Nginx 大約佔 30.8%，Caddy 大約 1.1%。份額不大，可是開發者社群很活躍，Caddy 的 GitHub 有七萬多顆星，2026 年 10 月初才剛釋出 v2.11.7，更新頻率相當穩定。

它被新手喜歡的原因很單純：同樣是「把網域轉給本機 3000 port 並開 HTTPS」，Caddy 的設定只要三行，其他伺服器常常要寫二三十行，再另外裝一套申請憑證的工具。少寫一行設定，就少一個出錯的地方。

如果你對「程式跑在容器裡」這件事還不熟，可以先看Docker 是什麼那篇。Caddy 本身也很常和 Docker 一起用，一個容器跑 Caddy、其他容器跑你的程式。

80 和 443 是什麼？網路世界的兩個標準門口

直接講答案：80 是 HTTP（沒加密）的預設 port，443 是 HTTPS（有加密）的預設 port。瀏覽器打 http:// 開頭的網址時，會自動去敲對方的 80 號門；打 https:// 開頭時，會自動去敲 443 號門。這就是為什麼你平常上網從來不用輸入 port 號碼。

回到大樓比喻：80 和 443 就像全世界約定好的「正門」與「掛號信收件口」。你的程式在本機跑在 3000 port 時，等於開在 3000 號房，訪客要打 http://你的IP:3000 才找得到。這樣能用，但很難看，也沒有加密，多數公司網路和瀏覽器還會對非標準 port 比較警戒。

Caddy 的工作就是佔住 80 和 443 這兩個正門，把訪客轉進 3000 號房。它還會做一件很貼心的事：有人從 80 進來（沒加密的 http），Caddy 會自動把他導到 443（加密的 https）。

為什麼 443 幾乎是必備？因為現在的網路已經預設全加密。Let's Encrypt 在 2025 年底的年度信提到，他們剛成立時網路上只有 39% 的頁面載入有加密，現在世界上許多地區已經超過 95%。瀏覽器對沒加密的網站會直接標示「不安全」，表單、登入、付款這些功能等於不能用。

下面這張圖是一個訪客從輸入網址到看到畫面，連線會經過的每一關。任何一關沒開，就會卡住：

看懂這張圖，除錯就有方向了。Caddy 只住在 F 這一格，前面的 B 到 E 都在它的管轄範圍外。新手最常遇到的狀況是 F 設得完美，訪客卻在 C 或 D 就被擋下來。

順帶一提，我們自家的產品也是照這個分工在跑。像恆遠會員中樞系統（讓多個產品共用註冊、登入、訂閱與權限）就放在雲端部署平台上，HTTPS 憑證和對外的門口交給平台處理，工程師只管程式本身。這也是後面會談到的替代方案之一。

ISP 是什麼？為什麼家裡的網路常常讓 Caddy 白忙

ISP（Internet Service Provider，網路服務供應商）就是幫你拉網路線、給你 IP 的公司。在台灣，中華電信 HiNet、台灣大寬頻、遠傳、凱擘大寬頻都屬於 ISP。你每個月繳的網路費，就是付給它們的。

ISP 會決定三件影響架站的事：你的 IP 會不會變、你的 IP 是不是獨享、它讓不讓外面的連線進來。這三件事 Caddy 都改變不了。

浮動 IP 與固定 IP

浮動 IP 就像每隔一段時間被換一次門牌號碼的房子。家用寬頻多半是浮動 IP，數據機重開、斷線重連都可能換一個號碼。DNS 記錄卻還指著舊門牌，訪客就找不到你。固定 IP 則是門牌永遠不變，DNS 設一次就好。固定 IP 通常需要另外申請，或改成企業方案，各家條件與費用不同，以 ISP 客服的回覆為準。

CGNAT：整條街共用一個門牌

比浮動 IP 更麻煩的是 CGNAT（Carrier-Grade NAT，電信等級網址轉換）。用比喻來說，ISP 為了省 IPv4 位址，讓一整條街的住戶共用同一個大門牌，再在 ISP 那邊自己分配。從外面看，你和鄰居長得一模一樣，訪客敲門時，ISP 根本不知道要送給哪一戶。

CGNAT 使用的位址段是 RFC 6598 規定的 100.64.0.0 到 100.127.255.255。判斷方法很簡單：登入路由器看 WAN（外網）IP，再用手機連家裡 Wi-Fi 去搜尋「what is my ip」。兩個數字一樣，代表你拿到的是公網 IP。路由器上顯示 192.168 或 10 開頭，代表前面還有一層 NAT，通常是 ISP 給的數據機，請 ISP 改成橋接模式多半就能解決；顯示 100.64 到 100.127 開頭，就是 CGNAT，port forwarding 怎麼設都沒用。手機行動網路（4G、5G）幾乎都是這種情況，所以用手機分享網路架站基本上行不通。

ISP 可能擋 80 或 443

有些 ISP 的家用方案會擋住從外面進來的 80 port，目的是避免一般住戶在家裡經營網站或被駭客當跳板。這個問題很老：iT 邦幫忙上 2012 年就有人在問ADSL 從外部連不進 80 port，十幾年後同類型的求救文還是每年出現。各家政策會改，最準的方法是自己測：請朋友用手機行動網路連你的 IP，或用線上的 port 檢查工具看 80 和 443 是否開放。

網路痛點討論區最常見的劇情是這樣：照著英文教學把 Caddy 裝好、Caddyfile 也寫對了，日誌卻一直出現憑證申請失敗。花了一個週末重灌系統，最後才發現路由器上看到的 IP 是 100 開頭。這類求救在 Reddit 的 r/selfhosted 與各種自架社群幾乎天天都有，問題的根源全在 ISP 那一端。

實際動手：從安裝 Caddy 到寫好 Caddyfile

假設你已經確認自己有固定公網 IP，而且 80 和 443 沒被擋，整個流程大約 30 分鐘就能做完。以下以 Ubuntu 或 Debian 主機為例，安裝指令照 Caddy 官方安裝文件。

第一步，先在網域商（或 Cloudflare）的 DNS 設定裡，新增一筆 A 記錄：名稱填 @ 或子網域，值填你的固定 IP。設好之後在主機上確認它真的指過來：

dig +short example.com
# 應該回傳你的固定 IP，例如 203.0.113.10

第二步，安裝 Caddy。官方提供的套件庫會自動處理更新，裝完後 Caddy 會以系統服務的方式在背景執行：

sudo apt install --yes debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

第三步，編輯設定檔 /etc/caddy/Caddyfile。下面這三行就是整篇文章的主角：把 example.com 的訪客，轉給本機 3000 port 上的程式。

example.com {
    reverse_proxy 127.0.0.1:3000
}

想讓同一台主機服務兩個程式？再加一段就好，櫃台會依照訪客要找的名字分流：

example.com {
    reverse_proxy 127.0.0.1:3000
}

api.example.com {
    reverse_proxy 127.0.0.1:8080
}

第四步，開主機防火牆、設路由器。主機在公司或家裡的路由器後面時，要在路由器的 port forwarding（虛擬伺服器）頁面，把外部的 80 與 443 轉到這台主機的內網 IP。主機防火牆則只放行這兩個 port 加上 SSH：

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
journalctl -u caddy -f   # 看憑證申請的即時日誌

最後一步驗收記得用手機行動網路測試，別用同一個 Wi-Fi。很多路由器不支援「從內網連自己的外網 IP」（一般稱為 NAT loopback 或 hairpin），內網測試失敗不代表外面連不到，內網測成功也不代表外面一定連得到。

Caddy 自動 HTTPS 怎麼做到的？Let's Encrypt 在背後做什麼

一句話：Caddy 會自動向免費的憑證機構（預設是 Let's Encrypt，失敗時改用 ZeroSSL）證明「這個網域真的是你的」，拿到憑證後裝好，快到期前再自動續期。整個過程你不用下任何指令。

HTTPS 憑證可以想成一張「大樓名稱的公證書」。瀏覽器看到公證書，才相信 example.com 這棟樓確實是你的，連線也才會加密。以前申請一張要花錢、要手動上傳檔案、每年續約，忘了續就整站跳紅色警告。Let's Encrypt 把這件事變成免費又自動化，現在服務的網站已經從一年前的 4.92 億成長到 7.62 億（同樣出自上面那封年度信）。

Caddy 證明網域所有權的方法叫 ACME 驗證，常用的有三種。Caddy 官方的自動 HTTPS 文件把條件列得很清楚：網域的 A 記錄要指向主機、80 和 443 要從外面打得進來、Caddy 要能使用這兩個 port、存放憑證的資料夾要能寫入且不會被清掉。

關於憑證，2026 年有兩個新變化值得知道。第一，Let's Encrypt 宣布會把憑證效期從 90 天縮短，2027 年 2 月起預設改為 64 天，2028 年 2 月再縮到 45 天，這是整個憑證產業依照 CA/Browser Forum 規範一起調整的。用 Caddy 的人幾乎不用煩惱，因為續期本來就是自動的；手動管理憑證的系統就要開始檢查自動化流程。

第二，很多人會問：「我只有固定 IP、沒有網域，能不能直接拿憑證？」Let's Encrypt 在 2026 年 1 月正式開放 IP 位址憑證，但規定只能用短效版本，效期大約 160 小時（六天多一點），理由是 IP 很容易換手。Caddy 遇到純 IP 的網址，預設會用自己簽的內部憑證，訪客的瀏覽器會跳出「不安全」警告。結論很實際：一年幾百元買個網域，比折騰 IP 憑證省事太多，網域怎麼挑可以參考企業網域怎麼選與註冊。

還有一個常被忽略的坑：用 Docker 跑 Caddy 時，如果沒有把資料夾掛到外面保存，每次重建容器都會重新申請憑證。重複申請太多次會撞到 Let's Encrypt 的頻率限制，網站可能好幾天拿不到新憑證。

安全性：程式只聽 127.0.0.1，門只開 80 和 443

最重要的一條規則：你的程式應該只監聽 127.0.0.1，讓 Caddy 當唯一的對外門口。

127.0.0.1 是「本機自己」的特殊位址，只有同一台主機上的程式連得到。0.0.0.0 則代表「所有網路介面都接受」，外面的人只要知道 port 號碼就能直接連進來。很多框架的開發模式預設綁 0.0.0.0，新手在本機開發時不會發現差別，一上線就等於在大樓側面多開了一扇沒有警衛的門。

這扇側門很快就會被找到。網路上隨時有大量自動化程式在掃描整個 IPv4 空間，看哪個 IP 開了哪些 port。Palo Alto Networks 的 Unit 42 在 2021 年做過一次蜜罐實驗：故意把 320 台有弱點的服務放到公開雲上，80% 在 24 小時內就被入侵，一週內全部淪陷。實驗距今幾年了，數字會變動，可是「上線就被掃」的現象只會更普遍。

以 Node.js 為例，把 app.listen(3000) 改成 app.listen(3000, '127.0.0.1')，就把側門鎖起來了。Python 的 uvicorn 用 --host 127.0.0.1，Docker 則把 -p 3000:3000 寫成 -p 127.0.0.1:3000:3000。這一行的差別，決定了你的程式是躲在櫃台後面，還是直接站在街上。

綁 127.0.0.1 只是第一層。主機上還有 SSH、資料庫和 Docker 發布的 port，要讓「只開 80 和 443」真的成立，還需要一道預設拒絕的主機防火牆。為什麼需要、ufw 怎麼設、Docker 為什麼會繞過它，完整寫在伺服器防火牆是什麼。

AI 工具普及之後，這個問題被放大了。很多人用 AI 幫忙寫出一個能動的服務，順手就丟上網，結果整個管理介面都暴露在外。中小企業 AI agent 部署資安指南整理過真實的暴露事件，金鑰外洩的路徑可以再看Zeabur 資安事件白話拆解。

我們的判斷很直接：對外營業的服務，安全防線要假設「明天就會被掃到」來設計。Caddy 幫你把 HTTPS 這一關顧好，剩下的 port 管理、系統更新、備份，仍然是主機主人的責任。

Caddy 跟 Nginx 怎麼選？新手與團隊的判斷方式

簡單講：個人專案、小團隊、想快點上線，選 Caddy；團隊已經有 Nginx 經驗，或需要大量現成的設定範例與外掛，選 Nginx。兩個都是成熟的工具，挑錯也不會毀掉專案。

我們的看法是，對多數中小企業來說，網頁伺服器選哪一套的影響，遠比「主機放在哪裡、有沒有人顧」小。花一個月比較 Caddy 和 Nginx 的效能差異，還不如花一個下午把備份與監控設好。

如果你的服務會越長越多（十幾個程式、需要自動擴充），那時候要談的就是容器編排了，可以先看K3s 是什麼，了解輕量版 Kubernetes 怎麼接手這些工作。

沒有固定 IP 怎麼辦？三種替代方案

沒有固定 IP、遇到 CGNAT、或 ISP 擋 port 時，可以從三條路裡挑一條：Cloudflare Tunnel、租一台雲端主機（VPS）、或用部署平台（PaaS）。三條路都能讓程式被外面看到，差在費用、控制權和要顧的東西多寡。

Cloudflare Tunnel 的原理和一般架站相反。一般架站是「開門等訪客進來」，Tunnel 則是你的主機主動打一通電話給 Cloudflare，之後訪客的連線就沿著這條電話線送回來。主機不用開任何對外 port，CGNAT 也擋不住它。Cloudflare 官方文件有完整的安裝說明，基本功能免費，條件是網域的 DNS 要交給 Cloudflare 管。

租雲端主機（VPS） 等於直接在網路上租一間有固定門牌的房間，每台都附公網 IP，80 和 443 也不會被擋，Caddy 照本文第四段的步驟就能跑。主機類型怎麼挑，可以看網站主機怎麼選那篇的六種類型比較。

部署平台（PaaS） 則是連主機都不用顧，把程式碼交給平台，它幫你處理 HTTPS、網域、重啟與擴充。我們自己的系統大多跑在這類平台上，五大 PaaS 平台比較與Zeabur 評價整理了實際用過的心得。

Cloudflare 除了 Tunnel，還能在主機前面擋一層快取與防護。主機偶爾掛掉時訪客仍看得到頁面的做法，寫在Cloudflare 救援機制實戰。只是想從外面連回公司或家裡的電腦（而非公開網站），用遠端連線工具更合適，可以參考Mac 對 Mac 遠端連線指南。

公司要自己架主機，還是交給雲端？老闆的判斷清單

給中小企業老闆的結論：對外營業的正式服務，優先放雲端；辦公室那台主機適合跑內部工具、測試環境與學習。

技術上，一台主機加固定 IP 加 Caddy 確實能撐起一個網站。問題出在技術以外：颱風天停電、大樓網路維修、硬碟老化、唯一懂設定的同事離職，任何一件都會讓網站停擺。雲端主機與部署平台的價值，就是把這些風險攤給專門處理它們的人。

評估時可以用一個簡單的問題：「這個服務停掉一天，公司會損失多少？」答案是幾乎沒影響，在辦公室架、拿來練功都很好；答案是客戶打電話來罵、訂單進不來，就該交給有人顧的地方。

另一種很常見的情況：程式是用 AI 工具做出來的，在自己電腦上跑得很順，想直接放上網給客戶用。能跑和能安全上線中間還隔著一段距離，Vibe Coding 做出來的 App 能直接上線嗎那篇有工程師角度的完整檢查。你的程式已經有雛形、卡在上線這一步，我們很樂意幫你做一次上線前的健檢，看看哪些地方要先補起來。

如果評估完決定交給專業團隊，從規格到部署怎麼談，可以先讀客製化網站開發完整指南。已經在跑的網站想補強憑證與備份，WordPress 網站被駭怎麼辦裡的 SSL 與備份章節同樣適用。