[트러블 슈팅] Java 21 업그레이드 후 Eureka DNS 해석 실패

💬Rush Deal 선착순 타임딜 프로젝트 진행 중,
API Gateway를 통해 User Service를 호출하는 과정에서 네트워크 에러가 발생했다.

 

1. 프로젝트 상황 및 초기 목표

Framework: Spring Boot 3.5.8 / Spring Cloud 2025.0.0

Language: Java 21 (Temurin)

OS: Windows 11 (WSL2)

Discovery: Netflix Eureka

 

User Service를 띄우고 Gateway를 통해 요청을 하자 다음과 같은 에러 로그가 발생했다.

 

io.netty.resolver.dns.DnsResolveContext$SearchDomainUnknownHostException:
Failed to resolve 'DESKTOP-UO2KEQG.mshome.net' [A(1)] after 2 queries
at io.netty.resolver.dns.DnsResolveContext.finishResolve(DnsResolveContext.java:1150)
...

---

2. 원인 분석

2-1. 에러 로그 및 도메인 분석

에러 메시지를 자세히 보니 "DESKTOP-UO2KEQG.mshome.net"이라는 도메인을 찾을 수 없다는 내용이었다.

DESKTOP-UO2KEQG: 내 개발 PC의 호스트네임이고,

.mshome.net: Windows WSL가 자동으로 부여하는 내부 DNS Suffix 이다.

 

Gateway가 Eureka로부터 서비스 주소를 받아와 연결을 시도하는 과정에서,  

로컬 가상 네트워크에서만 유효한 .mshome.net 도메인을 공인 DNS처럼 해석하려다 실패한 것이다.

 

처음에는 application.yml 설정 문제라고 생각해 설정을 점검했지만, 별다른 이상이 없었다.  
이후 구글링을 하던 중 문득 의문이 들었다.  
“동일한 MSA 환경에서 개발했던 이전 물류 프로젝트에서는 이런 문제가 없었는데, 왜 이번에는 발생하지?”  
그때 ‘Java 버전이 다르구나’라는 사실이 떠올랐다.  

(이전 프로젝트는 Java 17, 현재 프로젝트는 Java 21을 사용 중이다)

 

2-2. 상세 원인

혹시나 하는 마음에 OpenJDK 공식 문서를 찾아보던 중, 결정적인 단서를 하나 발견했다

Java 18에 도입되어 Java 21에서 기본 사용으로 굳어진 JEP 418 스펙이 문제의 원인이었던 것이다. 해당 문서에는 InetAddress 클래스의 동작 방식 변경이 명시되어 있다.

 

핵심 변경 사항

"By default, InetAddress uses the operating system's native resolver to perform lookups."

(기본적으로 InetAddress는 룩업을 수행하기 위해 운영체제의 네이티브 리졸버를 사용합니다.)

 

이 변경 때문에, 동일한 OS 환경에서도 Java 버전에 따라 반환되는 호스트네임 형식이 달라지게 되었다.

Java 17 이하에서는 JVM이 OS 정보를 일정 부분 필터링해 단순 호스트네임만 사용하는 반면, Java 21에서는 OS 네이티브 리졸버를 그대로 신뢰해 FQDN 형태를 사용하는 식이다.​

 

Java 버전	호스트네임 해석 방식	반환 값 예시
Java 17 이하	JVM이 OS 설정을 정제	`DESKTOP-UO2KEQG`
Java 21	OS 네이티브 리졸버 직접 사용	`DESKTOP-UO2KEQG.mshome.net`

 

Windows 환경에서는 네트워크 인터페이스 이름이 DESKTOP-XXX.mshome.net 형태로 정의되는데, Java 21이 이 값을 "진짜 주소"로 인식하여 Eureka 서버에 등록하면서 문제가 발생한 것이다.

 

문제 발생 메커니즘

1. 서비스 등록: User Service(Java 21)가 구동되며 OS가 알려주는 자신의 주소(...mshome.net)를 Eureka에 그대로 등록.
2. 서비스 발견: API Gateway가 Eureka에서 이 주소를 가져옴.
3. DNS 조회 실패: Gateway가 해당 도메인을 찾으려 하지만, .mshome.net은 공인 도메인이 아니므로 DNS 서버에서 찾을 수 없음.

---

3. 고려했던 해결책들

Java 버전 다운그레이드 (Java 21 → 17)

❌ 기각: 이번 프로젝트는 타임딜 서비스 특성상 순간적인 고트래픽 처리가 중요하고, 이를 위해 Java 21의 Virtual Thread 기능을 포기할 수 없기에 현실적으로 선택하기 어려운 옵션이다.

 

JVM 옵션으로 Hostname 강제 지정

❌ 기각: -Deureka.instance.hostname=localhost처럼 하드코딩할 수는 있지만, Dev/Prod 등 배포 환경이 바뀔 때마다 스크립트를 수정해야 해 유지보수성이 떨어진다고 판단

 

최종 선택: Eureka에서 IP 우선 사용

✅ 채택: 결국 Eureka 설정을 통해 “호스트네임 대신 IP 기반으로 등록·통신하도록 만드는 방식”이 가장 깔끔하면서도 클라우드 환경에도 잘 맞는 해법이라고 보았다.

# application.yml (User Service)
eureka:
  instance:
    prefer-ip-address: true  # 핵심: Hostname 대신 IP 주소로 Eureka에 등록

이 설정을 적용한 뒤 Eureka Dashboard를 확인해 보니, 서비스가 IP 기반으로 정상 등록되었고 Gateway와의 통신도 문제없이 동작했다.

---

4. 결론

이번 트러블슈팅을 통해 Java 버전 업그레이드가 단순한 문법 개선이나 성능 향상을 넘어, Network와 I/O 같은 내부 동작 방식까지 근본적으로 변경될 수 있다는 사실을 뼈저리게 체감했다.

 

기존에 안정적으로 동작하던 코드가 JEP 418 같은 스펙 변경으로 인해 예상치 못한 Side Effect를 일으킬 수 있음을 알게 되었다.

 

앞으로 새로운 기술 스택이나 버전 도입 시, OpenJDK JEP 문서와 Release Notes를 통해 OS/네트워크 레벨에서의 잠재적 영향을 미리 검토하는 습관을 들이는 것이 필수적이다.

---

5. 참고

• https://openjdk.org/jeps/418
• https://docs.spring.io/spring-cloud-netflix/docs/current/reference/html/