포트가 열려 있어도 접속되지 않는 이유

서버에 애플리케이션을 배포한 뒤 방화벽 규칙도 추가했는데 외부에서 접속되지 않는 경우가 있습니다. 이때 포트가 열렸는지만 확인하고 원인을 단정하면 해결 시간이 길어집니다. 실제 연결은 클라이언트 네트워크, DNS, 서버 라우팅, 클라우드 보안 그룹, 운영체제 방화벽, 프로세스 리스닝 주소, 리버스 프록시 설정을 순서대로 통과합니다. 한 지점만 끊겨도 브라우저에는 단순한 연결 실패로 나타납니다.

장애 상황에서는 설정을 무작정 바꾸기보다 연결이 어느 구간까지 도달했는지 증거를 모아야 합니다. 이 문서는 Linux에서 HTTP 서비스가 외부에 열리지 않을 때 적용할 수 있는 점검 순서와 명령을 정리합니다. 예시는 8080 포트의 애플리케이션을 Nginx가 443으로 프록시하는 구성입니다.

1. 서버 내부에서 서비스 자체를 확인한다

외부 접속부터 시험하면 DNS와 방화벽 변수가 한꺼번에 섞입니다. 서버에 SSH로 접속한 뒤 localhost 요청이 성공하는지 확인합니다. 응답 코드가 200이 아니어도 TCP 연결과 애플리케이션 로그를 함께 보면 서비스가 살아 있는지 판단할 수 있습니다.

curl -i --max-time 5 http://127.0.0.1:8080/health
ss -lntp | grep ':8080'
systemctl status myapp --no-pager
journalctl -u myapp -n 100 --no-pager

ss 출력에서 중요한 것은 포트뿐 아니라 Local Address입니다. 127.0.0.1:8080은 서버 내부 요청만 받습니다. Nginx가 같은 서버에서 프록시한다면 정상일 수 있지만, 외부 클라이언트가 8080에 직접 접속해야 하는 구조라면 0.0.0.0:8080 또는 서버 실제 인터페이스 주소에 바인딩해야 합니다. 반대로 관리용 포트를 무심코 모든 인터페이스에 공개하지 않도록 서비스 목적부터 분명히 해야 합니다.

2. Nginx와 백엔드의 경계를 분리한다

외부 공개가 Nginx를 통한다면 애플리케이션 포트가 아니라 Nginx의 리스너와 프록시 연결을 검사합니다. 설정 문법 오류나 오래된 설정이 남아 있으면 재시작은 되었어도 의도한 server 블록이 선택되지 않을 수 있습니다. 먼저 유효 설정을 검사하고, Host 헤더를 넣어 로컬에서 가상 호스트를 테스트합니다.

sudo nginx -t
sudo systemctl reload nginx
curl -ik --resolve example.com:443:127.0.0.1 https://example.com/health
sudo tail -n 100 /var/log/nginx/error.log

--resolve는 DNS를 우회하고 지정한 IP로 연결하므로 인증서, Nginx, 백엔드 문제와 DNS 문제를 분리하는 데 유용합니다. Nginx 오류 로그에 connect() failed (111: Connection refused)가 보이면 백엔드가 실행 중인지, proxy_pass 대상 주소와 포트가 맞는지 확인합니다. 502는 보통 프록시와 백엔드 사이, 504는 백엔드 처리 시간 또는 타임아웃 설정 쪽부터 살피면 됩니다.

3. 운영체제 방화벽의 적용 상태를 확인한다

Ubuntu 계열에서는 UFW, RHEL 계열에서는 firewalld를 사용하는 경우가 많습니다. 둘 중 어떤 도구가 설치되어 있는지부터 확인하고, 동일 포트를 여러 규칙 체계로 관리하지 않는 것이 좋습니다. 규칙을 추가한 뒤에는 활성 상태와 인터페이스별 적용 결과를 확인해야 합니다.

# UFW를 사용하는 서버
sudo ufw status numbered
sudo ufw allow 443/tcp

# firewalld를 사용하는 서버
sudo firewall-cmd --state
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

방화벽을 잠시 전체 비활성화해 원인을 찾는 방식은 운영 서버에서 피해야 합니다. 필요한 포트와 프로토콜만 열고, 관리 포트는 사무실 VPN이나 운영자 고정 IP 대역으로 제한합니다. IPv4 규칙만 추가했는데 도메인의 AAAA 레코드가 IPv6를 가리키는 경우도 자주 놓칩니다. curl -4와 curl -6로 각각 시험하거나, IPv6 운영 계획이 없다면 AAAA 레코드를 정리합니다.

4. 클라우드와 네트워크 계층을 따로 본다

VPS나 클라우드 VM에서는 운영체제 방화벽 외에 보안 그룹, 네트워크 ACL, 로드밸런서 리스너 규칙이 있을 수 있습니다. 서버 안에서 curl이 성공하고 Nginx도 443을 수신하지만 외부에서만 실패한다면 이 계층을 우선 확인합니다. 보안 그룹 인바운드에 TCP 443이 허용되어 있는지, 대상 인스턴스 또는 로드밸런서에 규칙이 연결되어 있는지, 공인 IP가 바뀌지 않았는지 점검합니다.

서버 패킷 도착 여부는 tcpdump로 짧게 확인할 수 있습니다. 외부에서 한 번 접속을 시도하는 동안 아래 명령을 실행합니다. SYN 패킷이 보이지 않으면 서버 프로세스보다 앞단 네트워크 문제일 가능성이 큽니다. SYN은 보이지만 응답이 없으면 로컬 방화벽이나 리스닝 소켓을 다시 확인합니다.

sudo tcpdump -ni any 'tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-ack) != 0)'
ip route
ip addr show

5. DNS와 TLS를 독립적으로 검증한다

서비스와 네트워크가 정상이어도 도메인이 오래된 IP를 가리키거나 프록시 CDN 설정이 잘못되면 접속이 실패합니다. DNS 변경 직후에는 로컬 DNS 캐시와 레코드 TTL 때문에 사용자별 결과가 다를 수 있습니다. A와 AAAA 레코드, 실제 공인 IP, 로드밸런서 대상이 일치하는지 확인합니다. TLS에서는 인증서 만료일과 SNI에 따라 선택되는 인증서를 함께 봐야 합니다.

dig +short A example.com
dig +short AAAA example.com
openssl s_client -connect example.com:443 -servername example.com < /dev/null

테스트용으로 인증서 검증을 끄는 curl -k는 원인 분리에만 사용하고, 운영 점검의 최종 성공 기준으로 쓰면 안 됩니다. 최종적으로는 일반 브라우저와 검증이 켜진 curl에서 정상 체인이 확인되어야 합니다.

운영 체크리스트

  • 서버 내부 localhost 요청이 성공하는가
  • 프로세스가 의도한 주소와 포트에서 리스닝하는가
  • Nginx 설정 검사와 로컬 Host 기반 요청이 성공하는가
  • 운영체제 방화벽과 클라우드 보안 규칙이 필요한 포트를 허용하는가
  • 외부 접속 시 패킷이 서버까지 도착하는가
  • A·AAAA 레코드와 TLS 인증서가 현재 서비스 대상과 일치하는가

이 순서를 기록해 두면 접속 장애를 감으로 해결하지 않고 실패 지점을 빠르게 좁힐 수 있습니다. 변경 전후의 명령 결과와 시간대를 남기는 습관은 재발 방지와 운영 인수인계에도 직접 도움이 됩니다.