한 사이트만 ERR_CONNECTION_RESET

다른 사이트는 모두 열리는데 한 사이트만 "사이트에 연결할 수 없음"과 ERR_CONNECTION_RESET으로 계속 실패합니다. 새로 고침해도 그대로입니다. 이 가이드는 의사 결정 트리입니다. 각 단계에서 원인을 찾거나 원인 하나를 배제하며, 순서는 가장 빠른 확인에서 가장 많은 것을 알려 주는 확인으로 나아갑니다.

"연결 재설정"이 실제로 뜻하는 것

TCP 연결은 정중하게 끝날 수도 있고, 리셋 패킷(RST)으로 즉시 끊길 수도 있습니다. Chrome 및 다른 Chromium 브라우저는 페이지가 전달되기 전에 리셋이 도착하면 ERR_CONNECTION_RESET을 표시합니다. Firefox도 비슷한 "연결이 재설정되었습니다" 페이지를 보여 줍니다. 리셋은 사이트의 서버에서, 사용자 컴퓨터의 소프트웨어에서, 또는 두 끝 중 하나인 척하는 네트워크 중간의 장비에서 올 수 있습니다.

그래서 같은 오류라도 원인이 이렇게 다양합니다. 요령은 누가, 언제 리셋을 보냈는지 알아내는 것입니다.

1단계: 정말 한 사이트뿐인가요?

자주 가지 않는 사이트를 포함해 관련 없는 사이트를 두세 개 열어 보세요. 여러 개가 실패한다면 문제는 그 한 사이트가 아니라 회선, 공유기, 기기입니다. 공유기를 재시작하고 같은 네트워크의 다른 기기가 되는지 확인하세요. 한 사이트만 실패한다면 계속 진행하세요.

2단계: 한 네트워크에서만 그런가요?

가장 많은 것을 알려 주는 테스트이며, 비용도 들지 않습니다. Wi-Fi 대신 모바일 데이터로 사이트를 열거나, 노트북을 휴대폰에 테더링하세요. 한 네트워크에서는 열리고 다른 네트워크에서는 리셋된다면, 실패하는 네트워크가 관련되어 있습니다. 흔한 원인은 왜 사이트가 모바일 데이터에서는 열리고 Wi-Fi에서는 안 열릴까요?에서 다룹니다. 어디서나 실패한다면 사이트 자체나 기기가 원인일 가능성이 더 큽니다.

3단계: 다른 브라우저, 시크릿 창, 확장 프로그램 끄기

대부분의 확장 프로그램이 기본적으로 꺼지는 비공개 창이나 시크릿 창에서 시도해 보세요. 그다음 다른 브라우저로 시도하세요. 광고 차단기, 개인정보 보호 확장 프로그램, "세이프 브라우징" 부가 기능, 회사 브라우저 정책은 모두 연결을 닫을 수 있습니다. 시크릿 창에서 사이트가 열린다면, 오류가 다시 나타날 때까지 확장 프로그램을 하나씩 다시 켜 보세요.

4단계: 다른 VPN, 프록시, HTTPS 검사 끄기

트래픽 경로에 있는 것은 무엇이든 마음에 들지 않는 연결을 리셋할 수 있습니다.

• 다른 VPN이나 프록시 앱. 완전히 끄고 다시 테스트하세요.
• 백신의 "HTTPS 검사"나 "웹 보호". 일부 보안 제품은 암호화된 트래픽을 검사하고 위험하다고 판단한 연결을 끊습니다. 테스트를 위해 그 기능을 잠시 멈췄다가 다시 켜세요.
• 시스템 프록시. Windows에서는 설정 → 네트워크 및 인터넷 → 프록시를 확인하세요. macOS에서는 시스템 설정 → 네트워크 → 사용 중인 연결 → 세부사항 → 프록시를 확인하세요. 모르는 프록시나 예전 앱이 남긴 프록시가 특정 사이트만 망가뜨릴 수 있습니다. 직접 설정했다고 확실히 아는 것만 제거하고, 관리되는 컴퓨터라면 IT 팀에 문의하세요.

5단계: DNS 캐시를 지우고 암호화 DNS 시도하기

사이트가 서버를 옮겼다면 기기가 아직 예전 주소를 쓰고 있어서 리셋이나 시간 초과가 날 수 있습니다. 캐시를 지우세요.

# Windows (Command Prompt)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Chrome's own cache: open chrome://net-internals/#dns and click "Clear host cache"

다음으로 네트워크의 응답과 독립적인 리졸버의 응답을 비교합니다. nslookup example.com을 실행한 다음 nslookup example.com 1.1.1.1을 실행하세요. 결과가 다르고 독립적인 응답만 동작한다면 네트워크의 DNS가 문제입니다. 이런 종류의 차단은 DoH와 DoT에서 설명하듯 암호화 DNS로 해결됩니다. 다만 큰 사이트는 네트워크마다 다른 서버를 알려 주므로, 주소가 다르다는 것만으로는 증거가 되지 않습니다.

6단계: 날짜와 시간 확인하기

시계가 틀리면 보통 리셋보다는 인증서 오류가 나지만, 10초면 확인할 수 있습니다. 자동 날짜 및 시간을 켜고 새로 고침하세요. 실패하는 페이지를 "통과"하려고 인증서 경고를 클릭해 넘어가는 일은 절대 하지 마세요.

7단계: 사이트가 다운되었나요?

사이트의 상태 페이지나 공식 소셜 계정을 확인하거나, 공개된 "모두에게 안 되는지, 나만 안 되는지" 확인 도구를 쓰세요. 사이트가 다운되었다면 기다리세요. 확인 도구는 자체 서버에서 테스트하므로, 거기서 "정상"이라고 해도 사용자의 네트워크에서 접속된다는 증거는 아니라는 점을 기억하세요.

8단계: curl로 리셋 읽기

여전히 한 네트워크에서만 사이트가 리셋된다면 핸드셰이크 자체를 살펴보세요. curl은 Windows 10과 11, macOS, 대부분의 Linux 시스템에 내장되어 있습니다. example.com 대신 해당 사이트를 넣어 터미널에서 실행하세요.

curl -v https://example.com

정상적인 연결은 다음과 같은 줄 몇 개를 출력한 뒤 페이지 헤더를 보여 줍니다. 정확한 문구는 curl 버전과 TLS 라이브러리에 따라 다릅니다.

*   Trying 203.0.113.10:443...
* Connected to example.com (203.0.113.10) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
...
< HTTP/2 200

이름 기반 필터링을 가리키는 패턴은 다음과 같습니다.

*   Trying 203.0.113.10:443...
* Connected to example.com (203.0.113.10) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer

한 줄씩 읽어 보세요. "Connected"는 서버 IP 주소로의 TCP 연결이 성공했다는 뜻이므로, 주소 자체가 완전히 차단된 것은 아닙니다. "Client hello"는 첫 TLS 메시지이며, SNI라는 필드에 사이트 이름을 평문으로 담고 있습니다. 그 직후의 "Connection reset by peer"는 그 이름이 보이자마자, 서버가 응답하기 전에 무언가가 연결을 끊었다는 뜻입니다. 일부 네트워크는 대신 조용히 연결을 닫는데, curl은 이를 예상치 못한 파일 끝이나 SSL "syscall" 오류로 보고하고, Chrome은 ERR_CONNECTION_CLOSED를 표시할 수 있습니다.

다른 결과와 비교해 보세요.

근거를 강화하려면 다른 네트워크에서 같은 명령을 실행하세요. 거기서 된다면 필터는 첫 번째 네트워크의 것입니다. 이것은 드문 상황에 대한 추측이 아닙니다. 2020년 OONI와 Centre for Internet and Society의 연구는 Bharti Airtel에서 특정 사이트에 대한 TLS 연결이 ClientHello 직후에 끊기고, Reliance Jio에서는 SNI와 목적지 주소의 조합으로 끊기는 것을 확인했습니다. CIS는 별도로 Jio가 SNI 검사를 사용한다고 보고했고, 그 보고는 ntc.party 포럼에서도 논의되었습니다. 더 많은 배경 지식: 웹사이트가 차단되었는지 확인하는 방법.

GreenTunnel이 도움이 되는 경우와 아닌 경우

GreenTunnel은 저희가 만드는 기기 내 로컬 VPN이므로, 이 부분은 저희가 편향되어 있다는 점을 알고 읽어 주세요. 위 원인 중 두 가지를 대상으로 합니다.

• SNI 필터링. 연결의 첫 TLS 패킷 모양을 바꿉니다. 예를 들어 Client hello나 그 TLS 레코드를 분할해, 사이트 이름을 찾는 필터가 이름을 한 덩어리로 찾지 못하게 합니다. 원리: SNI, DPI, TLS 레코드 분할.
• DNS 차단. 조회가 암호화 DNS(DoH 또는 DoT)로 Cloudflare, Google, Quad9에 전달되므로, 네트워크가 조용히 가짜 응답을 돌려줄 수 없습니다.

URL 검사 도구는 현재 네트워크에서 한 사이트에 대해 5단계와 8단계의 비교를 실행하고, 사이트가 이름으로 필터링되는지, 가짜 DNS 응답을 받는지, IP 주소로 차단되는지, 문제없는지 알려 줍니다. 동작하는 기법이 있으면 이 기법 사용을 탭할 수 있습니다.

다음과 같은 경우에는 도움이 되지 않습니다.

• 사이트가 다운되었거나, 리셋이 사이트 자체 서버나 보호 서비스에서 오는 경우,
• IP 주소로 차단된 경우로, "Trying"에서의 시간 초과로 나타납니다,
• 회사, 학교, 기타 관리되는 네트워크가 의도적으로 사이트를 차단하는 경우. 그 네트워크의 규칙은 소유자가 정합니다. 정책을 존중하고, 업무에 접근이 필요하다면 관리자에게 요청하세요,
• 원인이 내 기기의 확장 프로그램, 백신, 오래된 DNS인 경우. 그것들은 직접 고치세요.

솔직한 한계와 책임 있는 사용

GreenTunnel은 IP 주소를 숨기지 않으며 익명화 도구가 아닙니다. IP 차단, 인터넷 차단, 허용 목록을 우회할 수 없고, 특정 사이트가 열린다고 약속하지도 않습니다. 필터는 시간에 따라 바뀌고 ISP마다 다르므로, 오늘의 결과가 다음 달에는 다를 수 있습니다.

자주 묻는 질문

ERR_CONNECTION_RESET은 항상 사이트가 차단되었다는 신호인가요?

아니요. 확장 프로그램, 백신의 HTTPS 검사, 남아 있는 프록시, 오래된 DNS, 사이트 자체 모두 원인이 될 수 있습니다. 리셋이 한 네트워크에서, Client hello 직후에 일어나고, 다른 곳에서는 사이트가 열릴 때만 차단일 가능성이 높아집니다.

왜 모바일 데이터에서는 열리고 Wi-Fi에서는 리셋되나요?

두 네트워크는 서로 다른 통신사, 리졸버, 필터를 씁니다. 둘 중 하나가 사이트 이름을 읽거나 DNS에 다르게 응답할 수 있습니다. 양쪽에서 curl -v를 실행해 각각 어디서 멈추는지 비교하세요.

쿠키를 지우면 연결 재설정이 해결되나요?

거의 그렇지 않습니다. 쿠키는 연결이 성립된 후에 전송되지만, 대부분의 리셋은 그 전에 일어납니다. 사이트 데이터 삭제는 사이트 자체가 잘못된 세션을 거부할 때 도움이 되며, 그 경우에는 보통 대신 HTTP 오류가 표시됩니다.

회사 방화벽 때문에 생긴 리셋을 GreenTunnel로 해결할 수 있나요?

그런 용도가 아닙니다. 관리되는 네트워크는 소유자의 정책에 따라 사이트를 차단합니다. 우회하려 하지 말고 관리자에게 문의하세요.

출처

• OONI와 Centre for Internet and Society, Investigating TLS blocking in India, 2020년 7월.
• Centre for Internet and Society, Reliance Jio is using SNI inspection to block websites.
• ntc.party 포럼, SNI filtering by Indian ISP Reliance Jio.
• curl 프로젝트, curl 매뉴얼(-v 옵션).