핑

핑은 웹사이트, 서버 또는 포트에 연결할 수 있는지 확인하고 응답 시간, 상태 코드 또는 오류를 알려 주는 무료 도구입니다.

핑 검사는 실제로 무엇을 확인하나요?

핑 검사는 검사가 실행되는 네트워크에서 원격 시스템이 응답하는지 확인합니다. 구체적인 검사 방식은 선택한 프로토콜에 따라 달라집니다.

• HTTP(s)는 HTTP 또는 HTTPS로 웹 URL을 확인합니다. HTTP 응답 상태 코드를 반환할 수 있어 웹사이트, API, 웹 서비스 검사에 적합합니다.
• 핑(ICMP)은 호스트가 인터넷 제어 메시지 프로토콜의 에코 트래픽에 응답하는지 확인합니다. 네트워크에서 일반적으로 말하는 "핑"이 바로 이 방식입니다.
• 호스트/포트는 호스트의 특정 네트워크 포트에 연결할 수 있는지 확인합니다. SMTP 메일 서버, POP 서버, 데이터베이스 엔드포인트 등을 검사할 때 주로 사용합니다.

각 검사가 확인하는 내용은 조금씩 다릅니다. ICMP 응답이 있다는 것은 호스트가 해당 유형의 네트워크 트래픽을 받아 응답한다는 뜻이지만, 웹사이트나 메일 서비스가 정상 작동한다는 의미는 아닙니다. HTTP 응답에서는 상태 코드를 확인할 수 있으며, 이 코드가 문제를 나타내기도 합니다. 포트 검사가 성공해도 해당 포트에 연결할 수 있다는 뜻일 뿐, 애플리케이션 로그인이나 데이터베이스 쿼리까지 성공한다고 보장하지는 않습니다.

핑 도구는 어떻게 사용하나요?

알맞은 핑 프로토콜을 선택하고 해당 주소를 입력한 다음 검사를 실행하세요. 선택한 프로토콜에 맞는 형식으로 입력해야 합니다.

1. 웹사이트, API 엔드포인트 또는 웹 서비스를 진단하려면 HTTP(s)를 선택하고 https://www.example.com/status처럼 완전한 URL을 입력하세요.
2. 서버가 ICMP 트래픽에 응답하는지 확인하려면 핑(ICMP)을 선택하고 server.example.com 같은 호스트 또는 IP 주소를 입력하세요.
3. 호스트/포트를 선택하고 호스트를 입력한 다음, 숫자로 된 포트를 지정하세요. 예를 들어 SMTP 제출 서비스는 일반적으로 587번 포트를 사용하고, HTTPS는 보통 443번 포트를 사용합니다.

호스트만 검사할 때는 URL 경로를 추가하지 마세요. 반대로 문제가 도메인 전체가 아니라 특정 API 경로나 페이지에만 발생한다면 HTTP 검사에 전체 경로가 필요할 수 있습니다. 전송 계층의 포트 번호는 0부터 65535까지의 16비트 값을 사용합니다. 0번 포트는 예약되어 있으며 일반적으로 서비스 포트로 사용하지 않습니다. 공백, 쉼표, "port 443" 같은 표기는 포트 번호에 포함되지 않습니다.

핑 검사는 서버에서 실행됩니다. 입력한 핑 정보는 HTTPS를 통해 해당 서버로 전송되며 저장되지 않습니다. URL에 비밀번호, API 키 또는 기타 비밀 정보를 넣지 마세요. URL을 통해 원격 서비스뿐 아니라 일반적인 웹 인프라의 다른 영역에도 해당 정보가 노출될 수 있습니다.

핑 결과는 어떻게 해석하나요?

먼저 연결 가능 여부를 확인한 다음, 응답 시간과 HTTP 상태 또는 오류 결과를 바탕으로 문제의 범위를 좁혀 보세요.

예를 들어 가상의 HTTP 결과에 온라인, 응답 시간 180 ms, 상태 코드 200이 표시될 수 있습니다. 상태 코드 200은 요청이 성공했다는 뜻입니다. 404 응답은 원본 서버가 대상 리소스의 현재 표현을 찾지 못했거나, 해당 리소스가 존재한다는 사실을 공개하지 않으려 한다는 의미입니다. 5xx(서버 오류) 응답은 서버 오류 범주에 속하며, 정확한 원인은 개별 상태 코드에 따라 다릅니다.

오프라인 결과가 나왔다고 해서 장비 전체가 항상 오프라인인 것은 아닙니다. 방화벽이 ICMP를 차단해도 HTTPS는 계속 작동할 수 있고, 한 포트가 닫혀 있어도 다른 서비스는 이용 가능할 수 있습니다. 사용자가 접속하려는 서비스에 맞는 검사를 실행하세요.

핑으로 확인할 수 있는 일반적인 문제

웹사이트가 열리지 않는다면 먼저 HTTP(s)를 선택하고 문제가 발생한 정확한 URL을 입력하세요. 도메인은 응답하지만 특정 페이지에서 404가 반환된다면 경로, 재작성 규칙 또는 배포 상태를 확인하세요. 브라우저에서 HTTPS 인증서 경고가 표시되면 핑 결과에만 의존하지 말고 SSL 조회에서 인증서 세부 정보를 확인하세요. HTTP 헤더 조회를 사용하면 리디렉션과 응답 헤더도 확인할 수 있습니다.

이메일이 도착하지 않는다면 호스트/포트를 선택하고 메일 서버의 호스트 이름과 송수신 애플리케이션에 설정된 포트를 입력하세요. SMTP 포트에 연결할 수 있다고 해서 서버가 특정 메시지를 수락한다는 의미는 아닙니다. 인증 실패, 스팸 필터링, DNS 메일 레코드, 수신자 정책은 기본적인 포트 검사로 확인할 수 있는 범위를 벗어납니다.

사이트를 새 호스트로 이전한 뒤에는 상황에 따라 ICMP 또는 HTTP로 호스트 이름을 확인하세요. DNS 레코드를 검증하고 캐시된 응답이 남아 있을 수 있다는 점도 고려해야 합니다. Whois 조회는 도메인 등록 정보를 확인하는 데 도움이 될 수 있지만, 현재 모든 리졸버가 어떤 DNS 응답을 보유하고 있는지는 보여 주지 않습니다.

DNS 캐시 때문에 올바른 결과가 잘못된 것처럼 보이는 이유는 무엇인가요?

DNS 캐시로 인해 한동안 도구의 서버와 사용자의 기기가 같은 호스트 이름을 서로 다른 주소로 해석할 수 있습니다. 재귀 리졸버는 TTL이라고도 하는 유효 시간에 따라 DNS 응답을 보관하며, 일부 애플리케이션과 운영체제도 로컬 캐시를 유지합니다.

이러한 지연을 흔히 "전파"라고 부르지만, DNS 레코드가 하나의 통합된 절차를 거쳐 모든 곳으로 퍼지는 것은 아닙니다. 각 캐시는 저마다의 일정에 따라 만료됩니다. 따라서 최근 변경한 레코드가 한 연결에서는 작동하지만 다른 연결에서는 여전히 이전 주소를 사용할 수 있습니다.

이 도구는 서버에서 검사를 실행하므로, 결과에는 검사 시점에 해당 서버가 사용하는 네트워크 경로와 DNS 조회 결과가 반영됩니다. 국내의 모든 인터넷 사업자, 이동통신망 또는 기업용 리졸버가 같은 목적지를 보고 있다고 입증할 수는 없습니다. 위치에 따라 동작이 달라지는 문제가 중요하다면 로컬 검사 결과와 비교하고 관련 DNS 레코드를 조회하세요.

자주 묻는 질문

악센트 문자나 비라틴 문자가 들어간 도메인 이름도 검사할 수 있나요?

IDNA는 변환 가능한 유니코드 도메인 레이블을 ASCII A-레이블로 바꿉니다. 퓨니코드는 관련 A-레이블 내부에서 사용하는 인코딩 알고리즘입니다. 브라우저는 읽기 쉬운 표기를 자동으로 변환하는 경우가 많지만, 호스트 입력란이나 진단 시스템에서는 A-레이블 형식을 요구할 수 있습니다. 겉보기에 비슷한 유니코드 문자가 서로 다른 도메인을 가리킬 수 있으므로 철자를 주의 깊게 확인하세요.

응답 시간이 낮으면 계속 낮게 유지되나요?

아닙니다. 응답 시간은 라우팅, 네트워크 혼잡, 서버 부하, 물리적 거리에 따라 달라집니다. 비슷한 시간대에 여러 번 검사한 결과를 기록하고, 한 번 느리게 응답했다는 이유만으로 장애라고 판단하지 말고 지속적인 변화를 조사하세요.

DNS, 방화벽 또는 서버 설정을 변경하기 전에 문제가 발생한 서비스에서 실제로 사용하는 호스트 이름, URL 경로, 포트를 정확히 검사했는지 확인하세요. 결과가 나온 시간을 기록하고 로컬 로그와 비교하면 연결 양쪽의 기록을 서로 대조할 수 있습니다.