01. 연결이 안 돼요 — 계층별로 좁히기 — 소설처럼 읽는 데이터통신과 컴퓨터 네트워크

연결이 안 돼요 — 계층별로 좁히기

서버에 배포가 완료됐다는 알림을 받았습니다. 브라우저를 열고 도메인을 입력합니다. 응답이 없습니다. curl을 쳐도 타임아웃입니다. "연결이 안 됩니다"는 말은 맞지만, 원인이 어디인지는 전혀 알 수 없는 상태입니다.

원인 후보는 여럿입니다. 물리 회선 문제일 수도 있고, 서버의 IP 라우팅이 잘못됐을 수도 있고, DNS가 옛 IP를 가리킬 수도 있고, 방화벽이 포트를 막고 있을 수도 있습니다. 막연하게 서버 로그를 뒤지기 전에 계층을 따라 가설을 하나씩 소거합니다.

첫 번째로 내 컴퓨터에서 서버 IP에 ping이 닿는지 봅니다.

# 파일: 터미널ping -c 4 203.0.113.10

ping이 응답한다면 IP 레벨, 즉 3계층까지는 정상입니다. 응답이 없다면 라우팅 경로 어딘가에 단절이 있습니다. 이때 traceroute로 어느 구간에서 패킷이 멈추는지 확인합니다.

# 파일: 터미널traceroute 203.0.113.10

특정 홉에서 * * *이 반복된다면 그 구간 라우터에서 패킷이 막히거나 소실되고 있습니다. 클라우드 서버라면 해당 보안 그룹이나 ACL에서 ICMP를 허용했는지 확인합니다.

두 번째로 DNS가 올바른 IP를 반환하는지 봅니다.

# 파일: 터미널dig api.example.com +short

다른 IP가 나오거나 응답이 없다면 DNS 문제입니다. DNS 점검은 다음 절에서 더 자세히 다룹니다.

세 번째로 TCP 포트가 열려 있는지 봅니다. ping이 성공했더라도 방화벽이 특정 포트를 막고 있을 수 있습니다.

# 파일: 터미널curl -v --connect-timeout 5 http://203.0.113.10:8080

Connection refused라면 포트에 프로세스가 바인딩되지 않은 것입니다. 서버에서 ss -tlnp로 실제로 어떤 포트가 LISTEN 중인지 확인합니다.

# 파일: 터미널ss -tlnp

LISTEN 상태에 해당 포트가 없다면 서비스가 실행 중이지 않거나 다른 포트를 쓰고 있습니다. 클라우드 환경이라면 인바운드 보안 그룹 규칙에서 포트가 열려 있는지도 함께 확인합니다.

가장 흔한 패턴 두 가지입니다. 첫째는 방화벽이 포트를 막은 경우입니다. 클라우드 콘솔에서 보안 그룹 인바운드 규칙에 해당 포트를 추가하면 됩니다. 둘째는 서비스가 예상한 포트가 아닌 다른 포트에서 실행 중인 경우입니다. 배포 스크립트나 환경 변수 설정을 확인합니다.

계층별 소거 방식은 결국 "지금 어디까지는 정상"이라는 확신을 쌓아가는 과정입니다. 확신이 쌓이면 남은 가능성은 좁아집니다. 다음 절에서는 서버를 재시작했을 때 포트가 바로 안 열리는 구체적인 시나리오를 다룹니다.