IP로는 작동하지만 도메인으로는 작동하지 않는 원격 앱 문제 해결 방법

앱이 IP로는 작동하지만 도메인으로는 작동하지 않는다면 서버에는 연결할 수 있으며, 문제는 대개 DNS, 호스트 이름 기반 라우팅, TLS 또는 리디렉션에 있습니다.

IP를 통한 원격 액세스가 가능하다는 것은 일부 네트워크 경로가 홈 서버에 도달한다는 뜻이지만, 도메인 요청에는 DNS, TLS 서버 이름, HTTP Host 헤더, 애플리케이션에 구성된 공개 URL을 통한 추가 식별 정보가 포함됩니다. 가장 빠른 진단 방법은 리버스 프록시, 인증서, DNS 레코드를 동시에 변경하는 대신 동일한 클라이언트, 포트, 서버를 유지하면서 각 식별 계층을 순서대로 확인하는 것입니다.

IP 테스트가 의도한 서비스에 도달하는지 확인

원격에서 정상 작동하는 정확한 IP 주소, 포트, 프로토콜 및 응답을 기록합니다. IP로 접속했을 때 실제 애플리케이션, 리버스 프록시의 기본 페이지, 라우터 로그인 화면 또는 동일한 공인 주소를 공유하는 다른 서비스가 열리는지 확인합니다.

홈랩 리버스 프록시 안내에서는 프록시가 요청된 Host 헤더를 확인한 후 업스트림 서비스를 선택하기 때문에 하나의 주소에서 여러 앱을 호스팅할 수 있다고 설명합니다.

IP로 기본 사이트에만 연결된다면 프록시에 연결할 수 있다는 것은 입증되지만 대상 앱의 라우팅이 작동한다는 뜻은 아닙니다. 이후 테스트에서 올바른 가상 호스트를 식별할 수 있도록 페이지 제목이나 헤더와 같은 알려진 응답 표식을 하나 정해 두세요.

공개 DNS와 정상 작동하는 IP 주소 비교

권한 있는 네임서버와 하나 이상의 외부 재귀 리졸버를 통해 도메인을 조회합니다. 모든 A 및 AAAA 응답, TTL, CNAME이 다른 호스트 이름을 가리키는지 여부를 기록합니다.

셀프 호스팅 안내에 따르면 캐시된 응답은 이전 TTL이 만료될 때까지 남아 있을 수 있으므로, 권한 있는 레코드를 수정한 후에도 최근 변경 사항으로 인해 일부 클라이언트가 이전 DNS 대상을 계속 사용할 수 있습니다.

A 레코드가 정상 작동하는 IP와 다르면 레코드 또는 DDNS 업데이트 프로그램을 수정합니다. A 레코드는 올바르지만 AAAA가 연결할 수 없는 IPv6 경로를 가리킨다면 주소 체계별로 따로 테스트하고, 문제가 있는 레코드를 삭제하거나 수정합니다.

도메인은 유지한 채 정상 작동하는 IP에 연결

정상 작동하는 IP에 연결하면서 HTTP Host 헤더와 TLS 서버 이름에는 도메인을 전송할 수 있는 클라이언트를 사용합니다. 이렇게 하면 프록시와 인증서가 요구하는 식별 정보는 유지한 채 대상 주소만 변경할 수 있습니다.

Server Fault에서는 HTTP 리버스 프록시가 이름 기반 가상 호스트와 같은 방식으로 Host 헤더를 사용해 라우트를 선택할 수 있다고 설명합니다.

도메인 정보를 유지한 요청이 작동한다면 실패한 계층은 DNS입니다. 프록시에는 도달하지만 잘못된 사이트나 404가 반환된다면 가상 호스트 일치와 라우트 우선순위를 확인하고, HTTP 요청 전에 TLS가 실패한다면 SNI와 인증서 선택을 확인합니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

TLS SNI 및 인증서 식별 정보 확인

도메인으로 반환되는 인증서와 IP 주소로 반환되는 인증서를 비교합니다. 주체 이름, 발급자, 만료일 및 프록시가 기본 인증서를 제공하는지 여부를 기록합니다.

SNI는 암호화된 HTTP 요청보다 먼저 TLS ClientHello에 호스트 이름을 포함하므로 프록시가 보안 가상 호스트를 선택할 수 있게 합니다. 따라서 IP만 사용하는 요청은 동일한 리스너에 도달하더라도 TLS 선택 과정에서 사용되는 호스트 이름이 없을 수 있습니다.

개인 IP 또는 동적 IP용 인증서가 사용될 것이라고 기대하지 말고 도메인 인증서와 SNI 라우트를 수정합니다. CDN 또는 TCP 프록시가 앞단에 있다면 의도한 호스트 이름에 대한 SNI를 전달하거나 종료하는지 확인합니다.

내부 DNS와 외부 DNS가 서로 다른 경로로 보내지 않는지 확인

모바일 데이터, 공용 리졸버, 홈 LAN에서 도메인 조회 결과를 비교합니다. 분할 DNS는 집에서는 사설 프록시 주소를, 원격에서는 공용 주소를 의도적으로 반환할 수 있지만, 두 응답 모두 동일한 논리적 호스트 이름 라우트에 도달해야 합니다.

Level1Techs의 홈랩 토론에서는 공용 DNS와 홈 라우팅이 서로 다른 내부 및 외부 경로를 사용하는 경우 로컬 리버스 프록시 액세스에 자체 DNS 설계가 필요할 수 있음을 보여 줍니다.

하나의 리졸버에서만 잘못된 주소가 반환된다면 해당 DNS 뷰를 수정합니다. 공용 주소에는 IP로 연결되지만 모든 환경에서 도메인으로는 실패한다면 분할 DNS보다는 Host, SNI, 인증서 및 애플리케이션 식별 정보에 집중합니다.

DNS가 해결되었다고 판단하기 전에 표준 URL과 리디렉션 확인

도메인이 앱에 도달한 후 발생하는 모든 리디렉션을 확인합니다. 리버스 프록시 또는 애플리케이션이 클라이언트를 내부 호스트 이름, 이전 도메인, 잘못된 스킴, 사설 포트 또는 오래된 콜백 URL로 보낼 수 있습니다.

ZimaSpace의 분할 DNS로 집 안에서만 발생하는 오류를 해결할 수 있는지에 관한 글에서는 호스트 이름은 올바르지만 위치에 따라 경로가 달라지는 인접 사례를 다룹니다.

권한 있는 DNS가 의도한 주소를 반환하고, 도메인이 올바른 인증서와 프록시 라우트를 선택하며, 리디렉션이 공용 호스트 이름을 유지하고, IP로 대체하지 않은 전체 원격 작업 흐름이 성공해야 문제가 해결된 것입니다.