GCP帳號充值辦理谷歌雲外網無法訪問80端口解決

谷歌雲GCP / 2026-08-19 15:57:14

第一章：問題的表面現象其實指向幾個固定方向

很多人遇到「谷歌雲外網無法訪問 80 端口」時，第一反應通常是：是不是網路壞了？但在實務上，外部連不到 80 端口，幾乎總能落在幾類原因裡：要麼安全規則把流量擋下了，要麼你以為服務在跑，其實並沒有真正監聽在 0.0.0.0:80，要麼你的 Web 服務只監聽了內網地址，或是反向代理把流量導向了不可用的後端。

更關鍵的是，排查不能靠感覺。你需要先把「外網請求是否真的到達你的虛擬機」這件事弄清楚。當你能回答這個問題，後面的大多數修正就會變得很直觀。

第二章：先確認你說的「80 端口」到底是什麼

在谷歌雲上，外部是否能訪問某端口，涉及多層：外部負載均衡（若有）、Cloud Armor（若有）、VPC 防火牆規則、目標實例是否在正確端口啟動服務，以及網卡與路由是否正常。很多人只看了最後一步的 Nginx 設定，卻忽略了最前面的「流量根本沒進來」。

你可以先做兩個區分：

你是直接訪問 VM 的外網 IP： 常見原因是 VPC/防火牆沒有放行 80，或服務未監聽對外地址。
你是通過負載均衡器訪問： 需要同時確認轉送規則、後端服務的健康檢查，以及防火牆/路由是否允許。

本文以「直接訪問 VM 外部 IP 的 80 端口」為主線；如果你的架構用到了負載均衡，我也會在中後段補上對應檢查點。

第三章：檢查防火牆與安全規則（最常見、也最容易踩坑）

如果外網連不上 80，第一個要查的是：是不是防火牆把它擋了。谷歌雲的防火牆通常以「規則」方式存在，可能有幾個來源：VPC 的防火牆規則、實例的標籤（network tags）、以及（若使用）額外的安全層。

3.1 確認目標實例是否有對應的 network tags

很多人建立了防火牆規則允許 80，但規則設計為「只對帶有某些標籤的資源生效」。結果就是：你以為規則開了，實例卻沒有打上那個 tag。

做法很簡單：

打開 Compute Engine 的實例頁面，找到你的 VM。
查看網路標籤（network tags）。
進到 VPC 防火牆規則，確認有一條 Ingress 規則允許 TCP 80，並且目標範圍包含你的 VM tag。

如果你不確定 tag 是什麼，就先暫時把規則目標設成「任意目標」或把 tag 對上，確認可通再收斂權限。安全性要慢慢調整，先讓服務跑起來。

3.2 確認來源範圍（source ranges）是否包含你的 IP

另一個常見問題是 source ranges 設成了某個網段，導致你自己的網路不在範圍內。你可以用一個臨時策略來驗證：先用你的實際外網 IP（或暫時 0.0.0.0/0）測通，確認後再改回來。

注意：如果你公司的網路出 IP 會變，或者你在家上網 IP 變動頻繁，更要避免寫死某個來源段。

3.3 分清「防火牆允許了」與「端口監聽」兩件事

即便防火牆開了，也還可能出現 80 端口不通。原因通常是服務沒跑或沒綁定正確地址。下一步你就要在 VM 上驗證。

第四章：在 VM 上確認 80 端口是否真的在監聽

很多人遇到問題，第一反應就是看 Nginx 配置，但 Nginx 配置再正確，若服務沒有啟動或監聽地址不對，外網仍然無法連上。

進到 VM 後做以下檢查（以 Linux 為例）。

4.1 用 netstat 或 ss 看是否真的在監聽 80

執行：

ss -lntp | grep ':80'

你希望看到類似以下資訊：

LISTEN 狀態
地址通常是 0.0.0.0:80（代表監聽所有網卡）或 <你的外網IP>:80

如果看到的只有 127.0.0.1:80，外部訪問必定失敗，因為服務只對本機回環地址開放。

4.2 檢查 Web 服務是否啟動

常見是 Nginx 或 Apache。你可以分別檢查：

systemctl status nginx
systemctl status apache2

若沒啟動，先啟動並設為開機自啟：

sudo systemctl start nginx
sudo systemctl enable nginx

如果你根本沒有安裝或選錯了服務，也會導致 80 不通。確定你部署的是 Nginx 還是 Apache，別兩套都只配一半。

4.3 用本機 curl 測試「服務本身」是否回應

GCP帳號充值辦理 在 VM 上執行：

curl -I http://127.0.0.1
curl -I http://localhost
curl -I http://<VM 的內網IP>
curl -I http://<VM 的外網IP>

如果 127.0.0.1 能回，內網 IP 不能回，通常是監聽地址綁得太死；如果所有都不回，可能服務未啟動或站點配置錯誤。

第五章：Nginx/Apache 監聽設定錯誤是第二大元兇

在谷歌雲的部署中，最常見的配置問題是：只寫了 listen 80; 但又把 server 針對 IPv6 或特定地址，或把 listen 80 default_server; 寫在錯的檔案、或把站點根路徑改壞導致 Nginx 直接報錯。

你應該把排查分成「Nginx 有沒有正常載入」與「Nginx 有沒有監聽對外」。

5.1 檢查 Nginx 配置是否有語法錯誤

先做檢查：

nginx -t

如果有錯，會直接影響服務載入。看到類似「test is successful」才代表配置檔案格式沒有問題。

再重載：

sudo systemctl reload nginx

5.2 檢查 listen 是否綁定對外地址

典型良好配置通常至少包含：

server {
  listen 80;
  listen [::]:80;
  server_name _;

  location / {
    proxy_pass http://backend;
  }
}

如果你使用的是直接站點（靜態或 PHP），那就用對應的根目錄和 fastcgi 設定。

如果你看到 listen 127.0.0.1:80; 或 listen <內網IP>:80;，外網就通不了。把它改成能被外部路由到的地址（一般用 listen 80; 即可）。

GCP帳號充值辦理 5.3 檢查 server_name 與重定向邏輯

有些站點會因為 server_name 不匹配而走到 default server，導致你以為是「端口不通」，其實是回應內容不對或是一直 301/302。你可以在外網用 curl 指定 Host 頭檢查：

curl -I -H 'Host: example.com' http://<外網IP>

若你其實訪問的是 IP，但站點只配置了域名，Nginx 會落到 default server。通常仍會回 HTTP，只是內容不同；若 default server 回了空頁或 404，也算是「端口通了但站點沒對」。這時你要把焦點從網路轉到站點配置。

第六章：如果 80 端口「通了」但你仍覺得不對，可能是回應卡住或反向代理失敗

有時外網連到 80，瀏覽器卻一直轉圈。這表示 TCP 連線成功，但應用層沒有正常返回。這種情況多半是 Nginx/Apache 轉發後端失敗，或後端服務不在、超時、DNS 解析問題等。

6.1 看 Nginx 日誌（第一手證據）

檢查：

tail -n 200 /var/log/nginx/error.log
tail -n 200 /var/log/nginx/access.log

你要抓住兩類訊號：

是否收到外部請求（access.log 有沒有相同 IP 的請求）
如果有收到，錯誤出在哪裡（error.log 指向上游 502/504、連不上 backend、或 upstream timeout）

6.2 常見的 proxy_pass 指向錯誤或後端端口不開

若你在 Nginx 用 proxy_pass 導向某個內網服務，請確認後端端口有在監聽，且防火牆允許「從 Nginx 所在的那台 VM 到後端」的流量（若後端在同一台 VM，則通常不需要額外防火牆；但若是不同 VM，就要看間網規則）。

也要確認 upstream 的名稱解析是否可靠。DNS 不通時，Nginx 可能報出解析失敗或連不上上游。

第七章：在外網測試時，先用更精確的方式判斷失敗點

瀏覽器的「無法連線」有時資訊太少。你應該用更細的測試方式，把問題定位在「網路層」還是「應用層」。

7.1 用外部機器測 TCP 是否能連上 80

你可以從外部機器執行：

nc -vz <外網IP> 80
# 或
telnet <外網IP> 80

若顯示連線失敗，基本就是防火牆/路由/安全規則/實例啟動與監聽問題。

7.2 再測 HTTP 層的返回狀態碼

當 TCP 成功後，再測 HTTP：

curl -v http://<外網IP> -m 5

你要關心：

是否收到 HTTP/1.1 狀態行（例如 200、301、404、502）
是否卡在某一步（例如一直等待 header）

第八章：若你使用負載均衡或 Cloud Armor，要檢查的項目會不同

很多人說「谷歌雲外網訪問 80」其實是經過某些服務轉發。當你用的是 HTTP(S) Load Balancing，80 通常由前端負責接入，後端服務由你設定的健康檢查、後端端口決定能否回應。

即使你的 VM 本身 80 配置好了，也可能因為負載均衡後端健康檢查失敗而不轉發。

8.1 健康檢查（health check）不通會導致外部看起來像不通

在負載均衡配置中查看 health check 狀態。常見原因包括：

健康檢查路徑對不上（/health 不存在）
GCP帳號充值辦理 健康檢查端口與後端服務端口不一致
防火牆不允許負載均衡器連到後端

你可以把健康檢查路径設成站點已確實存在的簡單頁面（例如返回固定 200 的 /healthz），先確定流程跑通。

8.2 Cloud Armor 或安全策略可能直接擋掉

如果你使用了 Cloud Armor，請檢查是否有拒絕規則。這類擋下來通常會有比較明確的日志（取決於你是否啟用相應的記錄）。

第九章：把排查流程做成清單，你會更快找出原因

下面給你一個「從外到內、由易到難」的排查清單。照順序走，通常不需要來回猜。

9.1 外部連線測試

從外網主機測 TCP：能否連到 <外網IP>:80
若連不上：回到防火牆/規則/監聽

9.2 防火牆/規則

是否存在允許 TCP 80 的 Ingress 規則
規則是否匹配 VM 的 network tags
source ranges 是否包含你的來源 IP

9.3 VM 端口監聽

ss -lntp 是否有 LISTEN 在 :80
地址是否為 0.0.0.0:80，而不是 127.0.0.1:80
Web 服務是否啟動、且有正常載入配置

9.4 HTTP 回應與代理

本機 curl -I 是否回應
Nginx/Apache 日誌是否顯示錯誤（502/504/上游連不上）
反向代理的 upstream 是否存在且端口可連

第十章：幾個可直接套用的修正範例

下面用「你可以立即改」的方式給出常見修正方向。你不一定要完全照抄，但能快速把關鍵點對齊。

10.1 防火牆放行 TCP 80

GCP帳號充值辦理 確保有類似：

Direction：Ingress
Protocol：TCP
Port：80
Targets：包含你的 VM tag 或 All instances（臨時驗證用）
Source ranges：先用你的外網 IP 或 0.0.0.0/0 測通

放行後立刻重新從外網測試，避免你修了一堆卻不知道哪一步生效。

10.2 Nginx 監聽改為對外

如果你原本是只監聽 127.0.0.1，改成：

server {
  listen 80;
  listen [::]:80;
  server_name _;

  root /var/www/html;
  index index.html;
}

改完執行 nginx -t 再 systemctl reload nginx，最後用 ss -lntp | grep :80 確認真的在 0.0.0.0:80。

10.3 修正反向代理 upstream

如果你有 proxy_pass 指向後端，請先用本機驗證後端可連：

curl -I http://<後端IP或服務名>:<後端端口>

GCP帳號充值辦理 再回頭調整 Nginx：

location / {
  proxy_pass http://<upstream>;
  proxy_connect_timeout 5s;
  proxy_read_timeout 30s;
}

若後端其實沒有開放該端口或服務不跑，Nginx 會反覆報 502/504，你就要先把後端治好。

第十一章：常見錯誤總結（避免你反覆踩同一個坑）

只改了 Nginx，卻忘了防火牆： 端口還是收不到外部流量。
以為已經啟動服務，但實際沒監聽 80： 可能服務啟動了但配置錯導致沒載入正確 server。
GCP帳號充值辦理 監聽地址綁成 127.0.0.1： 外網必連不上。
負載均衡健康檢查不通： 外部看起來像不通或一直 5xx。
反向代理上游錯： TCP 或 HTTP 看似建立，卻一直超時。

第十二章：把結果落地——驗證與交付

當你修好後，不要只用「瀏覽器打開看起來能用」就算完成。你至少要做三個驗證：

外部 TCP 測試： 能連到外網 IP 的 80。
GCP帳號充值辦理 外部 HTTP 回應： 返回合理狀態碼（200/301/302/404 都比一直失敗好）
日誌可追： 你能在 Nginx/Apache 日誌或負載均衡日誌中看到請求與結果。

如果這三點都成立，問題才算真正被解決。

GCP帳號充值辦理結語：80 端口不通不是玄學，是流程問題

「谷歌雲外網無法訪問 80 端口」通常不是單點故障，而是某一層沒對上：防火牆沒放行、服務沒有監聽到對外地址、負載均衡後端不健康、或代理轉發失敗。只要你用本文提供的清單從外到內逐步排查，幾乎都能在短時間內定位原因並修好。

你可以把這次經驗記成規範：新環境上線前先檢查防火牆規則、再檢查端口監聽、最後用外部 curl/瀏覽器做雙重驗證。當你建立這個流程，下次就不會再被同樣的問題拖住。