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

리눅스 서버에서 nc 명령어로 실제 TCP 포트가 열려 있는지 확인하고 ping, curl, ss, systemctl, journalctl과 함께 접속 장애 원인을 점검하는 방법을 설명하는 대표 이미지

 

리눅스 서버에서 특정 서비스 접속이 안 되는 상황을 만나면 초보 운영자는 방화벽부터 의심하기 쉽습니다.

서버는 살아 있는데 웹 접속이 안 돼요.
DB 서버 포트가 막힌 것 같아요.
방화벽 문제 아닌가요?

 

물론 방화벽 문제일 수도 있습니다.

하지만 바로 방화벽 설정을 바꾸기 전에 먼저 확인해야 할 것이 있습니다.

내 서버에서 상대 서버의 특정 TCP 포트까지 실제로 연결이 되는지입니다.

이때 사용할 수 있는 명령어가 nc입니다.

nc는 netcat이라고도 부르며, 서버 간 포트 통신 확인에 자주 사용됩니다.

이번 글에서는 리눅스 서버에서 nc 명령어로 포트가 열려 있는지 확인하는 방법과, ping, ss, curl, systemctl, journalctl을 어떤 순서로 같이 보면 좋은지 정리합니다.

ping과 nc는 확인하는 대상이 다릅니다

접속 문제를 볼 때 먼저 ping을 실행하는 경우가 많습니다.

 

ping -c 4 203.0.113.10

 

하지만 ping은 ICMP 응답을 확인하는 명령어입니다.

웹 서비스나 DB 서비스처럼 실제로 사용하는 포트가 열려 있는지는 따로 확인해야 합니다.

간단히 나누면 이렇습니다.

ping
→ ICMP 응답 확인

nc
→ TCP 포트 접근 가능 여부 확인

curl
→ HTTP 응답 확인

ss
→ 서버 내부에서 포트 LISTEN 상태 확인

 

즉, ping은 되는데 포트가 막혀 있을 수 있고, 반대로 ping은 안 되지만 서비스 포트는 열려 있을 수도 있습니다.

ping이 된다고 서비스까지 정상이라고 보면 안 되는 이유는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/34

리눅스 서버 ping 된다고 정상이라 하지 말고 포트와 curl까지 확인하는 법

 

ping이 안 된다고 바로 방화벽 문제로 단정하면 안 되는 이유는 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/35

리눅스 서버 ping 안 된다고 방화벽 문제라 하지 말고 포트와 curl까지 확인하는 법

 

가상의 운영 상황 예시

예를 들어 WAS 서버에서 DB 서버로 접속이 안 된다고 가정해보겠습니다.

[상황]
- WAS 서버에서 DB 접속 실패
- DB 서버 IP는 203.0.113.10
- DB 포트는 3306
- 초보 운영자는 방화벽 문제를 의심
- 실제로는 DB 프로세스가 안 떠 있을 수도 있음

 

이때 바로 방화벽 정책을 바꾸면 위험합니다.

먼저 WAS 서버에서 DB 서버의 3306 포트까지 연결되는지 확인합니다.

 

nc -vz -w 3 203.0.113.10 3306

 

이 결과에 따라 방향을 나눌 수 있습니다.

nc 성공
→ TCP 포트까지는 접근 가능

connection refused
→ 대상까지는 갔지만 해당 포트를 받아주는 서비스가 없을 가능성

timed out
→ 방화벽, 보안그룹, 라우팅, 중간 네트워크 구간 문제 가능성

 

여기서 중요한 점은 nc 결과만으로 모든 원인이 확정되는 것은 아니라는 것입니다.

nc는 포트까지 길이 열려 있는지 보는 도구입니다. 서비스 로직, 인증, 계정 권한, HTTP 응답 정상 여부까지 확인해주지는 않습니다.

1단계. nc 기본 사용법

가장 기본적인 형태는 아래와 같습니다.

 

nc -vz -w 3 대상IP 포트

 

예를 들어 203.0.113.10 서버의 443 포트를 확인하려면 아래처럼 입력합니다.

 

nc -vz -w 3 203.0.113.10 443

 

도메인으로도 확인할 수 있습니다.

 

nc -vz -w 3 example.com 443

 

각 옵션을 초보 운영자 눈높이로 보면 이렇습니다.

-v
→ 결과를 자세히 출력

-z
→ 데이터를 보내지 않고 포트가 열렸는지만 확인

-w 3
→ 3초만 기다리고 종료

 

운영 서버에서는 -w 옵션을 같이 주는 것이 좋습니다.

타임아웃을 지정하지 않으면 상황에 따라 명령어가 오래 멈춘 것처럼 보일 수 있기 때문입니다.

2단계. nc 성공 결과는 어떻게 볼까?

성공했을 때는 보통 이런 식으로 보일 수 있습니다.

Connection to 203.0.113.10 443 port [tcp/https] succeeded!

 

또는 환경에 따라 조금 다른 문구가 나올 수 있습니다.

Ncat: Connected to 203.0.113.10:443.

 

이 결과는 현재 서버에서 대상 서버의 해당 TCP 포트까지 연결이 된다는 뜻으로 볼 수 있습니다.

하지만 여기서 멈추면 안 됩니다.

포트 연결이 된다고 해서 서비스가 정상이라는 뜻은 아닙니다.

예를 들어 이런 경우가 있을 수 있습니다.

- 443 포트 연결은 됨
- 하지만 웹 애플리케이션은 500 오류 응답
- DB 포트 연결은 됨
- 하지만 계정 인증 실패
- Redis 포트 연결은 됨
- 하지만 애플리케이션 설정이 다른 주소를 바라봄

 

즉, nc 성공은 “포트까지 연결 가능”이라는 뜻이지 “서비스 기능 정상”이라는 뜻은 아닙니다.

HTTP 서비스라면 이어서 curl로 응답까지 확인해야 합니다.

 

curl -I https://example.com

 

3단계. connection refused는 어떻게 볼까?

실패할 때 아래처럼 보일 수 있습니다.

nc: connect to 203.0.113.10 port 443 (tcp) failed: Connection refused

 

Connection refused는 대상 서버까지는 도달했지만, 해당 포트에서 연결을 받아주는 서비스가 없을 때 자주 보입니다.

가능성은 아래처럼 볼 수 있습니다.

- 대상 서버는 응답 가능
- 하지만 해당 포트에 LISTEN 중인 서비스가 없음
- 서비스가 내려가 있음
- 서비스가 다른 포트로 떠 있음
- 방화벽이 reject 방식으로 거절

 

이때는 바로 방화벽부터 열기보다 대상 서버 내부에서 포트가 열려 있는지 확인해야 합니다.

대상 서버에 접속할 수 있다면 아래처럼 봅니다.

 

ss -lntp | grep ':443'

 

서비스 상태도 확인합니다.

 

systemctl status nginx --no-pager

 

서비스 상태 확인은 아래 글에서 자세히 정리했습니다.

https://opsnote.tistory.com/27

리눅스 서버 서비스가 안 뜰 때 재기동부터 하지 말고 systemctl status 먼저 확인하는 법

 

4단계. timed out은 어떻게 볼까?

다른 실패 예시는 아래와 같습니다.

nc: connect to 203.0.113.10 port 443 (tcp) timed out

 

timed out은 연결 시도에 대한 응답이 돌아오지 않는 상황에 가깝습니다.

가능성은 아래처럼 볼 수 있습니다.

- 중간 방화벽에서 차단
- 클라우드 보안그룹 차단
- 네트워크 ACL 차단
- 라우팅 문제
- LB, WAF, Ingress 같은 앞단 장비 문제
- 대상 서버까지 경로가 없음
- 대상 서비스가 응답하지 못함

 

다만 timed out이라고 해서 무조건 방화벽 문제로 확정하면 안 됩니다.

먼저 어디에서 확인했는지, 서버 내부에서는 포트가 열려 있는지, 다른 서버에서는 접근되는지 나눠서 봐야 합니다.

외부에서 nc timeout
서버 내부 ss LISTEN 정상
→ 방화벽, 보안그룹, LB, WAF, 라우팅 확인

외부에서 nc timeout
서버 내부 ss LISTEN 없음
→ 서비스 미기동 또는 포트 설정 문제 먼저 확인

 

포트 확인 흐름은 아래 글과 함께 보면 좋습니다.

https://opsnote.tistory.com/18

리눅스 서버 접속이 안 될 때 netstat보다 ss로 포트 확인하는 이유

 

5단계. nc 실패 시 서버 내부 확인

nc 결과가 connection refused 또는 timed out이라면 대상 서버의 포트 상태를 추가 확인해야 합니다.

서버에 접속할 수 있다면 다음 명령어를 실행합니다.

sudo ss -lntp '( sport = :3306 )'

3306 포트가 LISTEN 상태라면 서버 내부에서 해당 포트를 수신 대기 중이라는 뜻입니다.

다만 LISTEN 상태만으로 외부 접근이 가능하다고 판단할 수는 없습니다.

반대로 LISTEN 상태가 확인되지 않는다면 DB 서비스의 기동 상태, 바인딩 주소, 실제 사용 포트를 확인해야 합니다.

MySQL을 systemd로 운영하는 환경이라면 다음 명령어로 서비스 상태를 확인할 수 있습니다.

systemctl status mysqld --no-pager

서비스 이름은 운영 환경에 따라 mysql, mariadb 등으로 다를 수 있습니다.

6단계. WAS에서 DB 연결 실패 시 결과 해석

앞서 설명한 가상 사례를 이어서 보겠습니다.

WAS 서버에서 DB 서버 203.0.113.10:3306으로 연결을 시도합니다.

nc -vz -w 3 203.0.113.10 3306

nc 결과확인된 사실다음 점검

succeeded	TCP 연결 성공	DB 계정·인증·애플리케이션 설정
connection refused	연결 거부 응답 수신	DB LISTEN·서비스 상태·REJECT 정책
timed out	제한 시간 내 연결 실패	방화벽·보안그룹·라우팅·서버 상태

예를 들어 WAS에서는 connection refused가 발생하고 DB 서버에서는 3306 포트가 LISTEN 상태가 아니라면, 우선 DB 서비스 상태와 설정을 확인하는 것이 합리적입니다.

반대로 DB 서버에서 포트가 LISTEN 중인데 WAS에서 timed out이 발생한다면, 출발지와 목적지 주소, DB 바인딩 주소, 방화벽 및 네트워크 경로를 함께 확인해야 합니다.

중요한 것은 nc 실패만으로 방화벽 장애를 확정하지 않는 것입니다.

7단계. 조치 후 동일한 위치에서 재확인

원인을 확인하고 승인된 조치를 수행했다면 최초 문제가 발생한 WAS 서버에서 다시 점검합니다.

nc -vz -w 3 203.0.113.10 3306

TCP 연결이 성공했다면 다음 단계로 실제 DB 인증 및 쿼리 수행 여부를 확인합니다.

nc 성공은 DB 포트 연결을 의미할 뿐, 데이터베이스 기능이 정상이라는 뜻은 아닙니다.

점검 결과에는 최소한 출발지 서버, 목적지 IP, 포트, 실행 시간, 연결 결과를 기록해 두는 것이 좋습니다.

8단계. 운영 서버에서 nc 사용할 때 주의할 점

nc는 편리하지만 운영 서버에서 조심해야 할 부분도 있습니다.

먼저 허가 없이 여러 포트를 범위로 스캔하면 안 됩니다.

 

nc -zv 203.0.113.10 1-65535

 

이런 식의 전체 포트 스캔은 운영 환경에서 보안 탐지에 걸리거나 불필요한 오해를 만들 수 있습니다.

장애 대응 중이라도 확인이 필요한 포트만 좁혀서 보는 것이 좋습니다.

 

nc -vz -w 3 203.0.113.10 443

 

또한 UDP 포트는 TCP처럼 단순하게 판단하기 어렵습니다.

 

nc -zvu -w 3 203.0.113.10 53

 

UDP는 연결을 맺는 방식이 아니기 때문에 결과만 보고 “무조건 열렸다” 또는 “닫혔다”라고 단정하기 어렵습니다.

처음에는 TCP 포트 확인부터 익숙해지는 편이 좋습니다.

그리고 실제 운영 IP, 도메인, 고객사명은 외부 문서나 블로그에 그대로 쓰면 안 됩니다.

IP 예시: 203.0.113.10
도메인 예시: example.com
내부 값: [MASKED]

9단계. 실무 보고 예시

포트 연결이 성공한 경우에는 이렇게 정리할 수 있습니다.

대상 서버 203.0.113.10의 443 포트에 대해 nc 연결은 성공했습니다.
TCP 포트 접근은 가능한 상태로 보이며, HTTP 응답과 애플리케이션 로그를 추가 확인하겠습니다.

 

connection refused가 나온 경우에는 이렇게 쓸 수 있습니다.

대상 서버 203.0.113.10의 443 포트 확인 결과 connection refused가 확인되었습니다.
대상 서버에서 해당 포트 LISTEN 여부와 서비스 상태를 우선 확인하겠습니다.

 

timed out이 나온 경우에는 이렇게 정리할 수 있습니다.

대상 서버 203.0.113.10의 443 포트 확인 결과 timed out이 발생했습니다.
방화벽, 보안그룹, 라우팅, LB 등 중간 경로 차단 가능성을 추가 확인하겠습니다.

 

서버 내부에서는 포트가 열려 있는데 외부에서 실패한다면 이렇게 쓸 수 있습니다.

대상 서버 내부에서는 443 포트 LISTEN 상태가 확인되나,
외부 클라이언트 기준 nc 연결이 실패합니다.
외부 접근 경로의 방화벽, 보안그룹, LB, WAF 설정을 추가 확인하겠습니다.

 

포트는 열려 있지만 HTTP 응답이 실패한다면 이렇게 정리할 수 있습니다.

TCP 포트 접근은 확인되었으나 curl 기준 정상 HTTP 응답이 확인되지 않습니다.
애플리케이션 로그와 upstream 상태를 추가 확인하겠습니다.

 

이렇게 쓰면 단순히 “포트 안 됩니다”보다 훨씬 정확합니다.

정리하면

리눅스에서 특정 TCP 포트에 접근할 수 있는지 확인하려면 nc를 사용할 수 있습니다.

nc -vz -w 3 대상IP 포트

결과에 따라 다음 점검 방향이 달라집니다.

• succeeded: TCP 연결 성공. 실제 서비스 기능은 추가 확인
• connection refused: 연결 거부 응답 수신. 서비스 LISTEN 및 거부 정책 확인
• timed out: 제한 시간 내 연결 실패. 네트워크 경로와 방화벽, 서버 상태 확인

운영 환경에서는 nc 결과 하나만으로 장애 원인을 확정하지 않는 것이 중요합니다.

확인 → 판단 → 조치 → 재확인 순서로 점검하고, 조치 후에는 최초 문제가 발생한 서버에서 다시 연결을 확인해야 합니다.

함께 읽으면 좋은 글

34번 — ping 성공과 서비스 정상의 차이

리눅스 서버 ping 된다고 정상이라 하지 말고 포트와 curl까지 확인하는 법

35번 — ping 실패와 ICMP 차단 구분하기

리눅스 서버 ping 안 된다고 방화벽 문제라 하지 말고 포트와 curl까지 확인하는 법

38번 — nc와 curl의 차이 이해하기

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

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

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