리눅스 서버 Connection refused 에러? 방화벽 탓하기 전 포트와 프로세스 상태 확인하는 법

리눅스 서버에서 Connection refused가 발생했을 때 방화벽보다 먼저 서비스 상태, 포트 LISTEN, 바인딩 주소, 로그를 확인하는 방법을 설명하는 이미지입니다.

리눅스 서버에 접속을 확인하다 보면 Connection refused 메시지를 만날 때가 있습니다.

예를 들어 외부에서 포트 확인을 했는데:

nc -vz example.com 80

이런 결과가 나올 수 있습니다.

Connection refused

또는 curl로 확인했을 때도 비슷한 메시지가 보일 수 있습니다.

curl -I http://example.com

curl: (7) Failed to connect to example.com port 80: Connection refused

초보 운영자 입장에서는 이 메시지를 보면 바로 방화벽을 의심하기 쉽습니다.

접속이 거부됐네?
방화벽에서 막힌 건가?

하지만 Connection refused는 보통 방화벽에서 조용히 막힌 상황과는 조금 다릅니다.

대상 서버까지는 갔지만, 해당 포트에서 연결을 받아주는 서비스가 없거나, 포트가 열려 있지 않거나, 잘못된 IP와 포트로 요청했을 때 자주 볼 수 있습니다.

이번 글에서는 리눅스 서버에서 Connection refused가 나왔을 때 방화벽부터 보기 전에 무엇을 먼저 확인하면 좋은지 초보 운영자 눈높이로 정리해보겠습니다.

---

Connection refused는 무슨 뜻일까?

Connection refused를 아주 단순하게 표현하면 이렇습니다.

대상까지 연결 요청은 갔지만,
그 포트에서 받아주는 서비스가 없음

집으로 비유하면 주소까지 찾아갔는데, 초인종을 눌렀더니 “여기 그런 문 없습니다” 하고 바로 거절당한 느낌입니다.

반대로 Connection timed out은 응답이 아예 안 오는 쪽에 가깝습니다.

Connection refused
→ 대상까지 갔지만 포트가 닫혀 있거나 서비스가 없음

Connection timed out
→ 중간에서 응답이 안 오거나 경로가 막혀 있을 가능성

그래서 refused가 나오면 무조건 방화벽부터 보는 것보다, 먼저 서버에서 해당 포트가 실제로 열려 있는지 확인하는 게 좋습니다.

---

1단계: 내가 확인한 IP와 포트가 맞는지 보기

가장 먼저 확인할 것은 아주 기본적인 부분입니다.

접속 대상 IP가 맞는가?
접속 대상 도메인이 맞는가?
포트 번호가 맞는가?
HTTP와 HTTPS를 헷갈리지 않았는가?

예를 들어 웹 서비스가 8080에 떠 있는데 80으로 확인하면 refused가 날 수 있습니다.

nc -vz example.com 80

하지만 실제 서비스 포트가 8080이라면 아래처럼 확인해야 합니다.

nc -vz example.com 8080

HTTPS 서비스인데 HTTP 포트로 확인하는 경우도 있습니다.

curl -I http://example.com

실제로는 443만 열려 있다면:

curl -I https://example.com

초보 운영에서는 “서버 문제”라고 보기 전에 내가 찍은 주소와 포트가 맞는지부터 확인해야 합니다.

---

2단계: 서버 안에서 포트 LISTEN 확인

서버에 접속할 수 있다면 가장 먼저 ss로 포트가 열려 있는지 확인합니다.

ss -lntp

80 포트를 확인하려면:

ss -lntp | grep ':80'

443 포트라면:

ss -lntp | grep ':443'

8080 포트라면:

ss -lntp | grep ':8080'

정상적으로 열려 있다면 이런 식으로 보입니다.

LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1234,fd=6))

반대로 아무 결과도 없다면 해당 포트를 받아주는 프로세스가 없는 상태일 수 있습니다.

ss 결과 없음
→ 해당 포트 LISTEN 없음
→ 서비스 미기동 또는 다른 포트로 기동 가능성

이 경우 Connection refused는 자연스러운 결과입니다.
포트를 받을 서비스가 없기 때문입니다.

---

3단계: 서비스 상태 확인

포트가 열려 있지 않다면 서비스가 떠 있는지 확인합니다.

nginx라면:

systemctl status nginx --no-pager

Apache라면:

systemctl status httpd --no-pager

애플리케이션 서비스라면:

systemctl status app.service --no-pager

여기서 봐야 할 것은 아래입니다.

active 상태인지
failed 상태인지
inactive 상태인지
재시작 중인지
최근 에러가 있는지

예를 들어:

Active: failed

이렇게 나오면 서비스가 죽어 있는 상태입니다.

그렇다면 외부에서 접속했을 때 Connection refused가 나는 것은 당연할 수 있습니다.
이때는 방화벽이 아니라 서비스 기동 실패 원인을 봐야 합니다.

로그를 확인합니다.

journalctl -u nginx -n 100 --no-pager

또는:

journalctl -u app.service -n 100 --no-pager

---

4단계: 서비스는 active인데 포트가 안 열릴 수 있다

가끔 서비스는 active인데 포트가 열려 있지 않은 경우도 있습니다.

예를 들어:

systemctl status app.service --no-pager

상태는 active입니다.

Active: active (running)

그런데 포트 확인은 안 됩니다.

ss -lntp | grep ':8080'

결과가 없습니다.

이럴 때는 아래를 의심해볼 수 있습니다.

서비스는 떠 있지만 웹 리스너가 안 뜸
설정 파일 오류
다른 포트로 기동됨
애플리케이션 내부 초기화 실패
프로세스는 떠 있지만 정상 준비 상태 아님

그래서 systemctl status만 보고 정상이라고 판단하면 안 됩니다.

서비스 상태와 포트 LISTEN은 같이 봐야 합니다.

서비스 active
+ 포트 LISTEN
+ curl 응답

이 세 가지를 같이 확인해야 더 안전함

---

5단계: 바인딩 주소 확인

포트가 열려 있더라도 어디에 열려 있는지도 중요합니다.

ss -lntp 결과를 봅니다.

ss -lntp | grep ':8080'

예를 들어 이렇게 보일 수 있습니다.

LISTEN 0 128 127.0.0.1:8080 0.0.0.0:* users:(("app",pid=2345,fd=10))

이 경우 애플리케이션은 127.0.0.1에만 떠 있습니다.
서버 내부에서는 접속되지만 외부에서는 직접 접근할 수 없습니다.

반대로:

LISTEN 0 128 0.0.0.0:8080 0.0.0.0:* users:(("app",pid=2345,fd=10))

이 경우 모든 인터페이스에서 연결을 받을 수 있는 상태입니다.

간단히 정리하면:

127.0.0.1 = 서버 내부에서만 접근 가능
0.0.0.0 = 외부 인터페이스 포함 접근 가능
특정 IP = 해당 IP 기준으로 접근 가능

외부에서 Connection refused가 나는데 서버 내부에서는 되는 경우, 이 바인딩 주소를 꼭 확인해야 합니다.

---

6단계: localhost와 서버 IP를 나눠서 curl 확인

서버 내부에서 확인할 때도 localhost만 보면 부족합니다.

먼저 localhost로 확인합니다.

curl -I http://localhost:8080

그다음 서버 IP로도 확인합니다.

curl -I http://192.168.10.10:8080

만약 localhost는 되는데 서버 IP는 refused가 난다면, 바인딩 주소 문제일 가능성이 있습니다.

localhost 응답 정상
서버 IP 접속 refused
→ 127.0.0.1에만 바인딩되었을 수 있음

이 경우는 외부 방화벽 문제라기보다 애플리케이션 설정 문제일 수 있습니다.

예를 들어 애플리케이션 설정에서 bind address가 127.0.0.1로 되어 있으면 외부에서 접근할 수 없습니다.

---

7단계: 앞단 웹 서버와 뒤쪽 앱 포트를 구분하기

운영 서버에서는 nginx나 Apache가 앞단에 있고, 뒤쪽 애플리케이션은 다른 포트에 떠 있는 경우가 많습니다.

예를 들면:

사용자
→ nginx:80
→ app:8080

이 구조에서 외부 사용자는 80으로 접속합니다.
하지만 실제 애플리케이션은 8080에서 동작합니다.

확인은 나눠서 해야 합니다.

ss -lntp | grep ':80'

ss -lntp | grep ':8080'

nginx는 살아 있는데 app 포트가 닫혀 있으면, 외부 사용자는 502를 볼 수도 있고 내부 테스트에서는 refused가 날 수도 있습니다.

뒤쪽 앱 포트를 curl로 확인합니다.

curl -I http://127.0.0.1:8080

만약 refused가 나오면 nginx보다 애플리케이션 상태를 먼저 봐야 합니다.

systemctl status app.service --no-pager

journalctl -u app.service -n 100 --no-pager

---

8단계: 서버 방화벽은 언제 볼까?

Connection refused가 나왔다고 방화벽을 아예 안 보는 것은 아닙니다.

다만 순서가 중요합니다.

먼저 확인할 것은:

대상 IP와 포트가 맞는지
서버에서 포트가 LISTEN 중인지
서비스가 정상인지
바인딩 주소가 맞는지

그다음 서버 방화벽을 확인합니다.

firewalld를 사용한다면:

firewall-cmd --list-all

포트 목록 확인:

firewall-cmd --list-ports

서비스 목록 확인:

firewall-cmd --list-services

Ubuntu 계열에서 UFW를 사용한다면:

ufw status

iptables를 직접 본다면:

iptables -L -n

다만 방화벽이 조용히 drop하는 경우에는 보통 timeout으로 보이는 경우가 많습니다.
환경에 따라 reject 정책이면 refused처럼 보일 수도 있지만, 초보 운영자 기준에서는 먼저 서비스와 포트 확인이 더 빠른 길입니다.

---

9단계: 외부에서 확인한 refused와 서버 안의 상태 비교

외부에서 refused가 나왔다면 서버 안에서 같은 포트를 확인합니다.

외부에서:

nc -vz example.com 80

결과:

Connection refused

서버 안에서:

ss -lntp | grep ':80'

결과 없음:

포트 LISTEN 없음

이 경우는 거의 서비스 또는 포트 문제 쪽입니다.

반대로 서버 안에서는 80이 열려 있는데 외부에서 refused가 난다면 아래를 봐야 합니다.

외부에서 접속한 IP가 실제 서버가 맞는지
로드밸런서나 VIP로 접속 중인지
중간 장비에서 reject 중인지
서버 방화벽 정책이 reject인지
도메인이 다른 IP를 바라보는지

이때 DNS도 확인합니다.

nslookup example.com

또는:

dig example.com

서버가 아닌 다른 장비로 접속하고 있었다면 refused의 원인도 달라집니다.

---

10단계: 컨테이너 환경이면 포트 매핑도 확인

Docker나 Kubernetes 환경에서는 포트가 더 헷갈릴 수 있습니다.

Docker라면 컨테이너 포트와 호스트 포트가 다를 수 있습니다.

docker ps

예시:

0.0.0.0:8080->80/tcp

이 뜻은 호스트의 8080 포트가 컨테이너의 80 포트로 연결된다는 의미입니다.

이 상황에서 80으로 접속하면 refused가 날 수 있습니다.

curl -I http://localhost:80

대신 8080으로 확인해야 합니다.

curl -I http://localhost:8080

Kubernetes 환경이라면 Service, NodePort, Ingress를 구분해야 합니다.

kubectl get pod -A

kubectl get svc -A

kubectl get ingress -A

컨테이너 환경에서는 “앱 내부 포트”, “컨테이너 포트”, “서비스 포트”, “외부 노출 포트”가 다를 수 있으니 더 조심해야 합니다.

---

운영 서버에서 확인하는 순서

Connection refused가 나왔을 때 저는 보통 아래 순서로 확인합니다.

1. 접속 대상 IP와 포트가 맞는지 확인
2. 서버에서 ss로 포트 LISTEN 확인
3. systemctl로 서비스 상태 확인
4. journalctl로 서비스 로그 확인
5. localhost와 서버 IP curl 비교
6. 바인딩 주소 확인
7. 앞단 웹 서버와 뒤쪽 앱 포트 구분
8. 서버 방화벽 확인
9. DNS가 올바른 IP를 바라보는지 확인
10. 컨테이너 환경이면 포트 매핑 확인

명령어로 정리하면 아래와 같습니다.

ss -lntp | grep ':80'

systemctl status nginx --no-pager

journalctl -u nginx -n 100 --no-pager

curl -I http://localhost

curl -I http://192.168.10.10

firewall-cmd --list-all

nslookup example.com

이 순서로 보면 refused를 무작정 방화벽 문제로 몰고 가지 않고, 실제로 받을 서비스가 있는지부터 확인할 수 있습니다.

---

초보 운영자가 자주 하는 실수

Connection refused 상황에서 자주 하는 실수는 아래입니다.

refused를 무조건 방화벽 문제로 판단함
포트 LISTEN 확인을 안 함
서비스 active만 보고 정상이라고 판단함
127.0.0.1 바인딩을 놓침
80과 8080 포트를 헷갈림
nginx 포트와 app 포트를 구분하지 않음
도메인이 다른 IP를 바라보는 것을 놓침
컨테이너 포트 매핑을 확인하지 않음

특히 이 문장은 기억해두면 좋습니다.

refused면 먼저 “그 포트를 받아주는 서비스가 있는지”부터 확인한다.

방화벽은 중요한 확인 항목이지만, 첫 번째로 찍을 표적은 아닐 때가 많습니다.

---

실무 보고 예시

포트가 열려 있지 않은 경우:

Connection refused 발생 건 확인 결과, 대상 서버에서 해당 포트가 LISTEN 상태로 확인되지 않습니다.
서비스 기동 상태와 설정 포트를 추가 확인하겠습니다.

서비스가 죽어 있는 경우:

대상 포트 접속 시 Connection refused가 발생하며, 서버 내 서비스 상태 확인 결과 failed 상태로 확인됩니다.
서비스 로그 확인 후 재기동 가능 여부와 원인을 추가 확인하겠습니다.

localhost만 되는 경우:

localhost 기준 접속은 가능하나 서버 IP 기준 접속 시 Connection refused가 발생합니다.
서비스 바인딩 주소가 127.0.0.1로 제한되어 있는지 확인하겠습니다.

외부에서만 refused가 나는 경우:

서버 내부 포트 LISTEN 상태는 정상이나 외부 접속 시 Connection refused가 발생하고 있습니다.
접속 대상 IP, DNS 매핑, 서버 방화벽 및 중간 장비 reject 여부를 추가 확인하겠습니다.

컨테이너 포트가 의심되는 경우:

컨테이너 환경에서 Connection refused가 발생하여 호스트 포트와 컨테이너 내부 포트 매핑 상태를 확인 중입니다.
실제 외부 노출 포트 기준으로 재확인하겠습니다.

이렇게 보고하면 “방화벽 문제 같습니다”보다 훨씬 안전하고 실무적입니다.

---

정리

리눅스 서버에서 Connection refused가 나왔다고 바로 방화벽부터 보면 원인을 놓칠 수 있습니다.

기본 확인 명령어는 아래입니다.

ss -lntp | grep ':포트'
systemctl status 서비스명 --no-pager
journalctl -u 서비스명 -n 100 --no-pager
curl -I http://localhost:포트
curl -I http://서버IP:포트
nslookup example.com

초보 운영자라면 이 문장만 기억해도 좋습니다.

refused면 방화벽보다 먼저 서비스와 포트 LISTEN부터 확인한다.

접속 장애도 결국 확인 → 판단 → 조치 순서가 중요합니다.

4. 관련 글 연결 문구

Connection refused는 접속 장애에서 자주 보이는 메시지지만, 무조건 방화벽 문제라고 단정하면 안 됩니다.
아래 글도 함께 보면 접속 장애 확인 흐름을 이어서 이해하기 좋습니다.

• 리눅스 서버 웹사이트 접속이 안 될 때 방화벽부터 보기 전 확인 순서
• 리눅스 서버 포트는 열렸는데 접속이 안 될 때 확인할 것
• 리눅스 서버 내부 접속은 되는데 외부 접속이 안 될 때 확인하는 법
• 리눅스 서버 포트 확인할 때 netstat만 찾지 말고 ss로 보는 법

5. 다음 글 예고 문구

다음 글에서는 Connection timed out이 나왔을 때 서버까지 요청이 도착하지 않는 상황을 어떻게 나눠서 확인하면 좋은지 정리해보겠습니다.