伺服器防火牆是什麼？程式只聽 127.0.0.1、只開 80 和 443，為什麼還要裝

你照著上一篇的建議，把程式改成只聽 127.0.0.1，Caddy 也穩穩地佔住 80 和 443，網站順利跑起 HTTPS。接著有人提醒你：「記得把防火牆打開。」你看著設定檔想了一下：程式已經躲在櫃台後面，對外也只想開兩個門，這樣還不夠安全嗎？

直接回答：不夠，因為「只開 80 和 443」在沒有防火牆的主機上並不存在。沒有防火牆時，主機上任何一支監聽 0.0.0.0 的服務都會直接對外營業，包括 SSH、資料庫、Docker 發布的 port、開發時忘了關的除錯 port，甚至是作業系統自己帶的小服務。127.0.0.1 只管得到你自己寫的那支程式，管不到別人裝的套件，也管不到半年後某位同事的一次手滑。防火牆的工作，就是在作業系統核心這一層，替整台主機加上一條「沒在名單上就不准進」的規則。

我們在寫上一篇Caddy Server 是什麼時，最常被追問的就是這一題，所以獨立寫成一篇。這篇延續同一個大樓比喻：127.0.0.1 是員工自己承諾只在辦公室裡講話，Caddy 是一樓櫃台，防火牆是大樓門口的警衛加門禁名單。三者各管一段，缺一段就會漏。

為什麼要這麼在意？Verizon 2026 年的資料外洩調查報告（DBIR）寫得很直接：利用軟體漏洞入侵已經超過偷密碼，成為駭客進門的第一名途徑，約佔 31% 的外洩事件，也是這份報告 19 年來第一次換位（Help Net Security 的整理也提到，修補已知漏洞的中位數時間拉長到 43 天）。漏洞要被利用，前提是攻擊者連得到那個服務；防火牆做的事，就是讓大部分服務根本連不到。

先看速覽表，三十秒就知道每個問題的答案在哪一段。

防火牆是什麼？大樓門口的警衛加門禁名單

一句話定義：防火牆是一組放在網路入口的規則，負責檢查每一個進出的封包，依照來源、目的地、port 與協定決定放行或丟掉。這篇講的是裝在伺服器自己身上的「主機防火牆」，和公司機房裡那種一整台的硬體防火牆概念相同，只是範圍縮小到一台機器。

回到大樓比喻。一棟大樓有很多房間（port），房間裡有沒有人上班，是程式自己決定的；大門口的警衛手上有一份門禁名單，訪客報出要去幾號房，名單上有才放行，沒有就請回。防火牆就是那位警衛。它不管房間裡的人在做什麼，只管「誰可以走到哪個房門口」。

有兩個名詞常被搞混，這裡一次講清楚：

表格最後一列要特別說明：很多人以為家裡路由器有 NAT 就等於有防火牆。NAT 確實會讓外面的連線找不到裡面的電腦，可是它的設計目的是共用一個對外 IP，擋人只是副作用。一旦你設了 port forwarding，或主機搬到雲端拿到真正的公網 IP，這層「順便的保護」就沒了。

最關鍵的觀念是：綁定位址屬於應用層的自律，防火牆屬於系統層的門禁。資安領域把這種多層保護叫做縱深防禦（defense in depth），意思是不讓任何一層單獨扛全部責任。任何一層失手，下一層還接得住。

只聽 127.0.0.1、只開 80 和 443，為什麼還不夠？

答案是：你能控制的只有自己寫的那支程式，而一台主機上監聽 port 的東西遠比你想的多。最快的確認方法，是登入主機跑一行指令，看看現在到底有誰在聽：

sudo ss -tulpn

下面是一台裝了 Caddy、資料庫和幾個工具的主機示意輸出（為了閱讀方便有精簡欄位）。你的程式乖乖地只聽 127.0.0.1:3000，可是整份清單裡，它只是其中一行：

Netid State   Local Address:Port   Process
tcp   LISTEN  127.0.0.1:3000       users:(("node",pid=812))
tcp   LISTEN  *:80                 users:(("caddy",pid=900))
tcp   LISTEN  *:443                users:(("caddy",pid=900))
udp   UNCONN  *:443                users:(("caddy",pid=900))
tcp   LISTEN  0.0.0.0:22           users:(("sshd",pid=640))
tcp   LISTEN  0.0.0.0:5432         users:(("docker-proxy",pid=1310))
tcp   LISTEN  0.0.0.0:6379         users:(("docker-proxy",pid=1342))
tcp   LISTEN  0.0.0.0:9229         users:(("node",pid=1022))
udp   UNCONN  0.0.0.0:111          users:(("rpcbind",pid=455))
udp   UNCONN  0.0.0.0:5353         users:(("avahi-daemon",pid=470))

逐行看，這台主機其實開了六扇你沒打算開的門：

• 22 號（SSH）：遠端登入一定要用，但它一上線就會吃到全世界的密碼暴力破解。
• 5432 與 6379（PostgreSQL、Redis）：用 Docker 啟動時寫了 -p 5432:5432，Docker 預設就發布在所有網路介面上。資料庫套件直接安裝時預設多半只聽本機，問題常出在後來為了讓自己的電腦連進去，把設定改成聽所有位址。
• 9229（Node.js 除錯）：某天為了遠端除錯加上 --inspect=0.0.0.0，修完忘了拿掉。這個 port 能直接執行程式碼，比資料庫外洩還嚴重。
• 111（rpcbind）與 5353（mDNS）：作業系統或某個套件順手帶進來的服務，很多人根本不知道它們存在。

這些都是真實世界每天在發生的事。Wiz 研究團隊在 2025 年 10 月揭露 Redis 漏洞 RediShell 時做過統計：網路上大約有 33 萬個 Redis 直接暴露，其中約 6 萬個完全沒設密碼，而且 57% 的雲端環境是用容器映像檔安裝 Redis，官方映像預設不需要驗證。同年 12 月 MongoDB 的 MongoBleed 漏洞爆發時，Tenable 引用 Censys 的掃描結果，可能受影響、直接對外的 MongoDB 超過 8 萬 7 千台。這些主機的主人，多半也相信自己「只開了需要的 port」。

所以「只開 80 和 443」要成立，必須有人在門口執行這份名單。這個人就是防火牆。它的預設規則是「進來的一律拒絕，只放行我寫在名單上的」，於是即使哪天有人把資料庫改成聽 0.0.0.0，外面的人還是連不到。

這也是我們自己踩過的事。我們的系統（例如恆遠會員中樞這類多產品共用的會員與訂閱平台）大多放在雲端部署平台上，內部一直在把資料庫連線收斂到平台內網、不走公網 port。做起來才發現最花時間的部分在盤點：哪些服務當初為了方便開了對外連線、現在還有沒有人在用。越早有一道預設拒絕的門，之後越不用回頭清。

防火牆實際在做什麼？封包過濾、規則鏈與連線追蹤

簡單講：每個封包進到主機時，Linux 核心會拿它去比對一串規則，比到第一條符合的就照做（放行、丟掉或拒絕），全部都不符合就套用預設政策。下面把這句話拆開來看。

netfilter 是引擎，ufw 和 firewalld 是方向盤

Linux 真正執行過濾的是核心裡的 netfilter 框架，iptables 和比較新的 nftables 是用來寫規則給它的工具。直接寫 iptables 規則很容易出錯，所以各家發行版提供了比較好上手的前端：Ubuntu 官方文件寫明 ufw（Uncomplicated Firewall）是 Ubuntu 預設的防火牆設定工具，而且安裝好時預設是關閉的；Red Hat、Rocky、AlmaLinux 這一系則慣用 firewalld。不管用哪一個，最後都是在 netfilter 裡寫規則。

預設政策：進來的拒絕，出去的放行

ufw 開啟後的預設政策是 deny incoming、allow outgoing，意思是外面主動連進來的一律擋掉，主機自己往外連（抓套件更新、查 DNS、呼叫第三方 API）一律放行。這是最適合一般網站主機的起點，因為攻擊幾乎都是從外面主動連進來。

連線追蹤：為什麼擋了進來，網頁還打得開

初學者常卡在這裡：既然預設拒絕所有進來的封包，主機去抓更新時，對方回傳的資料不也是「進來的」嗎？答案是防火牆會記帳。netfilter 有一個連線追蹤（conntrack）表，記錄每一條由主機發出去的連線，對方回應這條連線的封包會被認出來、直接放行。這種會記住連線狀態的防火牆叫 stateful 防火牆。比喻成警衛的話，就是他記得「剛剛是 302 室的人自己叫的外送」，外送員回來時不用再查名單。

DROP 和 REJECT 差在哪

被擋下的封包有兩種處理方式。DROP 是直接丟掉、什麼都不回，對方只能乾等到逾時；REJECT 會回一個「這裡不收」的訊號，對方立刻知道被拒絕。ufw 的 deny 就是 DROP，reject 則是 REJECT。對外的網站主機一般用 DROP：掃描程式得不到回應，要花更多時間猜，也少透露一點資訊。內部網路則常用 REJECT，同事連錯 port 時能馬上看到錯誤，排查比較快。

開了防火牆會有什麼副作用？最常見的七個影響

先講結論：防火牆本身幾乎不拖慢效能，真正的副作用都是「擋到不該擋的東西」，而且最常被擋到的是你自己。下面這張表把新手最常遇到的狀況整理在一起。

七項裡有兩項值得多講幾句。

SSH 鎖死是頭號新手事故。PHP Architect 在 2026 年 4 月一篇 Ubuntu 防火牆教學的標題就叫「五分鐘設好，外加一個會把你鎖在外面的步驟」，講的就是忘了先放行 OpenSSH。萬一真的發生，SSH 已經救不回來了，只能從雲端主控台的網頁終端機或救援模式登入，執行 sudo ufw disable 再重新設定。家裡或公司機房的實體主機，就得接螢幕鍵盤到現場處理。

HTTP/3 被擋不會出錯，只會變慢一點。Caddy 官方的全域設定文件寫明 protocols 的預設值是 h1 h2 h3，也就是預設就提供 HTTP/3。網路工程師 Mattias Geniar 在 2026 年的實測文提醒，大部分防火牆只開 TCP 443，UDP 被丟掉時瀏覽器會無聲地退回 HTTP/2，你永遠看不到 h3。網站還是正常，只是行動網路上的連線建立少了一點優勢。

其他副作用多半很輕微。效能方面，幾十條規則對一般網站的影響小到量不出來；高流量主機要注意的是 conntrack 表有上限，表滿時核心會開始丟新連線，這屬於每秒上萬連線才需要調整的進階議題。日誌方面，ufw 開啟記錄後，被擋的封包會以 [UFW BLOCK] 寫進系統日誌，公網主機每天可能累積大量掃描紀錄，記得設定日誌輪替。

Docker 會繞過 ufw：最多人中招的一個

這一條要獨立講，因為它違反直覺，而且後果嚴重。Docker 官方文件寫得很明白：Docker 和 ufw 使用防火牆規則的方式互相衝突，當你用 Docker 發布容器的 port，流量會在經過 ufw 的規則之前就被轉走。

原因在封包走的路線。docker run -p 6379:6379 會讓 Docker 在 nat 表寫一條轉址規則，封包一進主機就被改寫成「送往容器」，接著走 FORWARD 這條路；ufw 的放行名單卻掛在 INPUT 那條路上。兩條路從一開始就分岔，警衛站在大門口，訪客卻從地下停車場直接被帶上樓。

實務上有兩個可靠的解法，建議兩個都做：

第一，能不對外的容器 port 一律綁 127.0.0.1。Docker 的 port 發布文件建議在 -p 參數前加上 127.0.0.1，讓 port 只有主機自己連得到，Caddy 再從本機轉過去。文件同時提醒，Docker 28.0.0 以前的版本，同一個區網（例如接在同一台交換器上）的其他主機仍然連得到綁在 localhost 的 port，所以 Docker 也要記得更新。

# docker-compose.yml：資料庫與快取只給本機用
services:
  db:
    image: postgres:17
    ports:
      - "127.0.0.1:5432:5432"
  redis:
    image: redis:8
    ports:
      - "127.0.0.1:6379:6379"
  # 更好的做法：同一個 compose 網路裡的服務互連，根本不寫 ports

第二，需要對外但要限制來源時，規則寫在 DOCKER-USER chain。Docker 的 iptables 文件說明，這條鏈是專門留給使用者的，會在 Docker 自己的規則之前執行。例如只允許公司辦公室的 IP 連進容器：

# eth0 換成你的對外網卡，203.0.113.0/24 換成允許的來源
sudo iptables -I DOCKER-USER -i eth0 ! -s 203.0.113.0/24 -j DROP

要注意的是，Docker 29 開始提供實驗性的 nftables 後端，官方文件特別寫了 DOCKER-USER 的規則需要另外遷移。如果你的主機用的是新版 Docker 並切到 nftables，上面那行要改寫，不能直接照抄。

實際動手：用 ufw 幫 Caddy 主機設好防火牆

整套設定只要六行，順序是重點：先放行 SSH，再放行網站，最後才開啟。以下以 Ubuntu 為例，指令都要用有 sudo 權限的帳號執行。

# 1. 設定預設政策：進來的拒絕、出去的放行
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 2. 先放行 SSH（最重要，順序不能錯）
sudo ufw allow OpenSSH

# 3. 放行網站：80 給憑證驗證與轉址，443 不寫協定就同時開 TCP 與 UDP（HTTP/3）
sudo ufw allow 80/tcp
sudo ufw allow 443

# 4. 確認無誤再開啟
sudo ufw enable

開啟後用下面這行檢查，輸出應該長得像這樣：

$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443                        ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)
80/tcp (v6)                ALLOW IN    Anywhere (v6)
443 (v6)                   ALLOW IN    Anywhere (v6)

看懂這份輸出的三個重點：

• Default 那一行：deny (incoming) 代表名單以外的進入連線全部丟掉，這就是門禁的核心。
• 每條規則都有 v6 版本：ufw 預設同時管 IPv4 和 IPv6。只管 IPv4 的防火牆，等於後門沒鎖。
• 名單上只有三個 port：5432、6379、9229 都不在上面，從外面就連不到了（Docker 發布的 port 例外，見上一節）。

進階一點，可以把 SSH 改成 sudo ufw limit OpenSSH。Ubuntu 文件說明 limit 會對短時間內反覆連線的來源 IP 暫時拒絕，能擋掉大部分低階的暴力破解。如果只有公司固定 IP 需要登入，更好的寫法是 sudo ufw allow from 你的固定IP to any port 22，連門都只對你開。

如果你還在評估要不要自己管主機，可以先看網站主機怎麼選和PaaS 部署平台比較。PaaS 平台通常把對外入口收斂成一個 HTTPS 端點，這一整段防火牆設定由平台替你做掉。

開啟防火牆前後，技術上有什麼變化？

最直接的變化：從外部掃描時，被擋住的 port 由 open 變成 filtered（DROP）或 closed（REJECT），而主機內部的 ss 輸出完全不變。這點很重要：防火牆不會讓程式停止監聽，程式照樣在 5432 等著，只是外面的封包到不了它。

驗證方法是從「另一台」電腦對主機的公網 IP 掃描（在主機自己身上掃，走的是本機路線，看不出效果）。Nmap 官方說明把 port 分成六種狀態，最常見的三種意思如下：

同一台主機，開防火牆前後各掃一次，差異一目了然：

# 開防火牆前（從外部掃描）
$ nmap -p 22,80,443,5432,6379,9229 203.0.113.10
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https
5432/tcp open  postgresql
6379/tcp open  redis
9229/tcp open  unknown

# 開防火牆後（ufw 預設 deny，也就是 DROP）
$ nmap -p 22,80,443,5432,6379,9229 203.0.113.10
PORT     STATE    SERVICE
22/tcp   open     ssh
80/tcp   open     http
443/tcp  open     https
5432/tcp filtered postgresql
6379/tcp filtered redis
9229/tcp filtered unknown

如果開了 ufw，5432 掃出來卻還是 open，第一個要懷疑的就是 Docker：那個資料庫八成是用 -p 發布的容器。這也是為什麼我們建議改完設定後一定要從外面實際掃一次，不要只看 ufw status 說了什麼。

想定期自動做這件事，可以參考自架弱點掃描工具 OpenVAS 指南，它除了掃 port，還會比對已知漏洞。

防火牆之外：雲端安全群組、SSH 金鑰、fail2ban 與 Cloudflare 回源限制

主機防火牆是基本盤，再往外和往內各加一層，才算完整。每一層擋的東西不一樣，彼此替代不了。

雲端安全群組像園區大門。AWS 文件說明安全群組是 stateful 的，主機主動發出的請求，回應會自動放行，概念和主機上的 conntrack 一樣。它擋在主機外面，主機被入侵時也改不到它，所以是很好的外層。但它管不到同一個網段裡其他主機的連線，也管不到你在主機上犯的錯，主機防火牆仍然要開。

fail2ban 是一個會讀日誌的小幫手。它的 GitHub 說明寫得很清楚：它掃描像 /var/log/auth.log 這類日誌，發現某個 IP 登入失敗太多次，就去改防火牆規則把它封鎖一段時間。搭配 SSH 只用金鑰登入，暴力破解基本上就沒戲了。

Cloudflare 回源限制適合已經把網域掛在 Cloudflare 代理後面的網站。做法是讓主機的 80 和 443 只接受 Cloudflare 公布的 IP 範圍，攻擊者就算查到你的真實 IP，也沒辦法繞過 Cloudflare 直接打主機。兩個提醒：Cloudflare 的 IP 清單偶爾會更新，要定期同步；限制之後，Caddy 申請憑證的驗證流量也要能通過，建議改用 DNS 驗證，或上線前實際測一次續期。這一步屬於進階，先把前面幾層做好再考慮。

如果主機上跑的是 WordPress，入侵後怎麼救、平常怎麼防，可以看WordPress 被駭處理與資安指南；金鑰和 API key 外洩的真實案例，則整理在Zeabur 資安事件白話拆解。

公司自己架主機的最低安全清單，什麼時候該交給代管？

給中小企業老闆的判斷很簡單：主機上的防火牆、更新、備份、監控，每一項都要有一個具名的負責人。列不出負責人的那一項，就是遲早會出事的那一項。

這張表六項全部有人扛，自己架主機就是合理的選擇，成本低、彈性高。如果發現大部分項目都落在「應該是工程師會處理吧」，那更適合把主機交給 PaaS 部署平台或代管廠商，讓平台承擔防火牆與系統更新，你的團隊專心在程式本身。公司若正在準備資安認證，這張清單也和 CNS 27001 與 ISO 27001 導入指南裡的存取控制要求對得上。

AI 工具普及之後，這個判斷更急迫。很多團隊用 AI 很快做出一個能動的服務，直接丟上一台主機，防火牆、更新和備份一項都沒做。中小企業 AI agent 部署資安指南整理過大量服務暴露在外的真實事件；Vibe Coding 做的東西能不能直接上線則從工程師角度列出上線前要補的功課。

看到這裡，如果你的程式已經在主機上跑起來，卻不太確定這十項做到了幾項，我們很樂意 陪你在上線前把整台主機看一遍：哪些 port 該關、Docker 怎麼設、要自己管還是改用平台，我們會直接告訴你最划算的做法。