GCP實名帳號開通 解決GCP部署應用外網無法連接資料庫

第一章：問題不在「端口」，而在「路徑」

很多人遇到「外網連不上資料庫」時，第一反應是去防火牆或安全組把端口放開。但在 GCP 上，最常見的根因其實不是端口號，而是連線的路徑在某一段被切斷：DNS 指向錯誤的地址、VPC 路由不通、Cloud SQL 的連線來源被拒、資料庫根本只允許特定網段，或應用實例在外網卻沒有出站能力。

更麻煩的是，現象常常被描述成一句話：「外網無法連接資料庫」。你以為是外部使用者連資料庫，但實際可能是你的應用從外網/公網環境去連資料庫；也可能是資料庫只對私網開了、你的應用跑在公網但沒有經過正確的私網通道。只要你沒先把「是哪一方在連、經過哪條網路、連到誰的哪個地址」搞清楚，後面排錯就會像在黑暗中摸索。

因此，本文會用一個實戰導向的方式，把排查拆成幾個關鍵問題：資料庫在哪裡、你的應用在哪裡、連線走的是私網還是公網、GCP 允許的來源網段是什麼、以及防火牆/路由是否真的允許。

第二章：先分辨你遇到的是哪一種「連不上的」

在開始動配置前，先確認你看到的錯誤屬於哪個類型。不同類型往往對應不同層級的阻擋。

小節：超時 vs 立刻拒絕

1）如果你連資料庫直接超時（timeout），通常是「路由或網路層」不通，或安全規則沒有放行導致封包被丟棄。

2）如果你很快收到拒絕（refused）或明確的錯誤訊息，可能是「應用能到達但資料庫端沒有接受」或「認證/用戶權限」問題。

小節：解析成功但無法連

若 DNS 解析沒有問題，卻連不上，則比較可能是：網段來源不符合、Cloud SQL 只允許特定連線方式、或你使用了錯誤的 IP（例如把公網 IP 指到只能私網的終端）。

小節：應用在內網可連，外網不行

如果你發現同一套程式在「內網環境」可以連，但在「外網環境」不行，那幾乎可以確定差異存在於出站路徑、來源 IP、或使用了不同的連線端點（私網端點 vs 公網端點）。

第三章：典型場景拆解（Cloud SQL 與自建資料庫差別很大）

在 GCP，「資料庫」常見兩種：Cloud SQL（托管）或你自己跑在 Compute Engine / GKE / 其他 VM 上的資料庫。兩者在「怎麼允許連線」上完全不同。

小節：Cloud SQL 的關鍵是「連線來源」

Cloud SQL 的安全策略通常不是只靠「開端口」就結束，它還牽涉到：你允許哪些 IP/網段連過來、是否啟用 SSL、以及是否使用特定連線方法（例如專用連線、代理機制）。你可能以為自己已經開了防火牆，但如果 Cloud SQL 的 allowed networks 沒包含你的出站 IP，連線依然會失敗，且表現為超時。

小節：自建資料庫的關鍵是「網卡可達性」與「主機防火牆」

自建資料庫的狀況則更像傳統部署：資料庫所在的 VM/Pod 要能從你的應用網段到達；同時系統防火牆（例如 Linux 的 iptables/ufw）也要允許，另外如果你在 GCP 層還有 VPC 防火牆規則，兩者都要對上。

第四章：最常見的根因清單（照著勾，你會更快）

以下是我在實務中最常見的幾個原因，幾乎可以覆蓋大部分「外網連不上資料庫」的案例。你可以把它當成檢查表。

小節：應用使用了錯誤的資料庫端點（私網/公網）

例如你在本機或內網測試時，使用私網 IP 或特定的 private endpoint；但部署到外網環境後，程式仍指向私網地址。外網來源無法路由到該私網地址，就只能超時。

GCP實名帳號開通 反過來也一樣：你以為開了公網 IP，但實際上 Cloud SQL 只允許私網連線，你仍然連不上。

小節：來源 IP 變了（NAT 或重建後導致出站 IP 不在白名單）

很多服務會在外網環境使用 NAT。只要你改了 NAT 的配置，或用了不同的出站方式，應用對外呈現的來源 IP 就會變。Cloud SQL 又常常會用來源 IP 白名單策略，於是就出現「今天能連，明天不能連」的狀況。

這也是為什麼你看到的錯誤常常很像「網路壞掉」，但其實是「白名單不匹配」。

小節：VPC 防火牆只在內網放行，卻沒對應到外網出站路徑

GCP 的防火牆是以方向（ingress/egress）、目標（target）、來源（source）、協議/埠（protocol/port）來判斷。你可能只看了 ingress（進來）把規則開了，但你的應用其實需要的是出站（egress）允許，或反之。

更常見的是規則套用範圍錯誤：目標只綁到某個 network tag，但你的實例 tag 沒打上，規則看似存在，實際完全不命中。

小節：路由表不通（例如 VPC 間路由、或跨區域連線）

如果你的應用在一個 VPC，而資料庫在另一個 VPC，沒有打通 VPC peering 或沒有建立 Cloud Router + VPN / Interconnect，就算把防火牆端口都開了，也可能因路由不存在而到不了目的地。

這類狀況最典型的特徵是：你嘗試從應用所在環境去連資料庫，無論是 ping 或 TCP 探測都不通。

小節：GKE/Compute 的服務帳號或執行方式導致代理沒走到

若你使用某種連線代理（例如 Cloud SQL Auth Proxy 類似機制），前提是容器或服務帳號權限正確、環境變數端點正確、以及網路政策允許它發起對應連線。權限不夠可能呈現為連線失敗，但你以為是網路問題。

小節：啟用了私網，但應用只在公網跑，卻沒有建立私網通道

如果你把資料庫設在私網（或只允許私網 endpoint），你的應用必須能進入同一個私網範圍，或通過 VPN/Interconnect/VPC peering 進入該網段。否則「外網」再怎麼努力也連不到。

第五章：逐步排查流程（從「確認位置」到「修到能連」）

接下來給一個可照做的排查流程。你不需要一次改很多設定，目標是快速定位是哪一層阻擋。

小節：步驟 1——確認你連的是誰、連的地址是什麼

先在你的應用部署環境印出或記錄「資料庫連線字串」裡的主機名與端口。不要只看程式碼的預設值，因為環境變數或不同 profile 可能導致連線目標不同。

接著判斷該主機名解析後是什麼 IP：若它是 RFC1918 的私網地址（例如 10.x、172.16-31.x、192.168.x），那就代表你在依賴私網路由；外網環境如果沒有進到同一個私網，就必然失敗。

小節：步驟 2——在「應用所在環境」做連通性測試

你要在應用同一個環境去測，而不是在你自己的電腦測。因為 NAT、DNS、路由都不同。

常用方法是用 TCP 探測或資料庫連線測試工具。如果你測不到 TCP 層，先別急著談認證。

小節：步驟 3——對照 Cloud SQL 的連線來源策略

如果是 Cloud SQL：檢查它允許的「連線來源」是否包含你的應用出站 IP。你需要的是你的應用「從網路看出去」的來源 IP，不是你伺服器內網的固定地址。

這一步通常要你查清楚：你的應用是否經過 Cloud NAT？NAT 的 IP 是固定還是會變？如果會變，那就要改成更穩定的策略（例如使用固定 IP 的 NAT，或改用更適合的連線方式）。

小節：步驟 4——檢查 VPC 防火牆：ingress 與 egress 都要看

很多人只看目的端（資料庫所在的 VM/Pod）的 ingress 規則，卻忽略了源端的 egress。若 egress 被拒，封包在出站就被擋住，目的端根本收不到，自然也就連不上。

你需要確認：

• 目標：資料庫所在資源是否被正確標記（network tag 或 service account）。
• 來源：你的應用所在 IP/網段是否符合 source ranges。
• 協議/埠：是否允許資料庫需要的埠（例如 MySQL 3306、PostgreSQL 5432）。
• 方向：這次失敗到底是出站還是入站被擋。

小節：步驟 5——檢查路由與 VPC 連線

如果你的應用與資料庫不在同一個 VPC，先確認你有沒有做 VPC peering / VPN / Interconnect。若沒有，就要么建立私網通道，要么改成允許的公網連線方案（並配合資料庫安全策略）。

另外也要注意資料庫所在子網與應用所在子網是否因為自訂路由而導致封包被導向錯誤的路徑。

第六章：把設定做對——幾個真正有效的修正方向

當你定位出問題所在，就要選擇修正方向。不同架構的「最佳解」不一樣，但有幾個方向是最常見也最有效的。

GCP實名帳號開通 小節：方向一——明確使用私網通道（推薦給需要穩定與安全的場景）

如果你的目標是「外網用戶/外網環境能用，但資料庫只要私網安全連線」，最佳做法通常是：讓應用服務透過私網可達資料庫。

實務上你可以考慮以下思路：

• 把應用與資料庫放在同一個 VPC / 同一個區域網段。
• 如果跨 VPC，用 VPC peering 或 VPN/Interconnect 打通。
• 若要面向公網，使用負載均衡或入口層（例如 HTTPS/LB）對外，但應用到資料庫仍走私網。

GCP實名帳號開通 這樣你就不需要把資料庫暴露在公網，只需確保私網路由與防火牆允許。

小節：方向二——Cloud SQL：用正確的連線方式與固定來源 IP

Cloud SQL 常見策略是：

• 若你的應用可以穩定使用某個固定出站 IP（例如固定 NAT IP），就把該 IP 加到 Cloud SQL 的 allowed networks。
• 若你不能保證來源 IP 穩定，就考慮使用更適合的連線方法（例如透過代理機制或企業內連線策略）。

重點是：不要只盯著「我開了防火牆」，卻忽略 Cloud SQL 的 allowed networks 其實是另一條 gate。

小節：方向三——若必須走公網：最小權限開放與嚴格驗證

GCP實名帳號開通 有些情況下，你確實只能用公網連線。此時務必做到最小權限：

• 只允許必要埠（資料庫埠）
• 只允許必要來源 IP/網段（不要 0.0.0.0/0）
• 啟用 TLS/SSL（視資料庫而定）
• 做好資料庫帳號權限與密碼輪替

公網方式往往不是不能用，而是要知道「安全策略在哪一層」。你不能在 GCP 防火牆放行後就以為一切安全。

第七章：案例拆解——為什麼「開了規則」還是連不上

我遇過一個典型案例：團隊已經在 VPC 防火牆把資料庫端口開了，並且資料庫所在 VM 也在允許的 network tag 上。但外網環境仍然連不上，內網環境卻可以。

後來檢查應用設定才發現：外網部署使用了不同的環境變數，資料庫主機名解析到的是另一個 endpoint。內網指到私網 IP（可以路由），外網指到另一個需要特定通道才能抵達的地址（或根本指錯網段）。

修正後的做法是兩件事：

• 統一連線端點策略：內網使用私網端點，外網使用對應可達端點（或採取同一種可控的代理/通道）。
• 增加部署前檢查：在 CI/CD 或部署腳本中，輸出解析結果與連線目標，避免「改了規則卻連錯地方」。

這個案例提醒：排錯要先對齊「連的是對的地址」；防火牆再漂亮，只要端點錯了，永遠不會成功。

第八章：實務建議——讓你下次不再反覆試錯

GCP實名帳號開通 把排錯做成流程，不要靠運氣。以下是我建議團隊採納的做法。

小節：建立「網路與連線」的責任邊界

把問題拆成兩塊：網路可達性與身份認證。當你看到超時，就先集中在網路路徑與規則匹配；當你看到明確拒絕或認證錯誤，再看帳號權限或 TLS。

小節：部署時輸出關鍵資訊（但不要洩漏敏感內容）

部署日志保留以下資訊：

• 資料庫 host 與 port（不顯示密碼）
• host 解析到的 IP（或至少保留解析結果）
• 使用的連線模式（私網端點/公網端點/代理機制）
• 應用執行環境（區域、VPC、是否經 NAT）

當出問題，你不用回頭猜。

小節：固定出站策略，減少來源 IP 漂移

GCP實名帳號開通 如果你依賴 allowed networks，任何出站 IP 漂移都會造成不可預期的連線失敗。盡量使用可預期且固定的出站路徑。

第九章：總結——真正解決外網連不上資料庫的核心步驟

要解決「GCP 部署應用外網無法連接資料庫」，核心不是一個設定項，而是一套判斷順序：

• 先確認連線目標地址（私網/公網端點是否一致）
• 在應用所在環境測連通性（避免只在本機測）
• 若是 Cloud SQL，核對 allowed networks 與實際來源 IP
• 核對 VPC 防火牆的方向（ingress/egress）、標籤命中與端口
• 核對路由與 VPC 連線（VPC peering/VPN/Interconnect）

當你把「路徑」看成第一性原理，再去處理安全與認證，就會快很多。很多連不上的問題，其實早在你確認地址解析與出站來源時就已經浮出水面。

希望你看完這篇文章後，面對同類問題不再只盯端口，能用更清晰的方式把問題定位到具體層級，最後穩定地把服務與資料庫重新連起來。