웹 서비스가 열리지 않을 때 '방화벽 문제'부터 단정하면 진단이 길어진다. 연결은 이름 해석, 목적지 주소, 경로, 포트, 서버 프로세스가 모두 맞아야 하므로 실패 지점을 순서대로 좁히는 것이 좋다.
먼저 대상과 포트를 명확히 한다
URL의 호스트가 어떤 IP로 해석되는지, 클라이언트가 정확히 어떤 포트에 접속하는지 확인한다. HTTPS 기본 포트와 애플리케이션 포트가 다를 수 있으며, 로드 밸런서와 서버가 서로 다른 포트를 쓸 수도 있다.
서버가 실제로 리스닝하는지 확인한다
서버 프로세스가 실행 중인지와 해당 포트가 예상 주소에 바인딩됐는지를 본다. 로컬 루프백에만 바인딩한 서비스는 같은 서버에서는 열려도 외부에서는 접속되지 않는다. 프로세스를 재시작하기 전에 로그와 바인딩 상태를 보면 설정 오류를 보존할 수 있다.
python3 -m http.server 8000 --bind 127.0.0.1
# 다른 터미널에서
ss -ltn
curl --max-time 3 -I http://127.0.0.1:8000/
curl --max-time 3 -I http://127.0.0.1:8001/이 예제에서 8000번은 로컬 HTTP 응답을 주고 8001번은 리스너가 없어 연결에 실패해야 한다. 같은 IP에서도 포트에 따라 결과가 다른 것이다. 리눅스 서버에서 ss의 Local Address가 127.0.0.1:8000이라면 로컬에만 바인딩된 상태다. 8000번도 실패하면 서버 프로세스와 포트 설정을 확인한다. 로컬에서는 성공하지만 외부에서만 실패한다면 그때 방화벽·보안 그룹·로드 밸런서 경계로 진단을 옮긴다.
경계마다 허용 규칙을 대조한다
서버 운영체제 방화벽, 클라우드 보안 그룹·NSG, 네트워크 ACL, 로드 밸런서 규칙은 서로 다른 경계다. 필요한 출발지·프로토콜·포트만 허용하고, 문제를 해결하려고 모든 IP와 포트를 여는 것은 피한다. 응답이 없을 때는 어느 경계까지 도달했는지 로그와 연결 테스트로 확인한다.
핵심 요약
연결 실패는 IP나 포트 하나의 문제가 아닐 수 있다. 이름 해석, 대상 주소, 서버 리스닝, 네트워크 경계 규칙을 차례로 확인하자. 최소 허용 규칙을 유지하면서 관측 결과로 다음 가설을 정하면 빠르고 안전하게 원인을 찾을 수 있다.
