DNS에서 앱까지 하나의 요청을 따라가세요.

예상 경로를 기록하세요

이 안내는 관리하는 Linux VPS, 작동하는 SSH 세션, 무해한 /healthz 엔드포인트가 있는 애플리케이션, 그리고 제어하는 도메인의 권한 있는 DNS 설정에 대한 접근을 가정합니다. 예제 앱은 다음에서 수신합니다: 127.0.0.1:3000; Caddy는 공용 역방향 프록시입니다. 앱이 다른 슈퍼바이저나 프록시를 사용하면 진단 순서를 유지하고 해당 문서를 사용하세요.

api.example.com 및 203.0.113.10 는 문서 자리 표시자이며 실제 서비스가 아닙니다. 자체 시스템에 대해 점검을 실행하기 전에 둘 다 교체하세요. 실제 호스트 이름, 의도한 IP 주소, 앱 포트 및 서비스 이름을 한 곳에 기록하세요. 구성 도구에서 VPS 호스트 이름을 설정해도 공용 DNS 레코드가 생성되지 않습니다.

DNS가 의도한 주소를 반환합니다.
연결이 의도한 서버와 포트에 도달합니다.
TLS가 요청된 호스트 이름을 인증합니다.
프록시가 요청을 올바른 업스트림으로 전달합니다.
애플리케이션이 예상 응답을 반환합니다.

두 주소 패밀리 모두 확인

VPS 외부 머신에서 게시하려는 레코드를 쿼리하세요. dig 는 BIND의 DNS 도구에 속하며 패키지 이름은 다양합니다. 이 명령은 답변 섹션을 요청하므로 레코드 유형, 주소 및 남은 캐시 수명을 볼 수 있습니다. 참조: BIND dig 참조.

dig api.example.com A +noall +answer
dig api.example.com AAAA +noall +answer

반환된 모든 주소를 의도한 대상과 비교하세요. 해당 주소에 대해 IPv6 라우팅, 수신 및 필터링이 작동할 때만 AAAA 레코드를 게시하세요. 오래된 AAAA 레코드는 일부 클라이언트를 A 레코드와 다른 곳으로 보낼 수 있습니다. 의도적으로 CDN 또는 DNS 프록시를 사용하는 경우 해당 주소가 올바를 수 있습니다. VPS가 반드시 나타나야 한다고 가정하지 말고 해당 추가 홉을 기록하세요.

빈 답변은 전체를 더 자세히 살펴봐야 합니다: dig 응답: 해당 유형의 레코드 없음, 존재하지 않는 이름 또는 확인 문제를 의미할 수 있습니다. 편집하기 전에 어떤 DNS 서비스가 권한 있는지 확인하세요. 이전 값과 TTL을 기록하고, 해당 위치에서 의도한 변경을 수행한 다음 기존 캐시가 만료된 후 새 결과를 비교하세요. 관련 없는 반복 편집은 타임라인을 이해하기 어렵게 만듭니다.

연결 실패와 인증서 실패 분리

서버 외부에서 작은 엔드포인트를 요청하세요. 애플리케이션이 HEAD를 구현한다고 가정하지 말고 GET을 사용하세요. Curl의 타임아웃 옵션은 점검을 제한하며, 상세 출력은 연결 및 TLS 진행 상황을 보여줍니다. Curl은 이러한 옵션과 인증서 검증을 문서화합니다.

curl --verbose --connect-timeout 5 --max-time 10 https://api.example.com/healthz

해석 오류는 DNS를 가리킵니다. 연결 거부는 연결이 적극적으로 거부되었음을 의미합니다. 타임아웃은 라우팅 또는 필터링과 관련될 수 있으며 어떤 방화벽이 원인인지 식별하지 않습니다. 인증서 오류는 예상된 보안 연결이 설정되지 않았음을 의미합니다. 인증서 검사를 비활성화하는 것을 영구 수정으로 삼지 마세요.

TLS 요청에서 호스트 이름을 유지하면서 특정 오리진을 비교하려면 curl의 주소 재정의를 사용하세요:

curl --verbose --connect-timeout 5 --max-time 10 --resolve api.example.com:443:203.0.113.10 https://api.example.com/healthz

일반 요청은 실패하는데 이 요청이 성공한다면 DNS와 중간 매개체를 비교하십시오. 이 재정의는 DNS를 편집하지 않습니다. A와 AAAA 레코드가 모두 존재하는 경우, 해당 네트워크를 실제로 지원하는 클라이언트에서 일반 요청을 반복하십시오. --ipv4 및 --ipv6 해당 네트워크를 실제로 지원하는 클라이언트에서.

연결의 서버 측 검사

VPS에서 수신 대기 중인 TCP 소켓을 확인하고 앱에 직접 질의하십시오:

sudo ss -ltnp
curl --silent --show-error --max-time 5 http://127.0.0.1:3000/healthz

ss 리스너와, 충분한 권한이 있는 경우 해당 프로세스를 보여줍니다. 루프백 리스너는 로컬에서 도달할 수 있으며, 그 존재만으로는 외부 접근에 대해 아무것도 알려주지 않습니다. 다음을 참조하십시오: 업스트림 ss 매뉴얼. 직접 앱 요청이 실패하면 다음으로 이동하십시오: 프로세스 진단 가이드 DNS를 변경하기 전에.

이 단일 앱 구성에서 관련 Caddyfile 블록은 다음과 같습니다:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

호스트 이름과 업스트림은 애플리케이션과 일치해야 합니다. Caddy의 reverse proxy 지시문 은 요청을 구성된 업스트림으로 전달합니다. 여기에 임의의 도메인을 넣는다고 해서 그 도메인을 제어할 수 있는 것은 아닙니다. 편집하기 전에 기존 구성을 보존하십시오. 패키지된 서비스와 이 파일 경로를 사용하는 경우 먼저 검증한 다음 검증이 성공한 후에만 다시 로드하십시오:

sudo caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
sudo systemctl reload caddy

명령의 목적은 다릅니다: 검증은 구성 로딩을 확인하고, 다시 로드는 변경 사항을 적용합니다. 설치된 서비스의 실제 파일 경로와 권한을 확인하십시오. Caddy의 명령 참조 에서 검증 및 다시 로드 동작을 설명합니다.

전체 경로를 확인한 다음 증거를 보관하세요

일반적인 공용 인증서 자동화를 위해 Caddy는 올바른 DNS, 외부에서 도달 가능한 챌린지 포트, 리스너를 바인딩할 권한, 영구적으로 쓰기 가능한 인증서 저장소가 필요합니다. HTTP 및 TLS-ALPN 챌린지는 각각 포트 80와 443을 사용하며, DNS 챌린지는 별도의 설정입니다. 참조: Caddy의 HTTPS 전제 조건. 방화벽 규칙을 검토할 때 관리 액세스를 유지하십시오.

예시 결과: 로컬 엔드포인트는 다음을 반환하고 {"status":"ok"}, 외부 HTTPS 요청은 동일한 작은 본문을 반환하며 curl은 성공적인 인증서 검증을 보고합니다. 이는 이 예시에 대한 예상 관찰이며 OffVPS 서버에서 기록된 결과가 아닙니다. 또한 하나의 일반 애플리케이션 작업을 실행해 보십시오: 얕은 상태 확인 엔드포인트는 통과하지만 데이터베이스에 의존하는 경로는 실패할 수 있습니다.

요청 시간, 호스트 이름, 주소 패밀리 및 첫 번째 실패 계층을 기록하십시오. 그 간략한 정보가 "도메인이 고장났다"보다 더 유용합니다. 경로가 작동하면 다음을 사용하십시오: 반복 가능한 릴리스 가이드 를 통해 동일한 검사를 모든 배포의 일부로 만드십시오.

사용된 문서

이 페이지의 기본 참조. 자체 환경에 설치된 버전의 문서를 확인하세요.