"포트가 안 열린다"는 신고는 두 가지 완전히 다른 원인이 한 문장에 섞여 있습니다. 서비스가 그 포트를 안 듣고 있거나, 듣고 있는데 방화벽이 막고 있거나. 둘은 고치는 곳이 다르므로, 추측 대신 한 단계씩 끊어서 봐야 합니다.
1. 서버가 그 포트를 듣고 있나
먼저 서버 안에서 확인합니다. 여기서 안 보이면 방화벽 문제가 아니라 서비스 문제입니다.
로컬 터미널
ss -tlnp | grep :8080
OUTPUT
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:* users:(("java",pid=812,fd=42))
- 아무것도 안 나오면 → 서비스가 안 떠 있거나 다른 포트를 듣는 중. 방화벽은 무죄.
127.0.0.1:8080으로 나오면 → 로컬에만 바인딩됨. 외부에서는 영원히 못 붙음. 서비스 설정을0.0.0.0으로 바꿔야 함.0.0.0.0:8080으로 나오면 → 서비스는 정상. 다음은 방화벽.
2. refused인가 timeout인가
클라이언트에서 붙어보면 둘을 구분할 수 있습니다.
| 증상 | 의미 | 1순위 |
|---|---|---|
Connection refused | 즉시 거절 — 포트에 아무도 안 들음 | 서비스 실행 여부 |
Connection timed out | 무응답 — 패킷이 드롭됨 | 방화벽·보안그룹 |
refused는 패킷이 도착해 "그 포트 안 쓴다"는 응답이 온 것이고, timeout은 응답조차 없이 중간에서 버려진 것입니다. 그래서 timeout이면 방화벽을 1순위로 봅니다.
로컬 터미널
nc -zv 10.0.0.5 8080 # refused / timed out 어느 쪽인지
3. 방화벽 규칙을 본다
서비스는 듣는데 timeout이면 방화벽 차례입니다.
로컬 터미널
# iptables 계열
sudo iptables -L -n -v | grep 8080
# firewalld 계열
sudo firewall-cmd --list-ports
sudo firewall-cmd --add-port=8080/tcp --permanent && sudo firewall-cmd --reload
클라우드라면 OS 방화벽이 열려 있어도 보안그룹/네트워크 ACL에서 막혔을 수 있습니다. 이 경우도 증상은 timeout입니다.
점검 체크리스트
로컬 터미널
ss -tlnp | grep :<포트> # 서버: 듣고 있나, 어디에 바인딩됐나
nc -zv <서버IP> <포트> # 클라이언트: refused vs timeout
sudo iptables -L -n | grep <포트> # OS 방화벽 규칙
# 클라우드면 보안그룹 인바운드 규칙도 확인
ss에서 안 보이면 방화벽을 아무리 열어도 소용없습니다. 항상 듣는지 먼저, 막혔는지 나중입니다.
리슨 상태·방화벽 규칙·보안그룹을 직접 끊어보며 포트 문제를 진단하는 실습은 네트워크 트랙에서 회원가입 없이 무료로 할 수 있습니다.