如何對 Java 應用程式中的 UnknownHostException 錯誤進行疑難排解？

簡短描述

UnknownHostException 是 Java 應用程式中常見的錯誤訊息。此錯誤通常表示 DNS 解析失敗。如果 Java 應用程式無法取得有效的 DNS 答案，則可能會擲出 UnknownHostException 錯誤。

除了 DNS 問題外，此錯誤的根本原因可能是：

• 影響 DNS 解析的軟體問題
• 驅動程式問題
• Amazon Elastic Compute Cloud (Amazon EC2) 執行個體中的網路中斷

解決方法

**注意：**如果您在執行 AWS Command Line Interface (AWS CLI) 命令時收到錯誤，請確定您使用的是最新的 AWS CLI 版本。

確定錯誤的根本原因

1. 使用 Windows 遠端桌面協定 (RDP) 或 Secure Shell (SSH) 協定，來連接至託管 Java 應用程式的伺服器。
2. 對導致錯誤的 DNS 名稱執行 dig 命令 (Linux) 或 nslookup 命令 (Windows)。
3. 根據輸出，檢閱下列案例：

來自 dig 或 nslookup 命令的有效答案

如果您從 dig 或 nslookup 命令取得有效答案，但在 Java 應用程式中繼續收到 UnknownHostException 錯誤，則可能存在應用程式層級問題。若要解決應用程式層級問題，請嘗試下列方法：

• 重新啟動應用程式。
• 確認您的 Java 應用程式沒有錯誤的 DNS 快取。如果可能，請將應用程式設定為遵循 DNS TTL。若要使用固定 TTL，請指定 60 秒或更短時間。如需詳細資訊，請參閱為 DNS 名稱查詢設定 JVM TTL。

在下列範例中，伺服器或 DNS 解析程式出現網路問題。應用程式無法連接，然後逾時：

$ dig timeout.example.com

;; global options: +cmd
;; connection timed out; no servers could be reached

如果來自 Amazon EC2 執行個體的 dig 命令顯示無法存取任何伺服器，請確認已為來源 VPC 開啟 DNS 支援選項。如需詳細資訊，請參閱 Amazon DNS 伺服器。

在下列範例中，在 VPC 層級停用 DNS 支援。在對 cloud-flare DNS 伺服器 (1.1.1.1) 的 dig 正在解析時，針對 VPC 解析程式 (10.1.1.2) 的 dig 查詢和 telnet 失敗。

$ dig google.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> google.com
;; global options: +cmd
;; connection timed out; no servers could be reached

$ telnet 10.1.1.2 53
Trying 10.1.1.2...
telnet:connect to address 10.1.1.2: No route to host

$ dig google.com @1.1.1.1 +short
142.251.16.102
142.251.16.139
142.251.16.138
142.251.16.113
142.251.16.101
142.251.16.100

有效的 NOERROR 回應遺失有效的答案部分

這種情況通常是由於存在地理位置路由政策，但記錄沒有伺服器地理位置的 DNS 答案。您可以建立記錄並定義地理位置記錄，或建立預設記錄。

以下是此案例的範例輸出：

$ dig noanswer.example.com

;; ->>HEADER<<- opcode: QUERY, <b>status: NOERROR</b>, id: 49948
;; flags: qr rd ra; QUERY: 1,
    ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com.   
    300    IN    SOA    ns1.example.com. ns2.example.com. 1 7200 900 1209600 86400

此外，如果未在公有託管區域中建立 DNS 記錄，且網域名稱系統安全延伸 (DNSSEC) 已開啟，則傳回 NOERROR - NOANSWER，而不是 NXDOMAIN。

若要驗證 DNSSEC 的狀態，請執行下列 dig 命令，以顯示 NSEC： **注意：**將 domain 取代為您的網域。

dig <domain> +trace

輸出看起來類似於：

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> example.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43917
;; flags: qr rd ra; QUERY: 1, ANSWER:0, AUTHORITY: 1, ADDITIONAL: 1
;; AUTHORITY SECTION:
example.co.uk. 300 IN SOA ns-1578.awsdns-05.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

在下列範例中，對於未建立且 DNSSEC 未開啟的 DNS 記錄，dig 輸出顯示 NXDOMAIN：

$ dig example.amazon.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>>
    example.amazon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64351
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; AUTHORITY SECTION:
amazon.com. 24 IN SOA dns-external-master.amazon.com. root.amazon.com. 2010158906 180 60 3024000 60

NXDOMAIN 或 NOERROR (無答案) 回應

檢查您的 DNS 公有託管區域，以確認是否已正確設定 DNS 記錄。

SERVFAIL 狀態

-或-

無法連接至 DNS 解析程式或伺服器

如果您對 Java 應用程式使用 Amazon EC2 執行個體，則網路中斷很少見，但也有可能發生。dig 或 nslookup 回應顯示您重複無法連接至 DNS 解析程式或伺服器。在這種情況下，請檢查 AWS 區域是否有任何作用中的網路中斷。

如果您使用內部部署伺服器以透過 Route 53 解析程式端點連接至 Route 53 私有託管區域，請檢查 VPC 上的端點組態。檢閱安全群組、網路存取控制清單 (網路 ACL) 和路由表的設定。如需指示，請參閱如何對網際網路的 Amazon EC2 執行個體連線逾時錯誤進行疑難排解？

在此範例中，輸出具有 SERVFAIL 狀態：

$ dig servfail.example.com

;; ->>HEADER<<- opcode: QUERY, <b>status: SERVFAIL</b>, id: 57632
;; flags: qr rd ra;
    QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

檢查私有託管區域和解析程式規則是否與來源 VPC 關聯

Amazon 提供的 DNS 解析程式會依下列優先順序評估最具體的相符項目：

1. 解析程式規則
2. 私有託管區域
3. 公有託管區域

如果 DNS 查詢與解析程式規則相符，請確認目標 IP 位址正在以正確的答案進行回覆。如果您使用的是私有託管區域，請確保在私有託管區域中建立 DNS 記錄。如果私有託管區域中不存在 DNS 記錄，則不會回復至公有託管區域並傳回 NXDOMAIN。

如需詳細資訊，請參閱解析 VPC 與網路之間的 DNS 查詢。

檢查子網域委派問題

確認在父區域、子區域和孫區域之間建立了正確的子網域委派。如果孫區域名稱伺服器 (NS) 存在於父區域中，但在子區域中遺失，則預期會出現間歇性 NXDOMAIN。每個子區域 NS 記錄都必須存在於父託管區域中。

避免間歇性 DNS 解析問題

以下是網域委派的範例：

• 父區域：example.com
• 子區域：today.example.com
• 孫區域：api.today.example.com

當孫區域 (api.today.example.com) NS 記錄存在於父區域 (example.com) 中時，確保它也存在於子區域 (today.example.com) 中。如需詳細資訊，請參閱如何測試我委派的子網域是否正確解析？

如果您間歇性地收到 UnknownHostException 錯誤，則 Amazon EC2 DNS 限制可能是一個因素。此限制為每個網路介面每秒 1,024 個封包，且此限制無法增加。Amazon 提供的 DNS 伺服器支援的每秒 DNS 查詢數會因查詢類型、回應大小和協定類型而異。如需詳細資訊，請參閱如何判斷我對 Amazon 提供的 DNS 伺服器的 DNS 查詢是否因為 VPC DNS 限流而失敗？

---