ERR_CONNECTION_REFUSED: 원인과 해결 방법

오류의 의미

브라우저가 서버의 주소를 찾아 443 포트(또는 80 포트)로 연결 요청을 보냈고, 서버가 “아니요”라고 응답했습니다. 해당 포트에서 대기 중인 프로그램이 없을 때 운영 체제가 보내는 TCP 리셋입니다. Chrome은 ERR_CONNECTION_REFUSED(“이 사이트에 연결할 수 없음”), Firefox는 “Unable to connect”, Safari는 “Safari에서 서버에 연결할 수 없음”으로 표시합니다.

이것은 시간 초과(아무 응답도 없음, 보통 패킷을 버리는 방화벽이나 꺼진 서버)나 DNS_PROBE_FINISHED_NXDOMAIN(이름이 확인되지 않음)과는 다릅니다. 연결 거부는 머신은 켜져 있고 접속할 수 있지만 그 위의 웹 서버가 실행 중이 아니거나, 다른 포트나 주소에서 대기 중이거나, 패킷을 버리지 않고 거부하는 방화벽에 막혀 있다는 뜻입니다.

흔한 원인

1. 웹 서버가 중지되었습니다. nginx나 Apache가 비정상 종료되었거나, 설정 변경 후 시작에 실패했거나, 업데이트로 중지되었습니다. 단연 가장 흔한 원인입니다.
2. 웹 서버가 잘못된 주소나 포트에서 대기합니다. listen 지시문을 변경한 후 nginx가 127.0.0.1에만, 또는 IPv4에만 바인딩되는데 DNS 레코드는 IPv6 주소를 가리키는 경우입니다.
3. 방화벽이 포트를 거부합니다. ufw, firewalld 또는 클라우드 보안 그룹에 80/443에 대한 reject 규칙이 있는 경우이며, 누군가 서버를 “보안 강화”한 후에 자주 발생합니다.
4. 웹 서버가 없는 새 서버. DNS 레코드가 이미 새 IP를 가리키는데 nginx가 설치되지 않았거나 아직 시작되지 않았습니다.
5. HTTPS가 설정되지 않았습니다. 80 포트는 작동하지만 443 포트에는 대기 중인 프로그램이 없고, 브라우저(또는 HSTS 항목)가 HTTPS를 고집합니다.
6. 방문자 쪽의 로컬 원인. 죽은 프록시를 가리키는 프록시 설정, VPN, 백신의 “웹 실드”, hosts 파일 항목, 브라우저 확장 프로그램.

방문자인 경우

1. 시크릿 창과 다른 브라우저에서 사이트를 시도해 보세요. 확장 프로그램과 캐시를 배제할 수 있습니다.
2. 프록시 설정을 확인하세요. Windows “프록시 설정”, macOS 네트워크 > 고급 > 프록시. 사용하지 않는 수동 프록시는 끄세요.
3. VPN과 백신의 웹 보호를 잠시 끄세요.
4. 이전한 사이트의 예전 주소가 캐시에 남아 있을 수 있으니 DNS를 비우세요(ipconfig /flushdns, sudo dscacheutil -flushcache).
5. https:// 대신 http://를 한 번 시도해 보세요. 그것이 작동하면 사이트의 HTTPS가 고장 난 것이며 소유자가 해결해야 합니다.

직접 운영하는 사이트라면: 먼저 확인할 것

웹사이트 다운 확인 도구를 실행하세요. 외부에서 “Connection refused”가 나오면 서버 자체가 거부하는 것이 확인됩니다. 그런 다음 SSH로 로그인하세요(웹사이트는 거부하는데 SSH가 작동한다면 그 자체로 강력한 단서입니다. 서버는 켜져 있고 웹 서버가 꺼져 있는 것입니다).

# 웹 서버가 실행 중인가?
systemctl status nginx
systemctl status apache2

# 80과 443에서 무엇이 대기 중인가?
sudo ss -tlnp | grep -E ':80 |:443 '

# 방화벽 규칙
sudo ufw status verbose
sudo firewall-cmd --list-all
sudo nft list ruleset | grep -E 'dport (80|443)'

ss에서 443에 아무것도 나타나지 않으면 웹 서버가 다운되었거나 443에 대해 설정되지 않은 것입니다. 0.0.0.0:443이나 *:443 대신 127.0.0.1:443이 나타나면 로컬에서만 대기하는 것입니다.

직접 운영하는 서버에서의 해결 방법

1. 웹 서버를 시작하고 중지된 이유 확인

sudo systemctl start nginx
systemctl status nginx
sudo journalctl -u nginx -n 50

시작에 실패한다면 이유는 거의 항상 다음 중 하나입니다.

• nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use): 다른 프로그램이 포트를 점유하고 있습니다(Apache와 nginx가 모두 설치되었거나 오래된 프로세스). sudo ss -tlnp | grep :80이 이름을 알려 주니 원하지 않는 쪽을 중지하세요.
• [emerg] unknown directive 또는 unexpected "}": 설정 파일의 구문 오류입니다. sudo nginx -t가 파일과 줄을 출력합니다.
• cannot load certificate: 인증서 파일이 삭제되었거나 다른 경로로 갱신되었습니다. ssl_certificate 줄을 디스크에 있는 파일과 비교하세요.
• Too many open files 또는 가득 찬 디스크: df -h, df -i.

Apache: sudo apachectl configtest, 그다음 sudo journalctl -u apache2 -n 50. 같은 범주가 적용되며, AH00558(서버 이름을 확인할 수 없음)은 경고일 뿐 원인이 아닙니다.

다시 불러오기 전에 항상 테스트하고, 가능하면 재시작 대신 다시 불러오기를 사용하세요.

sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

2. 올바른 주소에서 대기하기

nginx 서버 블록에서 IPv4와 IPv6 모두를 위해 다음 두 가지가 필요합니다.

listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;

DNS에 AAAA 레코드가 있는데 서버가 IPv6에서 대기하지 않거나(또는 IPv6 연결이 없거나) 하면, IPv6 방문자는 연결 거부를 받고 나머지는 모두 정상입니다. 대기하도록 설정하거나 AAAA 레코드를 제거하세요.

3. 방화벽 열기

# ufw (Debian/Ubuntu)
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# firewalld (RHEL 계열)
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload

클라우드 서버에서는 제어판에서 제공업체의 보안 그룹이나 네트워크 방화벽도 확인하세요. 그곳의 규칙은 서버 내부에서는 보이지 않습니다.

4. 80 포트만 응답한다면 HTTPS 설정

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Certbot이 443 서버 블록과 리디렉션을 추가합니다. 그런 다음 SSL 검사 도구로 체인이 완전한지 확인하세요.

5. 서버 이전 후

DNS를 변경하기 전에 새 머신의 웹 서버가 설치되고, 도메인에 맞게 설정되고, 시작되어 있는지 확인하세요. 이미 변경했다면 지금 설치하고 시작하거나, 새 서버가 준비될 때까지 레코드를 이전 서버로 되돌리세요.

호스팅 업체의 문제인 경우

공유 호스팅에서 연결 거부는 호스팅 업체의 웹 서버가 해당 노드에서 다운되었거나, DNS를 업데이트하지 않고 새 IP로 옮겼다는 뜻입니다. 다음 내용을 보내세요.

안녕하세요. 제 웹사이트 example.com이 약 20:15 UTC부터 80과 443 포트에서 “connection refused”를 반환합니다. 도메인은 203.0.113.10으로 확인됩니다. 제 계정에서는 아무것도 변경하지 않았습니다. 해당 머신의 웹 서버가 다운되었나요, 아니면 제 사이트가 다른 주소로 이전되었나요?

다음번을 막으려면

연결 거부는 거의 항상 중지된 웹 서버이며, 중지된 서비스는 외부에서 하는 포트 확인과 웹사이트 확인이 1분 안에 알아차리는 바로 그것입니다. 직접 운영하는 서버에서는 서버 에이전트가 nginx나 Apache가 중지되면 알림을 보내고, Quick Fix가 설정 테스트를 통과한 후 고정 가격으로 재시작합니다. 새벽 3시에 아무도 로그인할 필요가 없습니다. 설정 자체가 망가졌다면 Deep Fix가 수리합니다.