返回列表

AWS代理開戶服務 AWS域名綁定雲服務器與Route53解析詳細指南

亞馬遜雲AWS / 2026-09-03 15:45:38

第一章：把域名接到AWS，先想清楚你要指向什麼

在做「AWS域名綁定雲服務器與Route53解析」之前，最常見的失誤不是操作錯，而是目標不清：你要把域名指到哪一台資源？是EC2公網IP？還是負載均衡器（ALB）？是API Gateway？抑或是某個雲服務的固定終端？

AWS代理開戶服務 域名系統（DNS）本質上只負責一件事：把人看得懂的名字，解析成互聯網能連的地址。當你在瀏覽器輸入example.com，背後的解析過程會根據DNS記錄找到對應IP或CNAME，然後你的請求才能到達目標服務。

在AWS體系裡，Route 53是最常用的DNS服務。你可以把域名託管到Route53，或者只是在Route53裡建立解析記錄，讓外部域名註冊商把權威DNS指到Route53。

你要明確兩點：1）你的服務對外使用什麼端點；2）你希望域名解析的規則是根域名（@）還是子域名（如www）。

下面我們按照「從零到可用」的邏輯走：準備、建立託管區、設定記錄、驗證與排錯。你照著做，基本不會卡在“設了但打不開”的尷尬處境。

第二章：準備條件與工作範圍

2.1 你需要哪些東西

通常你需要：

一個已註冊的域名（例如 example.com）。
至少一個AWS資源作為目標（常見是EC2、ALB、或其他服務端點）。
對應AWS賬號權限，能進入Route53與目標資源的管理頁。
如果是EC2：確認安全組已開放對外端口（80/443等），並且實例有公網可訪問的方式（EIP或公網IP）。

2.2 先決定解析策略：EC2還是ALB

如果你的服務只是單台EC2，指到公網IP也可以；但實務上更推薦用ALB，因為它提供穩定端點、支援擴展與健康檢查。域名綁定的長期可維護性取決於你選擇什麼目標。

簡單記：
指向單台EC2：用A記錄或（若有EIP）直接綁IP。
指向ALB/CloudFront：可用Route53的ALIAS記錄，避免手動管理IP變化。

第三章：建立Route53託管區，讓權威DNS歸你管

3.1 準備：確認你的DNS由誰託管

域名註冊商通常提供修改名稱伺服器（Nameserver）的地方。若你的域名還在註冊商那邊管理DNS，你需要把權威DNS轉到Route53，或建立相應的解析指向。

判斷方式很簡單：進註冊商後查看當前的Nameserver。如果已經指向Route53的四個NS地址，那麼你可以直接在Route53裡建立記錄；若沒有，你需要在Route53完成託管區後，把NS改成Route53提供的。

3.2 在Route53建立Hosted Zone

進入Route53控制台，找到「Hosted zones」，點擊「Create hosted zone」。

你會看到兩種常見選項：

Public hosted zone：用於互聯網訪問的解析（多數情況）。
Private hosted zone：只在某VPC內可解析（企業內網常用）。

本指南以Public為主。

輸入域名（例如 example.com），選擇Public hosted zone，建立後你會得到一組NS記錄。接下來要做的事情取決於你目前域名的託管方式：把註冊商的Nameserver改成這組NS。

3.3 修改註冊商Nameserver

在域名註冊商後台找到「域名DNS設定/Nameserver」。把原本的NS全部替換為Route53提供的四個NS。

注意：改NS之後可能需要一些時間生效。不同域名供應商、TTL設定與全球DNS緩存狀況不同，通常從幾分鐘到幾小時不等。你能做的不是猜，而是耐心驗證。

第四章：理解DNS記錄類型，避免用錯

4.1 A/AAAA：直接對應IP

A記錄把域名指向IPv4地址；AAAA記錄把域名指向IPv6地址。當你有一個穩定的IP（例如EIP）時，A/AAAA是最直觀的選擇。

AWS代理開戶服務 4.2 CNAME：別名指向另一個域名

AWS代理開戶服務 CNAME用於把一個名稱指向另一個名稱。CNAME常用在你想把 www.example.com 指到某個已有域名（如 CloudFront 分配的域名）時。

但要注意：CNAME通常不適用於根域名（@）或與某些記錄組合衝突的情況；實務上Route53會限制根記錄的組合。

4.3 ALIAS：Route53提供的“類CNAME但能指根”的能力

Route53的ALIAS記錄可以把域名解析到AWS資源（例如ALB、CloudFront、某些S3靜態網站端點等）。它在概念上像CNAME，但它不是傳統CNAME那種直接“指向另一個名字”，而是由Route53在解析時提供目標的地址結果。

這帶來兩個好處：

對外域名可以指到AWS資源的“動態終端”，不用你手動追蹤IP變化。
能針對根域名（@）使用，而不受CNAME對根的限制。

如果你的目標是ALB/CloudFront，優先考慮ALIAS。

第五章：把域名指向EC2（最直觀但要注意穩定性）

5.1 檢查EC2的對外地址

進入EC2控制台，查看實例的網路設定。你可能看到兩種情況：

實例有公網IP（動態）。這種IP在停止/重啟或某些操作後可能變。
你使用了Elastic IP（EIP）（固定）。這種IP可以保證穩定，適合長期解析。

如果你要做“域名綁定服務器”並長期維持可訪問，強烈建議使用EIP。

5.2 建立A記錄：根域名或子域名

在Route53 Hosted zone裡，找到「Create record」。常見做法：

若你要讓 example.com 指向EC2：在Record name填入留空（或填@，依介面顯示），選A記錄，填入EC2/EIP的IPv4地址。
若你要讓 www.example.com 指向EC2：Record name填入www，選A記錄，填入IPv4。

TTL：建議先用Route53預設或填一個合理值。短TTL有利於你排錯時快速看到效果；但部署後可以逐步提高以減少解析壓力。

5.3 安全組與網路ACL：DNS能解析不等於能連上

這是“最常見的黑洞”。你可能在Route53確認解析成功，但瀏覽器仍報連線失敗。原因多半在：

EC2安全組沒有開放80/443（或你使用的端口）。
服務端沒有啟動或監聽在正確端口。
NACL或路由表阻擋了入口流量。

排查順序建議是：先用瀏覽器或curl測試連線，再檢查安全組入站規則，最後才看更底層的網路設定。

第六章：把域名指向ALB（更推薦的做法）

6.1 為什麼指向ALB更省心

ALB相當於你服務的“入口”。它會把外部流量分配到後端目標（EC2、容器、或其他服務）。對域名解析而言，ALB提供穩定的端點，且健康檢查能讓流量更可靠。

6.2 在Route53建立ALIAS記錄

在Hosted zone中建立新記錄：

Record type選擇A - Routes traffic to an IPv4 address（或介面顯示對應選項）。
Record name填入@（根域名）或www（子域名）。
Alias選項打開。
Alias target選擇你的ALB，通常會在下拉列表出現。

Route53會自動處理目標地址的解析結果，因此即使ALB背後地址變動，你的域名仍能正常工作。

6.3 HTTPS與憑證：不要把域名綁定當作“結束”

如果你想走HTTPS，你通常會在ALB上配置證書（可用AWS Certificate Manager）。這裡要注意：證書的網域名稱（CN/SAN）必須覆蓋你使用的域名（例如 example.com 與 www.example.com）。

否則即使DNS解析成功，仍可能遇到瀏覽器警告或握手失敗。

第七章：常見情境模板（你可以照這些方向做）

7.1 只有一台EC2，想讓example.com直接訪問

做法：

AWS代理開戶服務 EC2綁EIP。
Route53建A記錄：Name=@，Value=EIP IPv4。
EC2安全組開放80與443（若使用HTTPS）。
部署你的Web服務，確保監聽在正確端口。

7.2 想要www與根域名都可訪問

AWS代理開戶服務 你可以：

兩條記錄都指向同一目標：@與www分別建立A記錄或ALIAS。
也可以讓其中一個做跳轉（例如www指向根，或根指向www），但跳轉通常需要Web層或CDN支援，DNS本身不會幫你做HTTP跳轉。

如果你用ALB並處理HTTPS與HTTP重定向，最常見是直接讓兩者都指到同一ALB入口，再在程式或ALB規則中做重定向策略。

7.3 指向CloudFront（或其他需要CNAME/ALIAS的AWS資源）

若你使用CloudFront，通常做法會是：

www.example.com用CNAME指向CloudFront分配的域名。
根域名@若需HTTPS與穩定指向，優先考慮Route53 ALIAS指向CloudFront（視配置而定）。

你只要記得：CloudFront提供的是域名而非固定IP，因此CNAME/ALIAS比A記錄更合適。

第八章：TTL、緩存與生效時間：為什麼你改了但還是不通

8.1 TTL決定“你看到變化”的速度

TTL（Time To Live）是DNS記錄的緩存存活時間。改DNS之後，你需要等待全球DNS服務與本地解析器的緩存到期。即使Route53已更新，某些地區的解析器還可能仍回傳舊值。

排錯時建議做兩件事：

先把TTL調成偏短（例如60秒或300秒，視你的策略），更快驗證。
驗證時不要只盯著瀏覽器結果，改用DNS查詢工具看“解析到哪”。

8.2 用正確方式驗證DNS解析

你可以用以下思路：

AWS代理開戶服務 確認你解析的是正確的名稱（@是根域名，www是子域名）。
查詢A記錄與ALIAS解析結果是否匹配你期望的目標。
在改完之後，間隔幾分鐘再測，而不是立刻刷新當地緩存。

第九章：從“解析成功”到“服務可用”的完整驗證清單

9.1 解析層驗證

按順序檢查：

你輸入的域名是否有解析記錄。
是否解析到你期望的IP或ALB端點。
沒有出現錯誤記錄（例如把www指到另一台服務，或根域名指向錯誤端點）。

9.2 網路與應用層驗證

解析沒問題，下一步看連線與應用：

安全組入站是否允許HTTP/HTTPS。
目標服務是否正常運行。
HTTPS是否配置證書，且域名匹配。
若是ALB，監聽器與目標群組（Target group）健康狀態是否正常。

第十章：常見錯誤與排查策略（少走彎路）

10.1 設了Route53但外部還是連不上

最常見原因：

註冊商的NS沒有改指向Route53。
改完NS後未等待生效。
你改的是Private hosted zone，但你測試的是公網環境。

排查策略：先確認Route53是否真的成為權威DNS（以你查詢到的結果為準），再看記錄是否存在於正確的Hosted zone。

10.2 記錄類型用錯（A、CNAME、ALIAS混淆）

常見情況：

根域名用CNAME導致衝突或無法建立。
你用A記錄填了不該填的值（例如填了ALB名稱或CloudFront域名）。
目標資源實際需要ALIAS，但你選成普通記錄。

排查策略：先回到“目標是什麼資源”。資源決定記錄類型。

10.3 解析到對的IP/端點，但瀏覽器仍顯示超時

通常是網路層：

安全組沒開端口。
Web服務沒啟動或監聽在錯誤端口。
如果是ALB，Target group未通過健康檢查，流量被丟棄。

排查策略：先用ping或TCP連線測試基本連通，再查安全組與服務狀態。

10.4 HTTPS報證書錯誤

常見原因：

AWS代理開戶服務 證書沒有包含你的域名（例如只簽了example.com，沒包含www.example.com）。
域名指向了不同的入口，但你把證書配置在另一個ALB/服務上。

AWS代理開戶服務 排查策略：把“正在回應HTTPS的那個終端”找清楚，再對應到證書設定。

第十一章：一份可落地的操作流程（建議你照這張清單做）

11.1 步驟總覽

AWS代理開戶服務 確定域名（example.com）與你要指向的AWS目標（EC2/EIP、ALB、CloudFront等）。
AWS代理開戶服務 建立Route53 Public hosted zone。
把註冊商NS修改為Route53提供的名稱伺服器。
在Hosted zone建立對應記錄（@與www分別處理）：
- EC2：A記錄指向EIP。
- ALB/CloudFront：優先ALIAS或CNAME（依資源類型）。
確認目標資源入口可用：安全組、監聽器、Target group健康狀態、服務啟動。
等待DNS生效（受TTL與緩存影響），並用DNS查詢與端口測試驗證。

11.2 最重要的細節：根域名與子域名別混了

很多人只設了www，結果example.com還是連不上。也有人反過來，只設了@，www也會失效。你可以一次性把兩者都指向同一入口，讓使用者不用猜。

若你只想保留一個（例如只保留www），那就需要在Web/ALB層做HTTP重定向，而不是只靠DNS。

第十二章：把部署做穩：建議的工程化習慣

域名解析是“基礎設施”，好不好用不取決於你今天有沒有成功，而取決於你未來改動的成本。下面是一些實務建議：

用EIP或ALB/CloudFront避免IP漂移帶來的故障風險。
把安全組、NACL與目標服務的依賴關係寫成清單。下次排錯不用靠回憶。
記錄變更前後的時間點與測試方式。DNS是分布式的，你需要證據而不是情緒。
為HTTPS提前核對證書域名覆蓋範圍，尤其是根與www都要考慮。

結語：你其實不是在綁“域名”，你是在建立一條穩定的連線鏈

AWS域名綁定與Route53解析，看似只是幾條DNS記錄的事，但成功的關鍵在於整條鏈路的連貫性：權威DNS是否正確、記錄類型是否匹配目標資源、TTL是否符合你的驗證節奏、以及網路與應用層是否真正接受外部連線。

當你用Route53把權威託管落到正確的Hosted zone，並用正確的A/ALIAS/CNAME把域名指到正確入口，再配合安全組與服務狀態的檢查，你就能穩定地把域名接到AWS雲服務上。

你不需要記住所有術語才做得成。只要每一步都回答同一個問題：我這條記錄要讓誰被誰解析、解析到哪裡，以及那裡是否真的能接收請求。做到這三點，域名綁定就會變成可預期的工程，而不是運氣。