AWS帳號充值代辦 AWS RDS 連線逾時解決方法

第一章：先把「逾時」分清楚

RDS 連線逾時看似同一種錯誤，其實可能是不同階段卡住：網路層根本到不了、TLS/認證階段互相看不見、或資料庫已滿載導致連上後才卡住。你如果只盯著同一段程式碼反覆改，很容易浪費時間。

我建議把問題分成三個問題來問自己：

• 逾時發生在哪個時間點？是連「TCP 建立」就不回、還是連上後才超時？
• 從哪裡連？你的應用在同一 VPC、不同 VPC、還是公司網段？
• 是否只有特定 IP 或特定服務才逾時？這會直接指向安全規則或路由問題。

接著，下面的排查流程你可以當成路線圖：由外而內、由網路到資料庫，且每一步都要能得到「可觀測的證據」。

第二章：網路層先排雷（最常見）

多數 RDS 逾時不是 RDS 本身壞掉，而是你到不了它。AWS 的網路邏輯通常包含 VPC、子網路由、Internet Gateway 或 NAT、以及 Security Group / NACL。任何一環不通，就會表現成逾時。

2.1 確認 RDS 是公網還是私網

先看 RDS 實例屬於哪個設定：Publicly accessible 是開還是關。若你把 RDS 放在私有子網，卻從公網直接連，通常就會逾時。

• 若 RDS 為私網：你的連線端必須也在可到達的網路（例如同 VPC、透過 VPN/Direct Connect、或透過跳板主機）。
• 若 RDS 為公網：仍然要檢查 Security Group 是否允許來源 IP 與埠。

你可以用最基本的連線測試先建立信心：從你的應用所在環境測一次「能不能到端點與埠」。

2.2 檢查 Security Group（連得上還是卡住）

Security Group 是 AWS 最常被忽略的一環。RDS 端的 Security Group 必須允許入站到資料庫埠，來源通常是你的應用所在的 Security Group 或特定 CIDR。

AWS帳號充值代辦 常見錯誤包含：

• 你只開了 3306/5432 但來源 CIDR 寫錯了（例如少了 NAT 後的出口 IP）。
• RDS SG 允許了你的測試機 IP，卻沒有允許應用伺服器的 SG。
• 你在某個環境開通，另一個環境（例如 staging/production）沒有同步。

更可靠的做法是使用 Security Group 當來源（當兩邊都在同一 VPC 或可互通的前提下）。這比維護一堆 CIDR 更不容易失手。

2.3 檢查 NACL 與子網方向

若 Security Group 允許，仍逾時，下一個要看 NACL（Network ACL）。NACL 是「子網級」的防火牆，且它同時要看入站與出站規則。

• RDS 所在子網的 NACL 是否允許資料庫埠的入站？
• RDS 所在子網的 NACL 是否允許回包的出站？
• 你的來源子網 NACL 是否阻擋了你送出的請求？

AWS帳號充值代辦 很多團隊把 NACL 設成預設 deny，後來把 SG 開得很寬但忘了 NACL，結果就是逾時。

2.4 路由與跨網路（VPC peering / VPN / TGW）

如果你從不同 VPC、或透過 VPN/Transit Gateway 來連 RDS，路由要對得上。即使 Security Group 對了，路由錯了也會逾時。

AWS帳號充值代辦 檢查方向：

• 從你的應用子網到 RDS 子網的路由是否存在？
• 回程路由是否正確？（很多時候你只看了單向）
• 若使用 VPC peering，兩邊的路由表都要加上對方的 CIDR。

這裡有個實務提醒：在多段網路（例如公司 → VPN → VPC → 私有子網）中，出口 IP、來源路徑都可能跟你想的不一致，導致安全規則匹配不到。

第三章：用「可觀測」的方法證明網路是否通

AWS帳號充值代辦 排查逾時最怕的是只憑猜測。你需要把「網路是否可達」這件事用工具驗證。方法不必花俏，重點是你要在同一個位置測試。

3.1 從同一張網卡/同一環境測連線

最佳做法是從 應用部署位置（或盡可能接近其網路位置）做測試，而不是只在你自己電腦測。若你自己電腦在辦公室網段、應用在雲上用 NAT 出去，那兩者來源 IP 完全不同，結論也會不同。

你可以使用常見的連線測試工具（如 telnet、nc，或對應資料庫的 ping/check 工具）。測試重點是：對端是否立即回應、還是完全沉默。

• 沉默到逾時：通常是網路或防火牆阻擋（SG/NACL/路由）。
• AWS帳號充值代辦 很快拒絕：多半是埠沒開或服務沒在那個埠。
• 連上後出錯：可能是認證、TLS、參數、或資料庫端限制。

3.2 利用 AWS 的日誌與指標（RDS 層面）

當你確定網路通了，下一個就要看 RDS 端的日誌與指標。RDS 通常可以啟用資料庫引擎提供的相關 log（例如 PostgreSQL 的 log_connections、log_disconnections；MySQL 的 general/error）。

你想看的是：

• 有沒有連入？連到資料庫引擎後有沒有記錄？
• 失敗是在哪個步驟？例如認證失敗、SSL 需求不匹配、或連線數達上限。
• 是否只有某個帳號/來源被拒？

有時候程式端一直逾時，但 RDS 日誌其實有「連上後立即拒絕」的痕跡，這會讓你把問題從網路轉到安全策略或認證。

第四章：資料庫層面的原因（連上但卡住）

當網路可達，你仍可能遇到「連線逾時」。這時常見原因就落在資料庫層。

AWS帳號充值代辦 4.1 埠與端點是否正確

端點看似簡單，但實務上常發生下列狀況：

• 連到舊的 RDS endpoint（例如重建後端點不同）。
• 連錯埠（例如應用設定仍是 3306，但 RDS 實際是另一個 port）。
• 使用讀寫分離或多個實例時，連錯到了不接受連線的節點（例如某些配置限制）。

這一步建議你花時間核對：應用設定、環境變數、以及密碼/連線串的組裝是否一致。

4.2 最大連線數與連線池配置

若資料庫連線已滿，很多驅動程式會表現為等待或超時，特別是當你在應用端使用不恰當的連線池。

AWS帳號充值代辦 你可以從兩邊一起看：

• 資料庫端：max_connections（PostgreSQL）或 max_connections（MySQL 對應概念）是否達到上限？
• 應用端：連線池最大連線數是否超出資料庫能力？等待隊列 timeout 是否過短？

解法通常不是「把 timeout 拉很長」就好，而是要控制並發與釋放資源。必要時調整參數群組、或改良查詢/交易長度，降低長時間佔用連線的情況。

4.3 TLS/SSL 要求造成的逾時或握手失敗

如果你的 RDS 設定要求 SSL，應用卻沒有啟用，或使用了不相容的憑證/版本，也會導致看似逾時的連線失敗。

常見情形：

• 某些驅動在握手失敗時需要較長時間重試。
• 應用環境缺少 CA 憑證檔，導致驗證卡住或失敗。
• 你把「允許非 SSL」改成「強制 SSL」後，舊程式仍以非 SSL 方式連線。

建議你在測試階段顯式確認 SSL 設定，並把資料庫端的 TLS 設定與應用端一致。

4.4 認證機制與權限問題（不一定會立刻報錯）

RDS 可能使用特定的認證機制（例如 PostgreSQL 的某些設定，或 MySQL 的 plugin）。帳號密碼錯誤通常是明確錯誤，但在某些驅動或網路重試策略下，仍可能呈現逾時。

此外，IAM 認證（若你用的是 RDS IAM authentication）也會涉及簽章與有效期。如果系統時間不準，簽章過期，同樣會出現連線失敗。

因此你需要檢查：

• 帳號密碼是否正確（含環境變數與密碼管理策略）。
• 系統時間是否同步（尤其是簽章型認證）。
• 驅動是否支援並正確使用你選擇的認證方式。

4.5 參數群組與連線相關設定

某些引擎參數會影響連線行為，例如查詢超時、idle timeout、TCP keepalive 等。雖然它們多半影響「後續操作」而不是「最初連線」，但在實務中常被誤會成連線逾時。

你可以針對：

• 連線後等待狀態是否正常（例如應用卡在發 SQL 還是卡在建立連線）。
• 交易是否長時間未提交導致連線被占用。
• 是否存在重度負載造成排隊（這會讓 driver 看起來像超時）。

第五章：快速定位根因的「三步驟」流程

如果你想要在現場快速止血，我建議用以下三步驟，能把問題縮到很小的範圍。

5.1 第一步：確認網路可達性（TCP 層）

從應用所在環境測試 RDS endpoint 與埠。

• 可達：代表 SG/NACL/路由大概率沒問題，進入資料庫層排查。
• 不可達：優先檢查 RDS SG、來源 SG、NACL、路由與 Publicly accessible。

5.2 第二步：確認應用層使用的參數是否一致

把應用的連線字串/連線參數列出來核對：

• 端點、埠、資料庫名
• SSL 開關與憑證設定
• 連線池上限、等待時間
• AWS帳號充值代辦 認證機制（密碼或 IAM）

很多逾時不是因為 AWS 壞掉，而是因為「某次部署改了設定」。例如只更新了 staging 沒更新 production，就會造成不一致。

5.3 第三步：看 RDS 日誌與錯誤模式

如果網路與參數都不指向問題，那就看 RDS 是否出現對應連線或錯誤訊息。你要抓的是：有沒有連到引擎、失敗訊息是什麼、以及同時段的資料庫負載是否異常。

第六章：依情境給解法（含常見錯誤配方）

下面用幾個典型情境說明，並給出「你應該先做什麼」。

6.1 只有線上環境逾時，測試環境正常

這通常是安全規則或網路差異造成：

• production 的 RDS SG 沒有允許應用的來源 SG。
• production 使用不同子網或 NAT，來源 IP 變了。
• production 的 Publicly accessible 狀態不同。

做法：把兩個環境的 RDS SG、NACL、子網路由與 Publicly accessible 對照，找出差異。

6.2 從公司網段連不上，但從雲端機器可連

常見原因是 VPN/Direct Connect 沒打通，或路由/安全規則只針對雲端。你要確認：

• 公司的網段是否被允許進入 RDS SG（或使用來源 SG 不適用時，必須寫入正確 CIDR）。
• VPN 路由表是否包含 RDS 私有子網 CIDR。
• NACL 是否阻擋公司到雲端的流量。

6.3 應用端連線逾時，但 RDS 日誌顯示大量連入又很快斷開

這像是 TLS/認證或參數不相容造成的握手或拒絕。你要檢查：

• 應用是否使用同樣的 SSL 設定（強制/允許）。
• 憑證鏈是否能驗證（CA 是否存在）。
• 認證機制是否正確（密碼或 IAM 的有效性）。

此情境通常不需要改網路，反而要把「驅動設定」與「RDS 安全策略」對齊。

6.4 壓測或尖峰時段逾時明顯增加

多半是連線池、最大連線數或資料庫繁忙造成。策略是：

• 檢查資料庫端是否接近 max connections 或 CPU/IO 長期飽和。
• 檢查應用連線池設定：最大連線數與等待隊列 timeout。
• 找出是否有慢查詢或卡住的交易，導致連線長時間不釋放。

第七章：修復後怎麼驗證「真的穩定」

修復並不等於結束。你要驗證的是：逾時率下降、連線建立成功率提升、且沒有新的副作用（例如把 timeout 拉長導致隱性堆積）。

7.1 做對應時間窗的驗證

把修復時間點記下來，對照在修復前後的連線錯誤率與平均連線時間。若只看是否「現在能連」，容易在下一次尖峰又爆。

7.2 觀察連線數與等待時間

至少觀察：

• RDS 的連線數是否穩定、沒有持續上升。
• 應用端連線池等待是否明顯下降。
• 資料庫端 CPU/IO 是否恢復到可承受區間。

7.3 保留可複現的測試方法

建議你把「能驗證問題的最小測試」固化成 SOP。比如：

• 每次變更安全規則後，從指定環境測一次端點埠連通性。
• 每次變更 SSL 或驅動版本後，測一次含 TLS 的連線。
• 每次調整連線池或擴縮容策略後，跑一個短壓測觀察逾時率。

這樣下次再遇到類似問題，你不必重走一遍猜謎。

第八章：可落地的檢查清單（拿來就用）

如果你現在就想行動，下面是一份簡短但覆蓋面很完整的清單。

8.1 網路與安全

• 確認 RDS 的 Publicly accessible 設定符合你的連線來源。
• RDS SG 入站允許資料庫埠，來源正確（建議用來源 SG）。
• 檢查 NACL 入站/出站規則是否允許該埠與回包。
• 跨 VPC/VPN/Peering：路由表雙向是否完整包含 CIDR。

8.2 資料庫與連線

• AWS帳號充值代辦 端點與埠無誤（含重建後端點可能變）。
• SSL/TLS 設定一致（RDS 要求與應用啟用一致）。
• 認證方式一致（密碼或 IAM，系統時間正確）。
• 連線池最大連線數與資料庫 max connections 相容。
• 尖峰時段負載不會造成連線排隊或慢查詢。

結語：逾時不是玄學，是可以被定位的問題

AWS RDS 連線逾時之所以令人焦慮，是因為它把很多不同原因都揉成同一種表現。但只要你遵循由外而內的排查順序，把「可觀測證據」當作判斷依據，問題就會逐步縮小範圍。

你真正需要的不是更長的 timeout，而是更清楚的因果關係：到底是網路到不了，還是連上後握手/認證失敗，或資料庫資源不足導致等待。當你把這些原因拆開，解法也就自然明確。

下次再遇到類似錯誤，試著從「TCP 層可達性」開始，把結果記下來；之後每一步都要回答一個問題：這一步是否讓狀況朝正確方向變了？如果你能做到這點，再難的逾時也能被你拆解成可解的清單。