Bad Request: This combination of host and port requires TLS

Bad Request: This combination of host and port requires TLS가 표시되면 TLS가 필요한 포트로 평문 HTTP 요청을 보냈는지 먼저 확인합니다. Apache Tomcat은 TLS가 필요한 연결에 TLS 없이 접속한 클라이언트에 이 문구를 포함한 HTTP 400 응답을 보내며, Elasticsearch의 HTTPS REST API 포트를 http://로 호출했을 때도 같은 문제가 발생할 수 있습니다.

이 오류는 사용자 이름이나 비밀번호가 틀렸다는 뜻이 아닙니다. TLS 연결이 시작되기 전에 요청 방식이 맞지 않아 반환된 결과이므로 주소의 스킴, 포트, HTTP 계층 TLS 설정을 먼저 비교합니다.

이 문서가 맞는 조건

다음 조건이 함께 확인될 때 이 문서를 사용합니다.

• 응답 본문에 Bad Request와 This combination of host and port requires TLS가 표시됩니다.
• 응답 상태가 HTTP 400이고 오류 원문이 일치합니다.
• 브라우저, API 클라이언트 또는 서버 간 요청 주소가 http://로 시작합니다.
• 요청한 포트는 Tomcat, Elasticsearch 또는 앞단 프록시에서 TLS를 요구합니다.

브라우저의 NET::ERR_CERT_*, Java의 PKIX path building failed, Node.js의 self signed certificate는 HTTPS 연결을 시작한 뒤 인증서를 신뢰하지 못한 문제입니다. 같은 TLS 범주이지만 확인 순서가 다릅니다.

먼저 응답 서버와 TLS 위치를 구분합니다

오류 문구만으로 애플리케이션이 Spring Boot인지 Elasticsearch인지 확정할 수 없습니다. 브라우저 개발자 도구, 클라이언트 설정, 프록시·애플리케이션 로그와 배포 설정을 함께 확인합니다.

X-Forwarded-Proto 같은 전달 헤더만 고쳐도 평문 연결이 TLS 연결로 바뀌지는 않습니다. 실제로 서버에 접속하는 URL과 포트를 먼저 맞춰야 합니다.

접속 주소와 포트를 확인합니다

먼저 브라우저 주소, 애플리케이션 환경변수, API 클라이언트 설정 또는 프록시 upstream에서 실제 접속 주소를 확인합니다.

잘못된 예: http://localhost:8443확인할 예: https://localhost:8443

localhost와 8443은 예시입니다. 실제 운영 환경에서는 서버가 TLS 연결을 받도록 설정한 호스트와 포트를 사용해야 합니다. 포트 번호만 보고 HTTP 또는 HTTPS를 추정하지 않습니다.

평문 요청 결과를 확인할 때는 응답 코드와 오류 원문만 기록합니다. 다음 명령에 실제 인증 정보를 넣지 않습니다.

curl --verbose http://localhost:8443/

같은 포트가 TLS를 요구하고 위 오류가 재현된다면 주소를 HTTPS로 바꾸고 인증서를 정상 검증하는 단계로 이동합니다.

Spring Boot와 Tomcat을 확인합니다

Spring Boot는 server.ssl.* 속성으로 내장 웹 서버의 SSL을 설정할 수 있습니다. 공식 문서의 예시처럼 HTTPS 커넥터를 설정하면 같은 설정만으로 평문 HTTP 커넥터가 함께 열리는 것은 아닙니다.

server.port=8443server.ssl.key-store=classpath:keystore.jksserver.ssl.key-store-password=${KEY_STORE_PASSWORD}

다음 순서로 확인합니다.

1. 실행 중인 애플리케이션의 server.port와 server.ssl.* 적용값을 확인합니다.
2. 브라우저나 API 클라이언트가 그 포트를 https://로 호출하는지 확인합니다.
3. Nginx, Apache HTTP Server, 로드 밸런서가 앞에 있다면 프록시에서 TLS를 끝내는지 확인합니다.
4. 프록시가 원본 Tomcat에도 HTTPS로 연결하도록 구성했으면 upstream 주소도 https://인지 확인합니다.
5. 같은 요청을 HTTPS로 다시 보내고 인증서 오류나 애플리케이션 응답으로 단계가 바뀌는지 확인합니다.

HTTP와 HTTPS를 모두 제공해야 한다면 Spring Boot 공식 문서가 설명하는 별도 커넥터 구성이 필요합니다. 오류를 숨기기 위해 기존 HTTPS 커넥터의 TLS를 끄지 않습니다.

Elasticsearch를 확인합니다

Elasticsearch는 노드 간 통신에 사용하는 transport TLS와 REST 클라이언트가 사용하는 HTTP TLS를 구분합니다. 이 오류에서는 HTTP 계층 설정을 확인해야 합니다.

xpack.security.http.ssl.enabled: true

Elasticsearch 8을 처음 시작할 때 보안 자동 구성이 적용되면 HTTP 계층 TLS 인증서와 CA 인증서가 생성될 수 있습니다. Elastic 공식 문서는 자체 관리 환경의 HTTP CA 인증서 위치 예시로 다음 경로를 안내합니다.

/etc/elasticsearch/certs/http_ca.crt

설치 방식과 설정 디렉터리에 따라 실제 경로는 다를 수 있습니다. 경로를 추정하지 말고 Elasticsearch 시작 로그와 현재 설정을 확인합니다.

HTTPS와 CA 인증서를 함께 설정합니다

주소만 https://로 바꾸면 다음 단계에서 인증서 신뢰 오류가 발생할 수 있습니다. 이때 검증을 끄지 말고 Elasticsearch HTTP 인증서를 서명한 CA를 클라이언트에 등록합니다.

curl로 확인하는 예시는 다음과 같습니다.

curl --cacert /etc/elasticsearch/certs/http_ca.crt \  https://localhost:9200/

인증이 설정된 Elasticsearch라면 CA 신뢰가 성공한 뒤 401 Unauthorized가 반환될 수 있습니다. 이는 TLS 연결이 실패한 것이 아니라 다음 인증 단계가 필요하다는 뜻입니다. 사용자 이름·비밀번호나 API Key는 환경변수 또는 사용하는 클라이언트의 보안 설정으로 전달하고 명령 기록에 남기지 않습니다.

애플리케이션에서는 다음 세 값을 함께 확인합니다.

Docker Compose, Spring Boot의 Elasticsearch 클라이언트, Node.js 클라이언트처럼 설정 위치가 다른 환경에서도 판정 기준은 같습니다. 컨테이너 내부에서 CA 파일을 읽을 수 있는지와 애플리케이션에 전달된 실제 URL을 확인합니다.

수정 후 재확인

1. 변경 전 사용한 스킴, 호스트와 포트를 기록합니다.
2. 응답 서버와 TLS가 끝나는 구간을 확인합니다.
3. 클라이언트 또는 프록시의 요청 주소를 해당 포트의 TLS 설정과 일치시킵니다.
4. 서버 인증서를 정상 검증하도록 신뢰 저장소나 CA를 설정합니다.
5. 같은 요청을 다시 보내 오류가 사라졌는지 확인합니다.
6. Elasticsearch에서 401이 나오면 TLS 문제와 인증 문제를 분리하고 필요한 인증 방식을 설정합니다.
7. 애플리케이션과 프록시 로그에서 오류 원문이 다시 발생하지 않는지 확인합니다.

하지 말아야 할 조치

인증서 검증을 끄면 연결 상대가 실제 서버인지 확인할 수 없습니다. curl -k, verify_certs: false, NODE_TLS_REJECT_UNAUTHORIZED=0을 운영 설정으로 남기지 않습니다. 오류를 없애기 위해 서버의 TLS를 끄거나 Tomcat·Elasticsearch 내부 포트를 외부에 공개하는 조치도 사용하지 않습니다.