Japan Server Error Fix Lab

홈 / AWS / EC2

EC2 Connection refused 해결 노트 5

EC2에서 Connection refused 오류가 발생했을 때 원인을 좁히고 다시 발생하지 않게 정리하는 운영자용 체크리스트입니다.

mediumConnection refused5 분 읽기
첫 확인 명령
grep -R "Connection refused" ./logs
먼저 볼 증거

EC2 Connection refused 대응은 먼저 발생 시각, 요청 URL, 사용자, 최근 변경, 첫 로그 라인을 확인합니다.

검색 쿼리
EC2 Connection refusedAWS error Connection refusedEC2 Connection refused 해결 노트 5

이런 상황에서 발생합니다

운영 중인 웹사이트나 API에서 같은 오류가 반복되거나, 배포 직후 특정 사용자에게만 재현될 때 참고합니다.

증상 체크

  • 브라우저 또는 API 클라이언트에 오류 코드가 표시됩니다.
  • 서버 로그에 같은 시간대의 실패 요청이 반복됩니다.
  • 최근 배포, DNS 변경, 인증서 갱신, 권한 변경 뒤에 발생하는 경우가 많습니다.
  • 일부 네트워크나 특정 경로에서만 재현될 수 있습니다.

가능성이 높은 원인

  • 설정값과 실제 운영 환경이 서로 맞지 않습니다.
  • 상위 프록시, 로드밸런서, DNS, 인증서 중 하나가 다른 상태를 보고 있습니다.
  • 서버 권한, 파일 경로, 포트, 방화벽, 데이터 상태가 바뀌었습니다.
  • 캐시나 전파 지연 때문에 사용자마다 다른 결과가 보입니다.
  • 로그를 충분히 보지 않고 화면의 오류 코드만 보고 판단하면 원인을 놓치기 쉽습니다.

1분 먼저 확인

  1. 장애가 시작된 시간과 직전 변경사항을 적습니다.
  2. 브라우저 결과, 서버 로그, 외부 명령 결과를 분리해서 봅니다.
  3. 같은 URL을 프록시 경유와 원본 서버 직접 접근으로 나누어 확인합니다.
  4. 재현되는 조건과 재현되지 않는 조건을 표로 적습니다.

먼저 볼 증거

EC2 Connection refused 대응은 먼저 발생 시각, 요청 URL, 사용자, 최근 변경, 첫 로그 라인을 확인합니다.

출력 예시

정상 출력

grep -R "Connection refused" ./logs
# no matching Connection refused entries during the checked window

실패 출력

grep -R "Connection refused" ./logs
# Connection refused appears with timestamp, request path, user, and upstream layer

출력별 판단

  • 로그에 같은 시각의 에러가 없습니다.
    브라우저, CDN, 프록시, DNS 캐시처럼 서버 밖 레이어부터 분리합니다.
  • 로그에 같은 시각과 같은 경로의 에러가 있습니다.
    그 로그가 나온 서비스, 업스트림, 권한, 데이터 상태를 우선 확인합니다.
  • 정상 사용자와 실패 사용자의 출력이 다릅니다.
    권한, 세션, 네트워크 위치, 캐시 차이를 비교합니다.

하지 말아야 할 조치

  • 빈 화면이나 코드만 보고 여러 설정을 동시에 바꾸지 마세요.
  • 원인 레이어를 확인하기 전에 전체 캐시 삭제, 전체 권한 부여, 보안 해제를 먼저 하지 마세요.

검증 상태

운영자용 초안: 기본 출력 예시와 분기 조치를 포함했습니다. 실제 incident 출력과 공식 문서 링크는 업데이트 큐에서 계속 보강합니다.

먼저 실행할 명령어

grep -R "Connection refused" ./logs
curl -Iv https://example.com
tail -n 200 /var/log/app/error.log
systemctl status nginx

해결 순서

  1. 사용자가 본 화면과 실제 요청 URL을 기록합니다.
  2. 장애 시작 시점의 배포, DNS, 인증서, 권한 변경을 확인합니다.
  3. 애플리케이션 로그와 웹서버 로그를 같은 시간대로 맞춥니다.
  4. 외부 명령어 결과와 관리 화면 표시가 일치하는지 비교합니다.
  5. 원인 후보를 하나씩 제거하고 수정 후 재검증합니다.

원인별 조치

  • 가장 최근 변경을 기준으로 설정을 되돌리거나 올바른 값으로 고칩니다.
  • 정상 요청과 실패 요청의 로그 차이를 비교합니다.
  • 원본 서버, 프록시, DNS, 인증서 레이어를 하나씩 분리합니다.
  • 수정 후 같은 명령어로 다시 확인하고 결과를 문서에 남깁니다.

검증 메타

  • operator-draft
  • official-reference-linked
  • 2026-07-23

업데이트 큐

  • 갱신 주기
    weekly-source-review
  • 다음 보강
    Add one official-source check and one real output example for AWS Connection refused.

환경별 확인 포인트

  • 공유 호스팅은 관리 화면의 반영 완료 상태를 먼저 봅니다.
  • Cloudflare나 ALB가 앞단에 있으면 원본 서버와 프록시 결과를 반드시 나눕니다.
  • 사내망, VPN, 캐시 서버가 있다면 외부 네트워크에서도 확인합니다.
  • 일본 호스팅은 SSL 반영과 DNS 반영 시간이 관리 화면 표시와 다를 수 있습니다.

다시 발생하지 않게 하기

  • 배포 체크리스트에 확인 명령어와 정상 예시를 추가합니다.
  • DNS, SSL, 방화벽, 권한 변경은 변경 전후 값을 기록합니다.
  • 자주 나오는 오류는 같은 형식의 해결 노트로 남깁니다.
  • 알림 기준을 오류율, 응답 시간, 디스크, 인증서 만료일로 나누어 둡니다.