AWS代理開戶服務 AWS 雲伺服器無法上網怎麼檢查路由

第一章：先把「無法上網」定義清楚

同樣叫做「不能上網」，實際上可能是三種不同現象：第一是連不上外網（TCP 連線失敗），第二是解析不到網域名（DNS 失敗），第三是連得上但回不來（多半是路由或防火牆方向/回程不通）。你如果一開始就把所有狀況當成同一類問題去排，通常會越查越亂。

因此建議你在開查前先記下三個資訊：你要測的是「IP 還是網域名」、錯誤訊息是什麼（例如超時、連線被拒絕、找不到主機）、以及你這台雲主機在哪個子網（public 子網或 private 子網）。這些線索會直接決定後面你要檢查的路由元件是 Internet Gateway 還是 NAT，甚至有沒有可能根本不是路由問題。

在 AWS 常見的排查節奏是：先確認主機是否有基本網路（IP/網卡/預設路由），再看 VPC 的路由表是否把流量「送往正確的出口」，接著才檢查安全群組與網路 ACL 是否放行，最後才回到 DNS 與作業系統設定。

第二章：從主機端開始確認「基本路由是否存在」

很多時候「看起來像路由」其實是主機層面的設定錯誤，例如預設路由沒有設好、網卡被重置後沒有附到正確的子網。先在雲主機上做最短路徑的確認，能大幅縮短定位時間。

2.1 檢查網卡是否在正確的子網、是否拿到正確 IP

進入該 EC2（或你使用的雲伺服器）後，先看網卡資訊。你要確認的是：主機是否真的在你以為的子網中；它是否取得了該子網應有的 IP 範圍（私有 IP 或公有 IP）；以及它的網關（gateway）是否存在。

在 Linux 上你可以查看：

查看 IP：

ip a

查看路由：

ip route

重點看兩件事：有沒有 default via 這種預設路由；以及 default 的 gateway 是不是符合該網段/該子網的慣例。如果 default 路由根本不存在或指向錯誤地址，那多半不是 AWS 的路由表，而是網卡/系統的網路設定問題。

2.2 用「IP 測試」先排除 DNS 影響

下一步先不要測網域名，直接 ping 或測試連線到一個固定 IP（例如公用 DNS 的 IP）。目標是判斷：連線卡在路由、還是只是 DNS。

你可以用：

ping 8.8.8.8

或測 TCP：

curl -m 5 http://1.1.1.1

AWS代理開戶服務 若「IP 不通」，通常指向路由/IGW/NAT/Security 層問題；若「IP 通但網域不通」，才集中看 DNS（/etc/resolv.conf、VPC DHCP 選項、或網路出口是否放行 UDP/TCP 53）。

第三章：路由表是核心，先看你走的是 IGW 還是 NAT

AWS代理開戶服務 在 AWS 裡，路由（route）決定封包要往哪裡送。對外網（0.0.0.0/0 或 ::/0）的出口通常只會落在兩種路徑：公開子網走 Internet Gateway（IGW），私有子網走 NAT Gateway 或 NAT Instance。你只要搞清楚「這台主機所在的子網類型」，接下來檢查路由表會更有方向。

3.1 找到子網對應的路由表

AWS代理開戶服務 你需要到 VPC 的「路由表」檢查該子網關聯哪一張路由表。常見情況是：你以為改了某張路由表，但實際子網綁的是另一張。這也是現場最容易踩的坑。

操作思路：

• 到 VPC → Subnets：確認子網 ID
• 到 VPC → Route Tables：查看該子網是否已關聯到某張 route table
• 在 route table 中檢查是否有 0.0.0.0/0（IPv4）和（如需要）::/0（IPv6）

如果沒有對外的預設路由，主機當然無法把目的地推往外網。

3.2 公開子網（public subnet）：0.0.0.0/0 必須指向 Internet Gateway

如果你的 EC2 是放在 public subnet，正確的路由應該是：路由表中有一筆 0.0.0.0/0 → igw-xxxx。此外，子網的「是否自動分配公有 IPv4」也會影響你是否能直接拿到公網位址，但即使沒公網 IP，對外通信的方式仍取決於路由與安全策略；在 public subnet 通常是允許直接到 IGW。

你還要檢查 VPC 是否真的已附掛 Internet Gateway。IGW 必須 attached 到正確的 VPC，否則路由就像指向不存在的門。

3.3 私有子網（private subnet）：0.0.0.0/0 必須指向 NAT Gateway

AWS代理開戶服務 若 EC2 在 private subnet，對外通信一般靠 NAT。正確的路由應該是：0.0.0.0/0 → nat-xxxx。另外，你要確認：

• NAT Gateway 的所在子網是否是 public subnet（通常 NAT 要放在 public subnet 才能連到 IGW）
• AWS代理開戶服務 NAT Gateway 是否是 active 狀態（有時會因為刪除網關或資源變動導致不可用）
• route table 是否確實被 private subnet 關聯

只要少其中一項，你的私有主機就會像「被困在內網」一樣無法對外。

第四章：不要只看 0.0.0.0/0，還要看你是否被更精細的規則覆蓋

AWS 路由規則是有「最長前綴匹配（longest prefix match）」概念的。你可能在 route table 裡看到某筆看似正確的 0.0.0.0/0，但其實還有更精細（例如某個網段）的路由指向了不通的目標，導致特定目的地（例如某些公司 IP、特定雲服務區段）失敗。

所以你應該做兩件事：第一，針對你測試的目的地（IP 或網域解析後的 IP）看它落在什麼網段；第二，確認 route table 沒有把該網段導向錯誤目的（例如錯把 VPC Peering、Transit Gateway、或其他 interface）。

4.1 如果你用的是 VPC Peering / Transit Gateway，額外確認回程路由

若你的「外網」其實是透過 VPC Peering 或 TGW 轉到另一個網段，那不是單向問題。你要同時檢查：

• 來源 VPC 的路由表：目的網段是否有指向 peering/TGW 的路由
• 目標 VPC 的路由表：回程（destination 對應的回去路徑）是否正確

很多人只看來源的路由，結果回程封包找不到路徑，TCP 連線會一直卡住直到超時。這種狀況常被誤判為「目的端不通」，但其實是回程缺路。

第五章：安全群組與網路 ACL 是路由的「另一半」

路由把封包送出去，但安全策略決定封包能不能通過。若路由與出口完全正確，仍然無法上網，就要轉到 security groups（SG）與 network ACL（NACL）。

5.1 檢查安全群組：出站（egress）是否允許

安全群組是狀態型（stateful），但依然可能因為出站規則（egress）限制而導致你「連不出去」。預設情況 SG 常常允許所有出站（0.0.0.0/0 TCP/UDP 全開），但很多團隊會為了合規把 egress 改成只允許特定服務，結果你突然就上不了網。

你需要確認以下：

• 針對你的測試目標（例如 80/443）是否有允許出站
• 若你測 DNS，是否允許對解析器的 UDP/TCP 53

此外，若你用的是代理或需要特定 port，規則也要包含相應連線。

AWS代理開戶服務 5.2 檢查網路 ACL：入站與出站都必須放行

NACL 是無狀態（stateless），所以入站與出站規則都要明確允許。這點經常造成「能夠送出但回不來」的錯覺。

你可以針對主機所在子網的 NACL，檢查：

• 是否允許臨時埠回應流量（通常是 ephemeral ports，例如 1024-65535，或用更寬範圍依策略設計）
• 是否允許目的地 port（例如 80/443、或 DNS 53）
• 是否有某個 deny 優先於 allow（因為 NACL 是按 rule number 從小到大匹配）

若你看到 NACL 有較嚴格的 deny 规则，且 rule number 比 allow 更靠前，那就算 SG 放行也不會通。

第六章：DNS 失敗時，路由可能是對的，但你還差一口氣

當 IP 可以通但網域名不能解析，很多人會立刻怪 DNS 伺服器，但在 AWS 裡你也要考慮：你的主機是否能對外找到 DNS；路由是否允許 UDP 53 或 TCP 53；以及 VPC 的 DHCP option 是否配置正確。

6.1 檢查主機的解析器設定

在 Linux 上通常看：

cat /etc/resolv.conf

確認 nameserver 指向的 IP。若解析器指向內網某個地址，但那地址其實不可達，DNS 就會失敗。

如果你使用 VPC 的內建 DNS（通常會啟用），解析器會指到 VPC 內的 DNS 地址。這通常可用，但前提仍是安全策略與路由。

6.2 確認 VPC DNS 設定與 DHCP options

在 VPC 設定中，檢查 DNS resolution 與 DNS hostname 是否啟用（依你需求）。如果你把這兩項關掉，某些情況下網域解析就會出問題。

另外，若你自訂過 DHCP options（例如指定不同 DNS server），要確保那個 DNS server 在網路上可達，且相應端口規則放行。

第七章：NAT Gateway / NAT Instance 常見故障點

當你判斷是 private subnet 無法上網，NAT 是最重要的查核對象。NAT 自身的健康狀態與其前後端路由關係，會決定整段鏈路是否正常。

7.1 NAT Gateway 所在子網必須可連到 IGW

NAT Gateway 通常放在 public subnet。若 NAT Gateway 所在的 public subnet 的 route table 沒有正確指向 IGW，NAT 就不可能把流量帶到外網。

因此你不只要看「私有子網的 route table 指到 NAT」，也要回頭看「NAT 所在 public 子網」本身是否具備 0.0.0.0/0 → igw。

7.2 NAT Gateway / Instance 的安全群組與路由

NAT Gateway 由 AWS 管理，通常你不直接管它的 OS 防火牆，但 NAT Gateway 依然要通過路由表與網路 ACL、以及（若涉及）的安全群組策略（例如 NAT instance 會有安全群組）。

如果你用的是 NAT Instance（較少見但仍可能存在），你需要額外確保：IP forwarding 開啟、iptables 或防火牆規則允許轉發、以及 security group / NACL 放行轉出的流量與回程。

第八章：把排查流程變成「一張清單」

下面給你一個實務上可直接照做的清單。你不需要一次全檢完；但至少依序走完，通常就能鎖定問題點。

8.1 主機端（先排除系統層）

• 確認 ip a 看得到網卡，且 IP 落在預期子網範圍
• 確認 ip route 有 default via
• 用 IP 測試（例如 1.1.1.1）判斷是路由還是 DNS
• 必要時測 traceroute（看封包停在何處）

8.2 VPC 路由（決定出口）

• 確認子網關聯的 route table 是哪一張
• 公有子網：檢查 0.0.0.0/0 → Internet Gateway
• 私有子網：檢查 0.0.0.0/0 → NAT Gateway/Instance
• 檢查是否有更精細網段路由覆蓋導致測試失敗
• 若用 Peering/TGW：確認回程路由也正確

8.3 安全策略（決定能不能通過）

• SG：檢查出站（egress）是否允許你需要的 port（80/443、53 等）
• NACL：檢查入站/出站都允許，且 rule number 順序沒有 deny 先命中

8.4 DNS（只在必要時深入）

• 主機 /etc/resolv.conf 的 nameserver 是否可達
• VPC DNS resolution/hostname 設定是否啟用（依實際需求）
• 若自訂 DHCP options：DNS server 地址與安全規則是否正確

第九章：用案例理解「路由錯在哪裡」

下面用三個常見情境，讓你知道人們通常在哪一步漏掉。

9.1 公有子網竟然沒有指到 IGW

某團隊把 EC2 放在 public subnet，但路由表原本為了測試留著只有內網路由，卻忘了加 0.0.0.0/0 → igw。主機端 default via 可能仍然存在（AWS 會提供子網 gateway），但預設目的地沒有「出路」，所以 ping 外網會超時。

這類問題修法很直接：回到 route table 增加 IGW 路由，並確認 IGW 已附掛到同一個 VPC。

9.2 私有子網指到 NAT，但 NAT 所在子網路由錯了

典型狀況是：私有子網正確配置 0.0.0.0/0 → nat，但 NAT Gateway 所在 public subnet 的 route table 沒有指到 IGW。結果 NAT 的狀態可能看起來還在，但實際上無法把流量送到外網。

所以你要回頭檢查 NAT 所在子網的出口路由，而不是只盯著 private subnet。

9.3 安全群組放行出站，但 NACL deny 了回程

有時 SG 幾乎都是全開，外部連線看似應該成功，但就是一直超時。排查後發現 NACL 有較嚴格的入站/出站限制，並且 deny 規則在前，導致回程封包被攔截。因為 NACL 是無狀態，你「送出」並不代表「回得來」。

解法是針對回應方向放行必要的臨時埠範圍，或依你的服務端口與協定精確配置。

第十章：最後的判斷原則——路由先行，安全次之，DNS 看情況

你可以用一個簡單原則來收斂排查方向：

• 若 IP 也連不上：優先查 route table 與出口（IGW/NAT）
• AWS代理開戶服務 若 IP 通但網域不通：優先查 DNS 設定與 UDP/TCP 53 的放行
• 若方向性問題（只出不回或卡在特定連線）：優先查 NACL 與回程路由

另外，AWS 的網路問題很常因為「改動過」而發生。你如果近期動過 VPC、路由表、NAT、NACL、SG，請把這些改動當成線索，而不是從零開始猜。

真正能把你從迷霧中帶出來的，不是單一設定，而是把鏈路拆成幾段：主機預設路由 → 子網路由表 → 出口（IGW/NAT）→ 安全策略（SG/NACL）→ DNS 解析。當你逐段確認，你就會知道到底卡在哪一段。只要那段被修正，你的雲伺服器上網問題通常就會迎刃而解。

如果你願意，我也可以依你目前的情況（public or private、目標是 IP 還是網域名、是否使用 NAT、以及你看到的錯誤類型）幫你把上述清單縮成「最短排查路徑」，讓你更快定位。