ERR_CONNECTION_REFUSED: 의미와 해결 방법 완벽 가이드

Advertisement
ERR_CONNECTION_REFUSED란 무엇인가요?
ERR_CONNECTION_REFUSED는 브라우저가 웹사이트의 서버에는 도달했지만 서버가 연결을 능동적으로 거부할 때 Chrome에 표시되는 오류입니다. 네트워크 수준에서 보면, 컴퓨터가 서버의 IP 주소와 포트로 TCP 연결 요청(SYN)을 보냈는데 서버 — 또는 그 앞단의 방화벽 — 가 이를 수락하는 대신 "여기서는 아무도 응답하지 않는다"는 의미의 리셋(RST) 패킷으로 답한 것입니다.
이 점에서 ERR_CONNECTION_REFUSED는 DNS_PROBE_FINISHED_NXDOMAIN 같은 DNS 오류와 근본적으로 다릅니다. DNS 오류에서는 도메인 이름이 IP 주소로 아예 변환되지 못합니다. 반면 ERR_CONNECTION_REFUSED에서는 DNS가 완벽하게 작동했고 — 브라우저는 서버가 어디에 있는지 정확히 알고 있습니다 — 그 주소의 머신이 문을 열어주기를 거부한 것입니다.
연결 거부는 보통 세 가지 중 하나를 의미합니다: 해당 포트에서 수신 대기 중인 서비스가 없거나(웹 서버가 다운되었거나 크래시), 방화벽이 해당 포트로 향하는 트래픽을 거부하고 있거나, 오래된 DNS 캐시나 고장 난 프록시 때문에 기기가 아예 잘못된 IP 주소로 연결하고 있는 경우입니다.
다른 브라우저에서는 이 오류가 어떻게 표시되나요?
브라우저마다 연결 거부를 다르게 표현하지만, 밑바탕의 TCP 거부는 동일합니다.
| 브라우저 | 오류 메시지 |
|---|---|
| Google Chrome | This site can't be reached — [site] refused to connect. ERR_CONNECTION_REFUSED |
| Microsoft Edge | Hmmm… can't reach this page — [site] refused to connect. |
| Mozilla Firefox | Unable to connect — Firefox can't establish a connection to the server. |
| Safari | Safari Can't Connect to the Server |
| Brave / Opera | This site can't be reached — ERR_CONNECTION_REFUSED |
Chromium 기반 브라우저(Chrome, Edge, Brave, Opera)는 모두 원시 ERR_CONNECTION_REFUSED 코드를 그대로 노출합니다. Firefox와 Safari는 일반적인 문장으로 표현하지만, 원인과 해결 방법은 완전히 동일합니다.
ERR_CONNECTION_REFUSED의 일반적인 원인
대략 절반은 서버 측의 문제이고, 나머지 절반은 사용자의 기기나 네트워크에서 무언가가 간섭하는 경우입니다. 가장 흔한 순서대로 정리한 일반적인 원인은 다음과 같습니다.
웹사이트의 서버 다운 — 웹 서비스(nginx, Apache, Node.js)가 크래시했거나, 재시작 중이거나, 중지되었습니다. 머신은 온라인이지만 포트 80/443에서 아무것도 응답하지 않습니다.
방화벽의 포트 차단 — 서버, 네트워크 또는 기기의 방화벽이 해당 포트로의 연결을 거부합니다.
잘못 구성된 프록시 설정 — 시스템이 오프라인이거나 도달할 수 없는 프록시 서버로 트래픽을 라우팅합니다. 클라이언트 측에서 가장 흔한 원인 중 하나입니다.
오래된 DNS 캐시 — 사이트가 새 서버로 이전했지만, 캐시된 DNS 항목이 여전히 아무것도 수신 대기하지 않는 이전 IP 주소를 가리킵니다.
VPN 또는 백신 프로그램 간섭 — 보안 소프트웨어가 연결을 가로채 거부하거나, VPN 출구 서버가 사이트에 도달하지 못합니다.
브라우저 확장 프로그램 간섭 — 광고 차단기, 개인정보 보호 확장 프로그램, 악성코드에 감염된 확장 프로그램이 특정 호스트로의 연결을 차단할 수 있습니다.
hosts 파일 재정의 — hosts 파일에서 도메인이 잘못된 IP(주로 127.0.0.1)에 매핑되어 있어 브라우저가 자기 자신의 컴퓨터로 연결하고, 그 연결이 거부됩니다.
localhost에서 수신 대기 중인 서비스 없음 — 개발자의 경우: 로컬 개발 서버가 실행되고 있지 않거나, 크래시했거나, 열어 둔 포트와 다른 포트에 바인딩되어 있습니다.
라우터 문제 — 오작동하는 라우터나 모뎀이 재시작 전까지 연결을 망가뜨립니다.
해결 방법 1: 사이트가 모두에게 다운되었는지 확인
기기에서 무언가를 변경하기 전에, 먼저 문제가 서버 측에 있는지 확인하세요 — 사이트가 모두에게 다운된 상태라면 로컬에서 어떤 조치를 해도 소용이 없습니다.
가장 깔끔한 테스트 방법은 다른 네트워크 경로에서 접속해 보는 것입니다. 휴대폰에서 Wi-Fi를 끄고 모바일 데이터로 사이트를 열어 보세요. 거기서도 실패한다면 서버 자체가 연결을 거부하고 있는 것이므로, 사이트 소유자가 고칠 때까지 기다리는 수밖에 없습니다.
다음 DNS Robot 도구들로 서버를 직접 테스트할 수도 있습니다:
[포트 확인 도구](/port-checker) — 사이트의 도메인을 입력하고 포트 443(HTTPS)과 포트 80(HTTP)을 테스트하세요. 둘 다 닫힘으로 표시되면 웹 서버가 다운되었거나 방화벽이 모두를 차단하고 있는 것입니다 — 나만의 문제가 아닙니다.
[Ping 테스트](/ping) — 서버 머신이 응답하는지 여부를 확인합니다. Ping은 되는데 포트가 닫혀 있다면, 머신은 켜져 있지만 웹 서비스가 죽은 것입니다.
[HTTP 헤더 검사 도구](/http-headers) — DNS Robot 서버에서 실제 HTTP 요청을 보냅니다. 여기서는 응답을 받는데 내 브라우저에서는 안 된다면, 문제는 내 기기나 네트워크에 있습니다.
Advertisement
해결 방법 2: 라우터와 기기 재시작
가장 고전적인 첫 번째 조치인 데는 이유가 있습니다: 재부팅은 라우터의 연결 테이블, DNS 캐시, 그리고 연결 거부를 유발할 수 있는 오작동 NAT 상태를 초기화합니다.
라우터(모뎀이 분리형이라면 모뎀도)의 전원 플러그를 뽑고 30초 기다린 뒤 다시 꽂고, 완전히 재연결될 때까지 2~3분 기다리세요. 컴퓨터나 휴대폰도 재시작해 네트워크 스택을 초기화한 다음 사이트에 다시 접속해 보세요.
해결 방법 3: 브라우저 캐시와 쿠키 삭제
Chrome이 깨진 리디렉션, 오래된 HSTS 항목, 또는 죽은 서버로 안내하는 쿠키를 캐시하고 있을 수 있습니다. 이를 삭제하면 완전히 새로운 연결이 강제됩니다.
Chrome을 열고 → 점 세 개 메뉴 → 인터넷 사용 기록 삭제를 클릭합니다
기간 → 전체 기간을 선택합니다
"쿠키 및 기타 사이트 데이터"와 "캐시된 이미지 및 파일"을 체크합니다
데이터 삭제를 클릭하고 Chrome을 재시작한 뒤 사이트에 다시 접속합니다
해결 방법 4: 프록시 설정 비활성화
잘못 구성되었거나 죽은 프록시는 모든 웹사이트에서 동시에 ERR_CONNECTION_REFUSED가 발생하는 가장 흔한 원인 중 하나입니다. 이미 존재하지 않는 프록시로 트래픽을 라우팅하도록 시스템이 설정되어 있으면 — 예전 VPN, 학교/회사 설정, 악성코드가 남긴 경우가 많습니다 — 모든 연결이 거부됩니다.
Windows: 설정 → 네트워크 및 인터넷 → 프록시를 엽니다. 수동 프록시 설정에서 "프록시 서버 사용"을 끄고, 회사 프록시를 쓰지 않는다면 "설정 자동 검색"도 끕니다.
macOS: 시스템 설정 → 네트워크 → Wi-Fi → 세부사항 → 프록시를 엽니다. 조직에서 요구하지 않는 한 목록의 모든 프로토콜(웹 프록시 HTTP, 보안 웹 프록시 HTTPS, SOCKS 프록시)을 해제하고 확인을 클릭합니다.
Chrome은 운영체제의 프록시 설정을 사용하므로, 변경 후 브라우저를 재시작하고 다시 테스트하세요.
해결 방법 5: DNS 캐시 플러시
웹사이트가 최근 새 서버로 이전했다면, 캐시된 DNS 항목이 여전히 이전 IP 주소를 가리킬 수 있습니다 — 거기에는 이제 아무것도 수신 대기하지 않으므로 연결이 거부됩니다. 캐시를 플러시하면 기기가 현재 주소를 다시 조회하게 됩니다.
# Windows (Command Prompt as Administrator)
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
sudo resolvectl flush-caches
# Also clear Chrome's internal DNS cache:
# chrome://net-internals/#dns → Clear host cache플러시 후에는 chrome://net-internals/#dns에서 Chrome 자체의 DNS 캐시도 삭제하고 chrome://net-internals/#sockets에서 소켓 풀도 플러시하세요 — Chrome은 운영체제와 별도로 둘 다 유지합니다. 전체 과정은 모든 OS에서 DNS를 플러시하는 방법 가이드를 참조하세요.
DNS Robot의 DNS 조회로 도메인이 현재 어떤 IP로 변환되는지 확인할 수 있습니다 — 터미널의 nslookup이 전 세계 결과와 다른 IP를 표시한다면 캐시가 문제였던 것입니다.
Advertisement
해결 방법 6: 공용 DNS 서버로 전환
ISP의 DNS 서버가 오래된 레코드를 반환하고 있다면 캐시 플러시는 도움이 되지 않습니다 — 같은 오래된 IP를 다시 받아올 뿐입니다. 빠른 공용 리졸버로 전환하면 최신 레코드를 받게 되고, 대개 전반적인 브라우징 속도도 빨라집니다.
| 공급자 | 기본 DNS | 보조 DNS | 최적 용도 |
|---|---|---|---|
| Cloudflare | 1.1.1.1 | 1.0.0.1 | 속도와 개인정보 보호 |
| Google Public DNS | 8.8.8.8 | 8.8.4.4 | 안정성 |
| Quad9 | 9.9.9.9 | 149.112.112.112 | 악성코드 차단 |
| OpenDNS | 208.67.222.222 | 208.67.220.220 | 콘텐츠 필터링 |
Windows: 설정 → 네트워크 및 인터넷 → 사용 중인 연결 → DNS 서버 할당 옆의 편집 → 수동 → IPv4 켬 → 1.1.1.1과 1.0.0.1 입력 → 저장.
macOS: 시스템 설정 → 네트워크 → Wi-Fi → 세부사항 → DNS → 1.1.1.1과 1.0.0.1을 추가하고 기존 항목 제거 → 확인.
내 위치에서 어떤 리졸버가 가장 빠른지 모르겠나요? DNS Robot의 DNS 속도 테스트를 실행하세요 — 몇 초 만에 내 회선에서 Cloudflare, Google, Quad9 등을 벤치마크합니다.
해결 방법 7: VPN, 백신 프로그램, 방화벽 일시 비활성화
VPN, 백신 프로그램의 웹 보호 기능, 방화벽은 모두 브라우저와 인터넷 사이에 위치하며, 각각이 연결을 거부할 수 있습니다. 백신의 HTTPS 검사 기능이 단골 원인입니다: 보안 트래픽을 로컬 서비스를 통해 프록시하는데, 그 서비스가 고장 나면 모든 HTTPS 사이트가 거부됩니다.
다음 순서로 테스트하세요: VPN을 끊고 새로고침합니다. 그다음 백신의 웹 보호 모듈을 잠시 비활성화하고 새로고침합니다. 마지막으로 방화벽(Windows Defender 방화벽 또는 macOS 방화벽)을 잠깐 끄고 새로고침합니다.
이 중 하나를 껐을 때 사이트가 열린다면, 다시 켠 뒤 해당 사이트를 예외로 추가하거나 — VPN이라면 다른 서버 위치로 전환하세요. 보호 기능을 꺼 둔 채로 두지 마세요.
해결 방법 8: 시크릿 모드에서 확장 프로그램 테스트
광고 차단기, 개인정보 보호 도구, VPN 확장 프로그램은 특정 호스트로의 연결을 조용히 차단할 수 있습니다. 빠른 테스트: 대부분의 확장 프로그램이 기본적으로 비활성화되는 시크릿 창(Ctrl+Shift+N / Cmd+Shift+N)에서 사이트를 열어 보세요.
시크릿 모드에서 사이트가 열린다면 확장 프로그램이 원인입니다. chrome://extensions로 이동해 모두 비활성화한 뒤, 오류가 다시 나타날 때까지 하나씩 다시 켜세요 — 그것이 범인입니다. 제거하거나 해당 사이트를 필터에서 제외하세요.
해결 방법 9: hosts 파일 확인
hosts 파일은 특정 도메인에 대해 DNS를 재정의합니다. 사이트가 그 파일에서 127.0.0.1, 0.0.0.0, 또는 예전 서버 IP에 매핑되어 있으면 브라우저는 그 주소로 대신 연결하고 — 거부당합니다. 남아 있는 개발용 항목과 광고 차단 hosts 목록이 단골 용의자입니다.
# Windows — open as Administrator:
notepad C:\Windows\System32\drivers\etc\hosts
# macOS / Linux:
sudo nano /etc/hosts
# Look for lines containing the domain, e.g.:
# 127.0.0.1 example.com ← forces the connection to your own PC
# 203.0.113.7 example.com ← forces an old server IP
# Delete the offending line, save, then flush DNS.Advertisement
localhost에서 연결을 거부했습니다 (개발자용)
127.0.0.1에서 localhost에서 연결을 거부했습니다 또는 ERR_CONNECTION_REFUSED를 마주치는 것은 모든 개발자의 통과의례입니다. 요청한 포트에서 연결을 수락하는 것이 내 컴퓨터에 아무것도 없다는 뜻입니다. 흔한 이유는 다음과 같습니다:
개발 서버가 실행 중이 아님 — 시작한 적이 없거나 크래시했습니다.
npm run dev,rails s,python manage.py runserver가 실행 중이어야 할 터미널을 확인하세요.잘못된 포트 — 서버가 다른 포트에서 시작되었는데(예: 3000이 사용 중이라 3001) 예전 포트를 열고 있는 경우입니다. 어떤 포트에 바인딩되었는지 알려주는 시작 로그 줄을 확인하세요.
다른 인터페이스에 바인딩됨 — 서버는
0.0.0.0이나 컨테이너 내부 IP에 바인딩되었는데localhost로 접속하는 경우 — 또는 그 반대입니다. Docker 포트 매핑(-p 3000:3000)은 앱이 컨테이너 안에서 수신하는 포트와 일치해야 합니다.방화벽 또는 보안 소프트웨어 — 로컬 방화벽은 루프백 포트조차 차단할 수 있습니다. 회사 컴퓨터에서 흔합니다.
HTTPS vs HTTP — https://localhost:3000을 여는데 개발 서버는 일반 HTTP만 지원하는 경우입니다. 명시적으로 http://를 시도해 보세요.
# Which process is listening on port 3000?
# macOS / Linux:
lsof -i :3000
# Windows (PowerShell):
netstat -ano | findstr :3000
# No output = nothing is listening = connection refused.
# Start your dev server, or kill the stale process and restart it.공용 서버의 포트가 인터넷에서 도달 가능한지(머신 자체에서만이 아니라 외부에서) 확인해야 한다면 DNS Robot의 포트 확인 도구를 사용하세요 — 네트워크 외부에서 연결을 테스트하며, 이것이 방문자가 실제로 경험하는 것입니다.
웹사이트 소유자용: 내 사이트가 연결을 거부할 때
방문자들이 내 웹사이트에서 ERR_CONNECTION_REFUSED를 보고한다면, 서버는 켜져 있지만(DNS는 변환되고 머신은 ping에 응답할 가능성이 높음) 웹 서비스가 연결을 수락하지 않는 상태입니다. 다음 체크리스트를 순서대로 확인하세요:
웹 서버 프로세스가 실행 중인가? SSH로 접속해 확인하세요:
systemctl status nginx(또는 apache2, caddy). 실패한 리로드나 메모리 부족(OOM) 킬 이후 크래시된 프로세스가 1위 원인입니다. 재시작:sudo systemctl restart nginx.올바른 포트에서 수신 대기 중인가?
ss -tlnp | grep -E ':80|:443'을 실행하세요. 443에서 아무것도 수신하지 않는다면 TLS 구성 로드에 실패한 것입니다 —nginx -t로 구성 오류를 확인하세요.방화벽이 열려 있는가?
ufw status또는 클라우드 제공업체의 보안 그룹을 확인하세요. 포트 80과 443은 0.0.0.0/0에서의 인바운드 TCP를 허용해야 합니다.서버 IP가 변경되었는가? DNS 조회로 DNS A 레코드와 서버의 실제 IP를 비교하세요. 마이그레이션 후 남은 예전 A 레코드는 방문자를 이전 머신으로 보냅니다.
외부에서 테스트 — 포트 확인 도구로 포트 80과 443을 테스트하고, HTTP 헤더 검사 도구로 서버가 공용 인터넷에서 온 실제 요청에 응답하는지 확인하세요.
해결되었는지 확인하는 방법
각 해결 방법을 적용한 후에는 페이지 새로고침만 하지 말고 네트워크 수준에서 연결을 확인하세요 — 포트가 실제로 열렸는지 알 수 있습니다.
# Test the TCP connection directly (Mac/Linux):
nc -zv example.com 443
# "succeeded" = port open, "refused" = still rejected
# Windows (PowerShell):
Test-NetConnection example.com -Port 443
# TcpTestSucceeded : True = fixed
# Then confirm what IP you're actually connecting to:
nslookup example.com터미널이 번거롭다면 건너뛰어도 됩니다: DNS Robot의 포트 확인 도구에 도메인과 포트를 입력하면 외부 네트워크 기준의 열림/닫힘 여부를 즉시 알려줍니다. 외부에서는 포트가 열려 있는데 브라우저에 여전히 ERR_CONNECTION_REFUSED가 표시된다면 차단 요인은 내 기기에 있습니다 — 위의 프록시, VPN, 백신, hosts 파일 해결 방법을 다시 확인하세요.
포트가 열려 있을까요 — 아니면 서버가 정말 거부하고 있을까요?
DNS Robot의 무료 포트 확인 도구는 외부 네트워크에서 어떤 도메인과 포트든 몇 초 만에 테스트합니다. 사이트의 포트 80/443이 열림, 닫힘, 필터링 상태인지 즉시 확인하세요 — "모두에게 다운된 걸까, 나만 안 되는 걸까?"에 대한 확실한 답입니다.
사용해보기 Port CheckerAdvertisement
자주 묻는 질문
브라우저가 웹사이트의 서버에 도달했지만 서버가 해당 포트에서 TCP 연결을 능동적으로 거부했다는 의미입니다. DNS 확인은 성공했고 — 브라우저는 서버의 IP를 알고 있습니다 — 아무것도 연결을 수락하지 않은 것입니다: 웹 서비스가 다운되었거나, 방화벽이 거부했거나, 오래된 캐시나 프록시 때문에 기기가 잘못된 주소로 연결한 것입니다.