리눅스 서버 접속 확인할 때 curl과 nc 차이, 포트와 HTTP 응답을 구분하는 법

리눅스 서버 접속 확인할 때 curl과 nc 차이를 이해하고 TCP 포트 연결, HTTP 응답, 서버 내부 LISTEN 상태, 서비스 상태와 로그를 순서대로 점검하는 방법을 설명하는 대표 이미지

 

리눅스 서버에서 접속 문제가 생기면 curl과 nc 명령어를 자주 사용합니다.

 

curl -I http://example.com
nc -vz -w 3 example.com 80

 

처음 보면 둘 다 “접속 확인 명령어”처럼 보입니다.

하지만 실제 운영에서는 확인하는 범위가 다릅니다.

nc는 특정 TCP 포트까지 연결이 가능한지 확인하는 데 좋고, curl은 HTTP 또는 HTTPS 요청을 보내서 실제 응답 코드까지 확인하는 데 좋습니다.

즉, nc는 포트까지 문이 열려 있는지 보는 명령이고, curl은 문 안쪽에서 서비스가 어떤 응답을 주는지 확인하는 명령에 가깝습니다.

이번 글에서는 리눅스 서버 접속 장애 상황에서 curl과 nc가 무엇을 다르게 확인하는지, 그리고 어떤 순서로 함께 사용하면 좋은지 정리합니다.

먼저 결론부터 보면

초보 운영자 기준으로는 이렇게 기억하면 됩니다.

nc
→ TCP 포트 연결 확인

curl
→ HTTP/HTTPS 응답 확인

 

예를 들어 웹 서버 접속이 안 된다고 할 때, 먼저 포트가 열려 있는지 볼 수 있습니다.

 

nc -vz -w 3 203.0.113.10 80

 

이 명령은 203.0.113.10 서버의 80번 포트로 TCP 연결이 되는지 확인합니다.

반면 curl은 실제 HTTP 요청을 보내고 응답을 봅니다.

 

curl -I http://203.0.113.10

 

이 명령은 서버가 HTTP 응답을 주는지, 응답 코드가 무엇인지 확인할 수 있습니다.

정리하면 이렇습니다.

nc 성공
→ 포트까지 연결은 가능

curl 성공
→ HTTP 응답까지 확인

nc 성공 + curl 실패
→ 포트는 열렸지만 HTTP 응답 또는 애플리케이션 문제 가능성

 

nc로 포트가 열렸는지 확인하는 기본 방법은 아래 글에서 먼저 정리했습니다.

https://opsnote.tistory.com/36

리눅스 서버 포트 열렸는지 nc로 확인할 때 ping만 보지 말고 TCP 접속까지 확인하는 법

 

가상의 운영 상황 예시

예를 들어 사용자가 웹 서비스 접속이 안 된다고 제보했다고 가정해보겠습니다.

[상황]
- 사용자가 웹페이지 접속 불가 제보
- 대상 서버 IP는 203.0.113.10
- 웹 서비스 포트는 80
- ping은 응답함
- nc로 80 포트 연결도 성공함
- 그런데 curl로는 500 오류가 발생함

 

이때 아래 결과만 보고 끝내면 안 됩니다.

 

nc -vz -w 3 203.0.113.10 80

 

결과가 성공으로 나올 수 있습니다.

Connection to 203.0.113.10 80 port [tcp/http] succeeded!

 

이 결과는 TCP 80 포트까지 연결이 된다는 뜻입니다.

하지만 HTTP 응답까지 정상이라는 뜻은 아닙니다.

이어서 curl을 확인합니다.

 

curl -I http://203.0.113.10

 

결과가 아래처럼 나올 수 있습니다.

HTTP/1.1 500 Internal Server Error

 

이 경우는 포트는 열려 있지만 애플리케이션 내부 오류가 발생하고 있을 가능성이 있습니다.

따라서 보고는 이렇게 해야 합니다.

대상 서버 80 포트 nc 연결은 성공했습니다.
다만 curl 기준 HTTP 500 응답이 확인되어 애플리케이션 로그를 추가 확인하겠습니다.

 

이렇게 쓰면 “접속 됩니다”보다 훨씬 정확합니다.

 

1단계. curl은 HTTP/HTTPS 응답을 확인합니다

curl은 실제 HTTP 또는 HTTPS 요청을 보내고 응답을 확인할 때 사용합니다.

HTTP 헤더만 보고 싶다면 -I 옵션을 씁니다.

 

curl -I http://203.0.113.10

 

도메인 기반 서비스라면 도메인으로 확인합니다.

 

curl -I https://example.com

 

응답 코드만 간단히 보고 싶다면 아래처럼 사용할 수 있습니다.

 

curl -o /dev/null -s -w "%{http_code}\n" https://example.com

 

응답 코드는 대략 이렇게 해석할 수 있습니다.

200
→ 일단 정상 응답 가능성

301 / 302
→ 리다이렉트

403
→ 권한 또는 접근 제한 가능성

404
→ 경로 또는 라우팅 문제 가능성

500
→ 애플리케이션 내부 오류 가능성

502
→ 프록시 또는 upstream 문제 가능성

503
→ backend 서비스 불가 가능성

504
→ 응답 지연 또는 timeout 가능성

 

curl은 단순히 포트가 열렸는지를 넘어서, 웹 서비스가 실제로 어떤 응답을 주는지 확인할 수 있습니다.

즉, 웹 서비스 확인에서는 nc보다 한 단계 더 안쪽을 보는 명령어입니다.

2단계. nc 성공 + curl 실패는 어떻게 볼까?

이 상황은 운영에서 자주 만납니다.

 

nc -vz -w 3 203.0.113.10 8080

 

nc는 성공합니다.

그런데 아래 명령은 실패합니다.

 

curl -I http://203.0.113.10:8080

 

이 경우는 “포트는 열려 있지만 HTTP 응답이 정상적이지 않다”라고 볼 수 있습니다.

가능성은 아래와 같습니다.

- 해당 포트가 HTTP 서비스가 아닐 수 있음
- HTTP가 아니라 HTTPS로 접근해야 할 수 있음
- Host 헤더가 필요한 서비스일 수 있음
- 애플리케이션 내부 오류가 발생 중일 수 있음
- 프록시나 upstream 연결이 실패할 수 있음
- 서비스는 떠 있지만 health check가 실패 중일 수 있음

 

예를 들어 HTTPS 서비스인데 HTTP로 요청하면 실패할 수 있습니다.

 

curl -I https://203.0.113.10:443

 

인증서 확인 때문에 테스트가 막히는 상황에서는 일시적으로 -k 옵션을 사용할 수도 있습니다.

 

curl -k -I https://203.0.113.10

 

다만 -k는 인증서 검증을 무시하는 옵션입니다.

운영에서는 아무 때나 쓰기보다 SSL 인증서 문제를 구분하기 위한 테스트 용도로만 사용하는 것이 좋습니다.

 

3단계. HTTP 서비스가 아니면 curl보다 nc가 먼저입니다

모든 서비스가 HTTP 응답을 주는 것은 아닙니다.

DB, Redis, MQ 같은 서비스는 HTTP 서비스가 아닙니다.

이런 포트에 curl을 실행하면 정상적인 HTTP 응답이 안 나오는 것이 당연합니다.

예를 들어 Redis 포트라면 아래처럼 포트 연결을 확인할 수 있습니다.

 

nc -vz -w 3 203.0.113.20 6379

 

MySQL 포트라면 아래처럼 볼 수 있습니다.

 

nc -vz -w 3 203.0.113.30 3306

 

Kafka 포트라면 아래처럼 확인할 수 있습니다.

 

nc -vz -w 3 203.0.113.40 9092

 

이런 서비스에 아래처럼 curl을 보내고 이상하다고 판단하면 안 됩니다.

 

curl -I http://203.0.113.30:3306

 

서비스 종류에 따라 확인 방법이 다릅니다.

HTTP / HTTPS 서비스
→ curl로 응답 확인

DB / Redis / MQ 같은 TCP 서비스
→ nc로 포트 연결 확인 후 서비스 전용 클라이언트 또는 로그 확인

 

즉, curl은 HTTP 계열 서비스에 강하고, nc는 TCP 포트 연결 확인에 넓게 사용할 수 있습니다.

4단계. 도메인과 IP 기준을 섞으면 헷갈립니다

테스트할 때 도메인과 IP 기준을 섞으면 결과가 달라질 수 있습니다.

예를 들어 아래 명령은 도메인 기준입니다.

 

curl -I https://example.com

 

그런데 아래 명령은 IP 기준입니다.

 

nc -vz -w 3 203.0.113.10 443

 

도메인이 실제로 다른 IP를 바라보고 있거나, 로드밸런서를 거치고 있다면 결과가 다르게 보일 수 있습니다.

먼저 DNS를 확인합니다.

 

nslookup example.com

 

또는 아래처럼 확인합니다.

 

dig example.com

 

확인 기준을 맞추는 것이 중요합니다.

도메인 기준 테스트
→ DNS, LB, WAF, 인증서, Host 기반 라우팅까지 포함될 수 있음

IP 기준 테스트
→ 특정 서버 또는 특정 경로만 확인할 수 있음

 

웹 서비스가 Host 헤더 기반으로 동작한다면 IP로 직접 접근했을 때 정상 응답이 나오지 않을 수도 있습니다.

그래서 결과를 볼 때는 항상 “어떤 대상에 대해 테스트했는지”를 같이 기록해야 합니다.

 

5단계. nc와 curl 결과를 함께 해석하는 방법

웹 서비스 접속 장애에서는 nc와 curl 결과를 조합해서 확인하는 것이 중요합니다.

nc 결과curl 결과판단

성공	HTTP 200	TCP 연결과 HTTP 응답 확인
성공	HTTP 500	애플리케이션 내부 오류 가능성
성공	HTTP 502	프록시 또는 upstream 문제 가능성
성공	HTTP 503	백엔드 서비스 불가 가능성
성공	HTTP 504	응답 지연 또는 타임아웃 가능성
성공	연결 실패	프로토콜, TLS, Host 설정 또는 HTTP 서비스 상태 확인
실패	실패	TCP 연결 경로, 방화벽, 대상 서비스 상태 확인

 

단, 두 명령어는 동일한 목적지 IP와 포트, 동일한 출발지 환경을 기준으로 비교해야 합니다.

도메인과 IP가 서로 다른 서버를 가리키거나, 로드밸런서를 거치는 경로가 다르면 결과를 직접 비교하기 어렵습니다.

또한 curl -I는 HEAD 요청이므로 HTTP 200 응답이 확인되더라도 로그인이나 실제 API 기능까지 정상이라는 뜻은 아닙니다.

핵심은 nc 성공을 서비스 정상으로 단정하지 않고, curl 응답을 통해 웹 서비스 상태를 한 단계 더 확인하는 것입니다.

6단계. 초보 운영자가 자주 하는 실수

curl과 nc를 사용할 때 자주 하는 실수는 아래입니다.

- nc 성공을 서비스 정상으로 판단
- curl 실패를 무조건 네트워크 문제로 판단
- HTTP가 아닌 서비스에 curl을 보내고 이상하다고 판단
- IP 기준 테스트와 도메인 기준 테스트를 섞어서 판단
- 내부 테스트와 외부 테스트를 구분하지 않음
- 실제 IP, 도메인, 고객사명을 외부 문서에 그대로 공유
- 포트 확인 후 로그 확인을 생략

 

특히 아래 판단은 조심해야 합니다.

nc 됩니다
→ 서비스 정상입니다

 

더 정확히는 이렇게 말해야 합니다.

대상 포트에 대한 TCP 연결은 확인되었습니다.
다만 실제 서비스 응답과 애플리케이션 로그는 추가 확인이 필요합니다.

 

운영에서는 이 문장 차이가 꽤 큽니다.

 

7단계. 실무 보고 예시

가상의 웹 서비스 점검 결과가 다음과 같다고 가정하겠습니다.

• 점검 위치: WAS 서버
• 대상: 203.0.113.10:80
• nc 결과: TCP 연결 성공
• curl 결과: HTTP 500 응답

이 경우에는 다음과 같이 보고할 수 있습니다.

대상 서버의 TCP 80 포트 연결은 정상 확인됐으나, 동일한 대상에 대한 HTTP 요청에서 500 응답이 발생했습니다.

현재 TCP 연결 자체보다는 HTTP 요청 처리 과정의 문제 가능성이 있어 애플리케이션 로그와 서비스 상태를 추가 확인하겠습니다.

정확한 원인은 로그 확인 후 안내하겠습니다.

이렇게 보고하면 확인된 사실과 추정 원인, 다음 점검 사항을 명확하게 구분할 수 있습니다.

정리하면

nc와 curl은 모두 접속 상태를 확인할 때 유용하지만 확인하는 범위가 다릅니다.

# TCP 포트 연결 확인
nc -vz -w 3 203.0.113.10 80

# HTTP 응답 확인
curl -I --connect-timeout 3 --max-time 10 http://203.0.113.10

• nc 성공: 해당 TCP 포트까지 연결 가능
• curl HTTP 200: 해당 HTTP 요청에 대해 정상 응답 확인
• nc 성공 + curl HTTP 500: TCP 연결은 가능하지만 HTTP 요청 처리 과정에 오류 발생

운영에서는 명령어 하나의 성공 여부보다 어디까지 연결되고 어느 단계에서 실패하는지를 구분하는 것이 중요합니다.

함께 읽으면 좋은 글

• 36번 — nc로 TCP 포트 연결 확인하기

리눅스 서버 포트 열렸는지 nc로 확인할 때 ping만 보지 말고 TCP 접속까지 확인하는 법

• 39번 — nslookup으로 DNS 확인하기

리눅스 서버 도메인 안 된다고 서버부터 보지 말고 nslookup으로 DNS부터 확인하는 법

• 74번 — ping은 되는데 사이트가 안 열릴 때

ping은 되는데 사이트가 안 열릴 때 nc와 curl로 확인하는 실제 점검 흐름