ERR_CONNECTION_REFUSED: '연결을 거부했습니다' 원인과 해결 방법

ERR_CONNECTION_REFUSED란 무엇인가요?

ERR_CONNECTION_REFUSED는 브라우저가 웹사이트의 IP 주소는 찾았지만, 그 주소의 머신이 연결을 거부했다는 뜻입니다. Chrome은 “사이트에 연결할 수 없음”과 함께 “example.com에서 연결을 거부했습니다.”라는 문구와 ERR_CONNECTION_REFUSED 코드를 표시합니다. Chromium 오류 목록의 -102번 오류입니다(net_error_list.h).

기기가 서버의 IP 주소와 포트(HTTPS는 443, HTTP는 80)로 TCP 연결 요청을 보냈고, 곧바로 거부 응답을 받았습니다. 응답은 TCP 리셋이거나 방화벽이 보내는 “port unreachable(포트 도달 불가)” 메시지입니다. 즉 해당 포트에서 연결을 받는 프로그램이 없었거나, 방화벽이 요청을 거부한 것입니다. DNS는 성공했고, 실패한 것은 연결입니다.

다시 말해 침묵이 아니라 거절이라는 응답입니다. 아무것도 응답하지 않으면 Chrome은 기다리다가 ERR_CONNECTION_TIMED_OUT을 표시합니다. 연결이 열린 뒤 끊기면 ERR_CONNECTION_RESET, 서버가 페이지를 보내기 전에 연결을 닫으면 ERR_CONNECTION_CLOSED입니다.

다른 브라우저와 앱에서는 어떻게 표시되나요?

연결 거부는 어디서나 같은 현상이고 표현만 다릅니다. Chromium 기반 브라우저(Chrome, Edge, Brave, Opera)는 ERR_CONNECTION_REFUSED 코드를 표시하고, 앱은 운영체제의 오류를 그대로 보여 줍니다.

문구가 무엇이든 아래 해결 방법은 똑같이 적용됩니다. 그 주소와 포트에 있는 무언가가 연결을 거절한 것입니다.

ERR_CONNECTION_REFUSED의 일반적인 원인

사이트 쪽 원인부터 내 쪽 원인 순으로 정리하면 다음과 같습니다.

• 웹사이트 서버 다운 — 웹 서버(nginx, Apache, Node.js)가 크래시했거나, 재시작 중이거나, 중지되었습니다. 머신은 켜져 있지만 포트 80이나 443에서 아무것도 응답하지 않습니다.
• 거부(reject)로 설정된 방화벽 — 서버, 내 네트워크 또는 내 기기의 방화벽이 해당 포트로의 연결을 (조용히 버리지 않고) 거부합니다.
• 사이트가 내 네트워크를 차단 — VPN 출구 서버나 특정 국가처럼 주소 대역 전체를 거부하는 사이트가 있습니다.
• 보안 소프트웨어 또는 VPN — 트래픽을 자신을 거쳐 보내는 백신의 웹 보호 기능이나 VPN이 연결을 거부합니다. (내 기기의 방화벽이 Chrome을 차단하면 “인터넷 액세스가 차단됨”(ERR_NETWORK_ACCESS_DENIED)이라는 다른 페이지가 표시됩니다.)
• 잘못된 IP 주소 — 오래된 DNS 캐시나 hosts 파일 항목 때문에 예전 서버나 내 컴퓨터(127.0.0.1)로 연결되는데, 그곳에서는 아무것도 수신 대기하지 않습니다.
• 기억된 리디렉션이나 HTTPS 규칙 — Chrome이 리디렉션이나 사이트의 HSTS 규칙을 캐시해 두고, 사이트가 더 이상 사용하지 않는 포트로 계속 보냅니다.
• localhost에서 수신 대기 중인 것이 없음 — 개발자의 경우: 로컬 서버가 실행 중이 아니거나, 크래시했거나, 연 주소와 다른 포트나 주소에서 실행 중입니다.

한 사이트만? 모든 사이트? 모든 브라우저?

무엇을 바꾸기 전에 오류가 어디서 나타나는지 보면, 어디를 살펴봐야 할지 알 수 있습니다.

“모든 브라우저에서”가 중요한 이유는 Edge, Firefox, Safari가 Chrome의 캐시나 확장 프로그램을 공유하지 않기 때문입니다. 모든 브라우저에서 거부된다면 원인은 브라우저 아래, 즉 기기, 네트워크 또는 사이트 자체에 있습니다.

해결 방법 1: 사이트가 모두에게 다운되었는지 확인

기기에서 무엇을 바꾸기 전에, 사이트가 모두를 거부하고 있는지 먼저 확인하세요. 그렇다면 내 쪽에서 무엇을 해도 소용이 없습니다.

가장 빠른 방법은 다른 네트워크 경로로 접속해 보는 것입니다. 휴대폰에서 Wi-Fi를 끄고 모바일 데이터로 사이트를 열어 보세요. 그다음 아래 DNS Robot 도구로 외부에서 서버를 테스트하세요.

• 사이트 다운 확인 — 전 세계 11곳과 내 브라우저에서 사이트를 엽니다. 모든 곳에서 다운이면 사이트 문제이고, 나를 제외한 모든 곳에서 정상이면 내 쪽 문제입니다.
• 포트 확인 — 사이트와 포트 443을 입력하세요(example.com:443 형식도 됩니다). 닫혀 있으면 서버가 우리 쪽 연결도 거부한 것이고, 열려 있으면 서버는 연결을 받고 있으며 거부는 내 환경에서만 일어나는 것입니다.
• 핑 테스트 — 11개 도시에서 사이트의 포트 443으로 연결하고, 한 곳에서는 일반 ping도 보냅니다. 모든 도시에서 거부되면 머신은 켜져 있지만 그 포트에서 아무것도 수신 대기하지 않는 것입니다. 일반 ping에 응답이 없다고 해서 증명되는 것은 없습니다. 많은 서버가 ping을 무시하기 때문입니다.

해결 방법 2: 라우터와 기기 재시작

Chrome이 가장 먼저 제안하는 “연결 확인”에서도 “케이블을 확인하고 사용 중인 라우터, 모뎀 또는 기타 네트워크 기기를 재부팅하시기 바랍니다.”라고 안내합니다. 재시작하면 라우터에 쌓인 상태가 DNS 캐시를 포함해 초기화됩니다.

라우터(모뎀이 분리형이라면 모뎀도)의 전원 플러그를 뽑고 30초 기다린 뒤 다시 꽂고, 완전히 재연결될 때까지 2~3분 기다리세요. 컴퓨터나 휴대폰도 재시작해 네트워크 스택을 초기화한 다음 사이트에 다시 접속해 보세요.

해결 방법 3: Chrome에 캐시된 리디렉션과 HTTPS 규칙 삭제

Chrome은 영구 리디렉션과 각 사이트의 HSTS 규칙(“항상 HTTPS 사용”)을 기억합니다. 사이트가 이후 이전했거나 포트 443에서 HTTPS 제공을 중단했다면, Chrome은 아무것도 수신 대기하지 않는 주소나 포트로 계속 보냅니다.

• Chrome을 열고 → 점 세 개 메뉴 → 인터넷 사용 기록 삭제
• 기간 → 전체 기간을 선택하고 캐시된 이미지 및 파일을 체크합니다(쿠키는 그대로 두어도 됩니다)
• 데이터 삭제를 클릭합니다(Chrome에 로그인하지 않았다면 이 기기에서 삭제). 그런 다음 사이트에 다시 접속합니다
• 여전히 거부되나요? chrome://net-internals/#hsts를 열고 “Delete domain security policies”에 도메인을 입력한 뒤 “Delete”를 클릭합니다(이 페이지는 영어로만 표시됩니다). 사이트가 직접 설정한 규칙에만 통하며, Chrome에 내장된 HSTS 사전 로드 목록의 도메인에는 적용되지 않습니다.

2026년의 변경 사항: Chrome 154(2026년 10월)부터 “항상 보안 연결 사용”이 기본으로 켜져, HTTPS가 없는 공개 사이트에 처음 방문하기 전에 Chrome이 조용히 시도하는 대신 사용자에게 허락을 구합니다(Google Security Blog).

해결 방법 4: 프록시 설정 확인

Chrome 오류 페이지에 프록시가 나오므로 확인은 해 보되, 결과를 미리 알아 두세요. Chrome이 프록시 서버에 연결하지 못하면 ERR_CONNECTION_REFUSED가 아니라 “인터넷 연결 없음”이라는 제목과 함께 ERR_PROXY_CONNECTION_FAILED(“프록시 서버에 문제가 발생했거나 주소가 잘못되었습니다.”)가 표시됩니다. 그 페이지가 보인다면 이 방법이 해결책입니다.

Windows: 설정 → 네트워크 및 인터넷 → 프록시. 수동 프록시 설정에서 “프록시 서버 사용” 옆의 편집을 클릭하고 끈 다음 저장을 클릭합니다. 모르는 주소라면 “설정 스크립트 사용”도 끄세요. “자동으로 설정 검색”은 내 네트워크에서 쓰지 않는다는 확신이 없다면 켜 두세요.

macOS: 시스템 설정 → 네트워크 → Wi-Fi → 세부사항 → 프록시. 조직에서 설정하지 않은 프록시를 모두 끄고 확인을 클릭합니다.

Chrome은 시스템 프록시 설정을 사용하고 Firefox도 기본값은 같으므로(“시스템 프록시 설정 사용”), 오래된 프록시 하나가 모든 브라우저를 한꺼번에 망가뜨립니다. 학교나 회사 기기에서는 관리자가 프록시를 설정하므로 직접 바꿀 수 없습니다.

해결 방법 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를 플러시하는 방법 가이드를 참조하세요.

내 컴퓨터가 실제로 사용하는 주소(hosts 파일과 캐시 포함)를 보려면 ping example.com을 실행하거나 PowerShell에서 Resolve-DnsName example.com을 실행한 뒤 DNS 조회 결과와 비교하세요. 이 용도로는 nslookup을 쓰지 마세요. nslookup은 DNS 서버에 직접 묻기 때문에 hosts 파일과 캐시를 모두 건너뜁니다.

해결 방법 6: 공용 DNS 서버로 전환

플러시한 뒤에도 ISP의 리졸버가 계속 예전 주소를 준다면 공용 리졸버로 전환해 새 응답을 받으세요.

Windows: 설정 → 네트워크 및 인터넷 → Wi-Fi → 알려진 네트워크 관리 → 사용 중인 네트워크(유선이면 이더넷 → 사용 중인 네트워크) → DNS 서버 할당 옆의 편집 → 수동 → IPv4 켬 → 기본 설정 DNS 1.1.1.1, 대체 DNS 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 주소를 아예 거부하는 사이트도 있습니다.

하나씩 테스트하세요. 먼저 VPN을 끊고 새로고침합니다. 다음으로 백신의 웹 보호를 1분간 일시 중지하고 새로고침합니다. 마지막으로 서드파티 방화벽(백신 제품에 포함된 경우가 많습니다)을 일시 중지합니다. (macOS 방화벽은 들어오는 연결만 걸러 내고, Windows Defender 방화벽은 누군가 규칙을 추가하지 않는 한 나가는 트래픽을 허용합니다. Chrome에 “인터넷 액세스가 차단됨”이 표시되면 내 기기의 방화벽이 원인입니다.)

이 중 하나를 껐을 때 사이트가 열린다면, 다시 켠 뒤 해당 사이트를 예외로 추가하거나 다른 VPN 서버를 선택하세요. 보호 기능을 꺼 둔 채로 두지 마세요.

해결 방법 8: 시크릿 모드에서 확장 프로그램 테스트

확장 프로그램이 이 오류 코드의 원인인 경우는 드뭅니다. 사이트를 차단하는 확장 프로그램이라면 ERR_BLOCKED_BY_CLIENT가 표시됩니다. 그래도 시크릿 창(Ctrl+Shift+N, Mac은 Cmd+Shift+N)은 10초면 끝나는 테스트로, 확장 프로그램과 캐시된 데이터를 한 번에 배제할 수 있습니다. 직접 허용하지 않는 한 시크릿 모드에서는 확장 프로그램이 꺼져 있기 때문입니다.

시크릿 모드에서 사이트가 열린다면 chrome://extensions에서 모두 끈 뒤, 오류가 다시 나타날 때까지 하나씩 켜 보세요. 시크릿 모드에서도 실패한다면 원인은 Chrome 밖에 있습니다.

해결 방법 9: hosts 파일 확인

hosts 파일은 그 안에 적힌 이름에 대해 DNS보다 우선합니다. 사이트가 127.0.0.1이나 예전 서버 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.

해결 방법 10: Android 휴대폰이나 iPhone에서

휴대폰도 같은 이유로 연결을 거부하며, 바꿀 설정만 다릅니다.

• 네트워크 바꿔 보기: 모바일 데이터로 사이트를 연 다음 Wi-Fi로 열어 보세요. 한쪽에서만 거부된다면 휴대폰이 아니라 그 네트워크의 문제입니다.
• VPN 앱 끄기: VPN으로 동작하는 광고 차단기와 방화벽 앱도 포함됩니다(상태 표시줄에 열쇠나 VPN 아이콘이 표시됩니다).
• Wi-Fi 프록시 제거: Android에서는 Wi-Fi 네트워크 설정을 열고 → 연필 아이콘 → 고급 옵션 → 프록시 → 없음으로 설정합니다(제조사마다 표현이 다릅니다). iPhone에서는 설정 → Wi-Fi → 네트워크 옆의 ⓘ → 프록시 구성 → 끔.
• Chrome 데이터 삭제: Chrome → 설정 → 개인 정보 보호 및 보안 → 인터넷 사용 기록 삭제 → 캐시된 이미지 및 파일.
• 내 서버를 테스트 중인가요? 휴대폰에서 localhost는 휴대폰 자신입니다. 대신 컴퓨터의 로컬 IP 주소를 사용하세요(다음 섹션 참고).

localhost에서 연결을 거부했습니다 (개발자용)

localhost에서 연결을 거부했습니다(localhost refused to connect)나 127.0.0.1에서의 ERR_CONNECTION_REFUSED는, 연 주소와 포트에서 내 컴퓨터의 어떤 프로그램도 연결을 받지 않는다는 뜻입니다. 흔한 이유는 다음과 같습니다.

• 개발 서버가 실행 중이 아님 — 시작하지 않았거나 크래시했습니다. npm run dev, rails s, python manage.py runserver가 실행 중이어야 할 터미널을 확인하세요.
• 잘못된 포트 — 서버가 다른 포트에서 시작되었습니다(예: 3000이 사용 중이라 3001). 시작할 때 출력되는 줄에서 주소를 복사하세요.
• 주소에 포트가 없음 — http://localhost는 포트 80으로 가지만, 개발 서버는 자체 포트(3000, 5173, 8000, 8080)를 사용합니다.
• 127.0.0.1과 [::1] — 브라우저는 localhost에 대해 두 주소를 모두 시도하지만, 서버는 그중 하나에서만 수신 대기할 수 있습니다. 다른 주소를 직접 열거나(http://127.0.0.1:3000 또는 http://[::1]:3000) 한 주소만 시도하는 도구로 연결하면 거부됩니다.
• Docker 안에서 실행 — 앱은 컨테이너 안에서 0.0.0.0으로 수신 대기해야 하고 포트를 게시해야 합니다(-p 3000:3000). 컨테이너 안에서 127.0.0.1에 바인딩된 앱에는 내 컴퓨터에서 접속할 수 없습니다(대신 ERR_EMPTY_RESPONSE가 표시될 수도 있습니다).
• 휴대폰이나 에뮬레이터에서 접속 — 그곳에서 localhost는 그 기기 자신입니다. 컴퓨터의 LAN IP를 사용하고 개발 서버를 모든 인터페이스에서 시작하거나(Vite: --host), Android Emulator에서는 컴퓨터의 localhost를 가리키는 별칭 10.0.2.2를 사용하세요.

# What is listening on port 3000?
# macOS / Linux:
lsof -nP -iTCP:3000 -sTCP:LISTEN

# Windows (PowerShell):
netstat -ano | findstr :3000 | findstr LISTENING

# No output = nothing is listening = connection refused.
# 127.0.0.1:3000 in the output = IPv4 only; [::1]:3000 = IPv6 only.

공용 서버의 포트가 인터넷에서 도달 가능한지(머신 자체에서만이 아니라 외부에서) 확인해야 한다면 DNS Robot의 포트 확인 도구를 사용하세요 — 네트워크 외부에서 연결을 테스트하며, 이것이 방문자가 실제로 경험하는 것입니다.

삽입된 페이지 안에 “연결을 거부했습니다”가 표시될 때

다른 페이지 안의 상자(삽입된 양식, 보고서, 지도, 로그인 창 등)에 “example.com에서 연결을 거부했습니다.”가 나타난다면, 대개 네트워크 문제가 아닙니다. 삽입된 사이트가 X-Frame-Options 또는 Content-Security-Policy: frame-ancestors 헤더로 다른 사이트의 페이지 안에 표시되는 것을 금지할 때도 Chrome은 같은 문장을 표시합니다. 내부적으로는 ERR_BLOCKED_BY_RESPONSE, 오류 -27입니다(net_error_list.h).

방문자라면 삽입된 링크를 새 탭에서 열면 표시됩니다. 사이트 운영자라면 내 사이트를 삽입하는 페이지를 Content-Security-Policy: frame-ancestors 'self' https://parent.example로 허용하세요. X-Frame-Options로는 DENY 또는 SAMEORIGIN만 지정할 수 있고, 두 헤더를 모두 보내면 현재 브라우저는 frame-ancestors를 따릅니다. 내 사이트가 무엇을 보내는지는 HTTP 헤더 검사로 확인하고, 정확한 헤더는 X-Frame-Options 가이드를 참고하세요.

웹사이트 소유자용: 내 사이트가 연결을 거부할 때

방문자들이 내 사이트에서 ERR_CONNECTION_REFUSED를 보고한다면, 패킷은 내 IP의 머신까지 도달하지만 그곳에서 연결을 받는 것이 없는 상태입니다. 다음 체크리스트를 확인하세요.

• 웹 서버가 실행 중인가? SSH로 접속해 systemctl status nginx(또는 apache2, caddy)를 확인하세요. 깨진 설정으로 재시작하다가 시작에 실패했거나 메모리 부족으로 종료된 서버는 수신 대기하는 것이 없는 상태를 남깁니다. sudo systemctl restart nginx로 재시작하세요.
• 올바른 포트와 주소에서 수신 대기 중인가? ss -tlnp | grep -E ':(80|443) '를 실행하세요. 127.0.0.1에서만 수신 대기하는 서버는 외부의 모든 연결을 거부합니다. 443에서 아무것도 수신 대기하지 않는다면 그 포트에서 수신하는 server 블록이 없는 것입니다(HTTPS를 설정하지 않았거나 사이트 설정 파일이 활성화되지 않음). nginx -T는 실제로 로드된 구성을 출력합니다.
• 방화벽이 거부하고 있는가? 거부로 설정된 규칙(iptables REJECT, ufw reject)은 거부 응답을 보냅니다. ufw의 기본 deny와 AWS 보안 그룹 같은 클라우드 방화벽은 대신 패킷을 조용히 버리므로, 방문자에게는 ERR_CONNECTION_TIMED_OUT으로 보입니다.
• fail2ban이 누군가를 차단했는가? 기본 차단은 차단된 주소를 거부하므로, 그 방문자(또는 SSH 로그인에 몇 번 실패한 나 자신)는 ERR_CONNECTION_REFUSED를 보고 다른 사람은 정상적으로 접속합니다. sudo fail2ban-client status로 확인하세요.
• 서버 IP가 바뀌었는가? DNS 조회로 A 레코드와 서버의 실제 IP를 비교하세요. 마이그레이션 후 남은 예전 A 레코드는 방문자를 이전 머신으로 보냅니다.
• Cloudflare를 사용 중인가? 프록시(주황색 구름)로 설정된 레코드에서는 방문자가 내 서버가 아니라 Cloudflare에 연결하므로 이 코드를 보지 않습니다. 원본 서버가 Cloudflare의 연결을 거부하면 Cloudflare는 자체 오류인 Error 521: Web server is down을 표시합니다.
• 외부에서 테스트: 포트 80과 443은 포트 확인으로, 공용 인터넷에서 보낸 실제 요청은 HTTP 헤더 검사로 확인하세요.

해결되었는지 확인하는 방법

각 해결 방법을 적용한 후에는 페이지 새로고침만 하지 말고 네트워크 수준에서 연결을 확인하세요 — 포트가 실제로 열렸는지 알 수 있습니다.

# Test the TCP connection directly (Mac/Linux):
nc -zv -w 5 example.com 443
# "succeeded" = port open, "refused" = still rejected

# Windows (PowerShell):
Test-NetConnection example.com -Port 443
# TcpTestSucceeded : True = fixed

# Then confirm the address your computer actually uses:
ping -c 1 example.com          # Mac/Linux
Resolve-DnsName example.com    # Windows PowerShell

터미널 없이 확인하려면 DNS Robot의 포트 확인에 도메인과 포트를 넣어 내 네트워크 밖에서 본 열림/닫힘 결과를 받으세요. 외부에서는 포트가 열려 있는데 브라우저에 계속 ERR_CONNECTION_REFUSED가 표시된다면 차단 요인은 내 기기나 네트워크에 있습니다. VPN, 보안 소프트웨어, hosts 파일 해결 방법으로 돌아가세요.