
증상과 점검 방향
Windows 11에서 인터넷 연결은 정상인데 특정 웹사이트만 열리지 않는 경우가 있습니다.
예를 들어 이런 상황입니다.
- Google이나 YouTube는 정상적으로 열림
- 특정 회사 사이트나 서비스만 접속 실패
- 브라우저를 바꿔도 동일한 사이트만 열리지 않음
ERR_CONNECTION_TIMED_OUT, 인증서 오류, DNS 오류 등이 표시됨- 다른 PC나 스마트폰에서는 해당 사이트가 정상적으로 열림
이 문제는 단순한 “인터넷이 안 된다”는 상황과는 점검 방법이 다릅니다.
특정 사이트만 열리지 않는다면 다음 순서로 원인을 좁혀 가는 편이 효율적입니다.
사이트 자체 장애 확인
↓
DNS 이름 해석
↓
TCP 443 연결
↓
Proxy / VPN
↓
hosts 파일
↓
TLS / 인증서
↓
보안 프로그램·방화벽
처음부터 네트워크 초기화를 실행하면 원인 파악이 어려워질 수 있습니다. 먼저 어느 단계에서 통신이 실패하는지 확인하는 것이 중요합니다.
먼저 다른 환경에서도 동일한지 확인
먼저 문제가 PC에 있는지, 웹사이트 자체에 있는지 구분합니다.
다음 세 가지를 확인합니다.
- 다른 브라우저에서 접속
- 스마트폰 모바일 데이터로 접속
- 다른 PC에서 동일 URL 접속
예를 들어 스마트폰 LTE/5G에서는 정상인데 같은 Wi-Fi에 연결한 PC에서만 실패한다면 로컬 PC 또는 네트워크 설정을 의심할 수 있습니다.
반대로 여러 네트워크와 장치에서 모두 접속되지 않는다면 사이트 자체에 장애가 있을 가능성이 있습니다.
브라우저 확장 프로그램의 영향을 배제하려면 시크릿 또는 InPrivate 창에서도 한 번 확인해 보는 것이 좋습니다.
DNS가 정상적으로 주소를 찾는지 확인
도메인 이름으로 사이트에 접속하려면 DNS가 먼저 도메인을 IP 주소로 변환해야 합니다.
PowerShell을 열고 다음 명령을 실행합니다.
Resolve-DnsName example.com
example.com 부분에는 실제 접속되지 않는 도메인을 입력합니다.
정상이라면 다음과 같이 IP 주소가 반환됩니다.
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
example.com A ... Answer 93.184.216.34
반대로 이름을 찾지 못하거나 DNS 관련 오류가 발생했다면 아직 HTTPS나 브라우저 문제를 확인할 단계가 아닙니다.
DNS 캐시 초기화
DNS 결과가 이상하거나 최근 사이트의 서버 주소가 바뀐 것으로 의심된다면 관리자 권한 명령 프롬프트에서 다음 명령을 실행할 수 있습니다.
ipconfig /flushdns
정상적으로 처리되면 DNS Resolver Cache가 초기화됩니다.
그 후 다시 확인합니다.
Resolve-DnsName example.com
DNS 서버를 Google DNS나 Cloudflare DNS로 무작정 변경하기보다 현재 DNS에서 이름 해석이 실패하는지 먼저 확인하는 편이 좋습니다.
TCP 443 포트까지 연결되는지 확인
DNS에서 IP가 정상적으로 확인됐다면 다음으로 서버의 HTTPS 포트까지 TCP 연결이 되는지 확인합니다.
PowerShell에서 다음 명령을 실행합니다.
Test-NetConnection example.com -Port 443
확인해야 할 핵심 값은 다음입니다.
TcpTestSucceeded : True
True인 경우
DNS 정상
TCP 443 정상
기본 네트워크 연결은 성공한 상태입니다.
이 경우에는 다음 단계인 Proxy, TLS, 인증서 또는 브라우저 계층을 확인하는 것이 좋습니다.
False인 경우
TcpTestSucceeded : False
라면 다음 원인을 확인해야 합니다.
- 방화벽 차단
- VPN 경로 문제
- 보안 프로그램 차단
- 회사·학교 네트워크 정책
- 목적지 서버의 443 포트 문제
- ISP 또는 중간 네트워크 경로 문제
이 상태에서는 브라우저 캐시만 반복해서 삭제해도 해결되지 않을 가능성이 높습니다.
curl.exe로 HTTP 응답 확인
TCP 443까지 정상인데 브라우저에서만 문제가 발생한다면 Windows에 포함된 curl.exe로 한 번 더 확인할 수 있습니다.
curl.exe -I https://example.com
정상적인 웹 서버라면 HTTP 응답을 확인할 수 있습니다.
HTTP/1.1 200 OK
또는 리다이렉트가 있다면:
HTTP/1.1 301 Moved Permanently
HTTP/1.1 302 Found
등이 나타날 수 있습니다.
curl.exe에서도 연결에 실패한다면 브라우저 자체 문제보다 네트워크·Proxy·TLS 계층을 먼저 확인합니다.
Windows Proxy 설정 확인
특정 사이트 접속 문제에서는 의도하지 않았던 Proxy 설정도 확인할 필요가 있습니다.
관리자 권한 명령 프롬프트에서 다음 명령을 실행합니다.
netsh winhttp show proxy
직접 연결 상태라면 일반적으로 다음과 비슷하게 표시됩니다.
Direct access (no proxy server).
반대로 사용자가 설정하지 않은 Proxy 주소가 표시된다면 그 원인을 확인해야 합니다.
예:
Proxy Server(s) : 192.168.0.10:8080
회사나 조직에서 사용하는 PC라면 Proxy가 정상적인 정책일 수 있으므로 임의로 삭제해서는 안 됩니다.
개인 PC에서 Proxy를 사용하지 않는데 예상치 못한 값이 설정되어 있다면 설정 경로부터 확인합니다.
Windows에서는:
설정 → 네트워크 및 인터넷 → 프록시
에서도 Proxy 상태를 확인할 수 있습니다.
WinHTTP Proxy를 초기화하는 명령도 있지만, 원인을 확인하기 전에 바로 실행하는 것은 권장하지 않습니다.
netsh winhttp reset proxy
이 명령은 현재 Proxy가 불필요하다고 확인한 경우에만 사용하는 것이 좋습니다. Microsoft는 netsh winhttp를 통해 현재 WinHTTP Proxy를 조회하거나 초기화할 수 있도록 안내합니다. (Microsoft Learn)
hosts 파일에 해당 사이트가 등록되어 있는지 확인
Windows의 hosts 파일에 특정 도메인이 수동으로 등록되어 있으면 DNS보다 hosts 파일의 값이 먼저 적용될 수 있습니다.
PowerShell에서 다음 명령으로 내용을 확인할 수 있습니다.
Get-Content "$env:SystemRoot\System32\drivers\etc\hosts"
예를 들어 이런 항목이 있다면 주의해야 합니다.
127.0.0.1 example.com
또는:
192.168.0.20 example.com
실제 서버가 아닌 IP에 도메인이 연결되어 있다면 특정 사이트만 접속되지 않을 수 있습니다.
hosts 파일은 일부 개발 환경, 광고 차단 도구, 테스트 프로그램에서 수정하기도 하므로 사용자가 직접 추가한 항목이 있는지도 확인합니다.
내용을 수정해야 한다면 기존 파일을 백업한 뒤 관리자 권한으로 작업하는 편이 안전합니다.
TLS와 인증서 문제 확인
DNS와 TCP 443까지 정상인데 HTTPS 사이트만 접속에 실패한다면 TLS 단계도 확인해야 합니다.
대표적인 증상은 다음과 같습니다.
인증서가 신뢰되지 않음
TLS handshake 실패
ERR_SSL_PROTOCOL_ERROR
ERR_CERT_AUTHORITY_INVALID
보안 연결을 설정할 수 없음
Windows에서는 TLS 통신에 Schannel이 사용되는 경우가 많고, 관련 오류가 System 이벤트 로그에 기록될 수 있습니다.
이벤트 뷰어에서:
Windows 로그
→ 시스템
→ 원본(Source): Schannel
을 확인합니다.
PowerShell에서도 최근 Schannel 이벤트를 확인할 수 있습니다.
Get-WinEvent -FilterHashtable @{
LogName='System'
ProviderName='Schannel'
} -MaxEvents 20
TLS 협상, 인증서 또는 프로토콜 관련 오류가 접속 실패 시각과 일치하는지 확인합니다.
Microsoft는 Windows 11에서도 Schannel을 통한 TLS 설정과 이벤트 로깅을 문제 해결에 활용할 수 있다고 안내합니다. 레지스트리 기반 TLS 설정을 직접 변경하면 부작용이 있을 수 있으므로 로그를 확인하기 전에 TLS 버전을 강제로 변경하는 방식은 피하는 것이 좋습니다. (Microsoft Learn)
PC 시간도 확인
TLS 인증서는 유효 기간을 기준으로 검증됩니다.
Windows의 날짜나 시간이 크게 어긋나 있으면 정상 인증서도 유효하지 않은 것처럼 보일 수 있습니다.
다음 경로에서 확인합니다.
설정 → 시간 및 언어 → 날짜 및 시간
가능하다면:
자동으로 시간 설정
자동으로 표준 시간대 설정
상태도 함께 확인합니다.
특히 BIOS 초기화, VM Snapshot 복원, 장기간 꺼져 있던 테스트 PC에서는 시스템 시간이 어긋나는 경우가 있습니다.
VPN과 보안 프로그램 확인
VPN이나 Endpoint Security 제품이 HTTPS 통신을 검사하면 특정 도메인에서만 문제가 나타날 수 있습니다.
패킷 수준에서 DNS·TCP·TLS 흐름을 직접 확인해야 한다면 [Windows에서 Wireshark 설치 후 패킷 캡처 확인하기] 글을 참고하면 됩니다.
확인 대상은 다음과 같습니다.
- VPN Client
- Web Protection
- HTTPS Inspection
- SSL Inspection
- 회사 Endpoint Agent
- Endpoint Firewall
- 광고·추적 차단 프로그램
다만 보안 프로그램을 장시간 완전히 비활성화한 상태로 사용하는 것은 권장하지 않습니다.
테스트가 필요하다면 네트워크가 통제된 환경에서 잠시 비교한 뒤 즉시 원래 상태로 복구합니다.
VPN 사용 중이라면 먼저 VPN을 연결하지 않은 상태와 비교하는 편이 비교적 안전한 진단 방법입니다.
결과별로 원인 구분하기
| 확인 결과 | 우선 확인할 영역 |
|---|---|
| 다른 장치에서도 접속 실패 | 사이트 자체 또는 외부 네트워크 |
Resolve-DnsName 실패 | DNS |
| DNS 정상 + TCP 443 실패 | Firewall·VPN·Routing |
| TCP 443 정상 + curl 실패 | TLS·Proxy·보안 프로그램 |
| curl 정상 + 브라우저만 실패 | 브라우저·확장 프로그램·Profile |
| 특정 도메인만 다른 IP 반환 | DNS·hosts |
| Schannel 오류 발생 | TLS·인증서 |
| VPN 해제 후 정상 | VPN 또는 보안 정책 |
이 표를 기준으로 문제 영역을 먼저 좁힌 뒤 해당 계층만 수정하는 편이 좋습니다.
네트워크 초기화는 마지막에 사용
인터넷 문제를 해결할 때 다음 명령을 바로 실행하는 경우가 많습니다.
netsh winsock reset
또는:
netsh int ip reset
이 명령들이 필요한 경우도 있지만 특정 사이트 하나만 열리지 않는 상황에서 첫 조치로 사용할 필요는 없습니다.
DNS, TCP 443, Proxy, hosts, TLS를 먼저 점검하면 문제가 어느 계층에서 발생하는지 확인할 수 있습니다.
네트워크 초기화를 먼저 실행하면 기존 설정이 바뀌어 오히려 원인 분석이 어려워질 수 있습니다.
최종 점검 순서
특정 사이트만 접속되지 않을 때는 다음 순서로 확인하면 됩니다.
1. 다른 장치·네트워크에서 사이트 확인
2. Resolve-DnsName으로 DNS 확인
3. Test-NetConnection으로 TCP 443 확인
4. curl.exe로 HTTP/HTTPS 응답 확인
5. Proxy 설정 확인
6. hosts 파일 확인
7. Schannel 이벤트 확인
8. VPN·보안 프로그램 영향 확인
9. 필요할 때만 네트워크 초기화
핵심은 처음부터 DNS 서버 변경, 방화벽 해제, Winsock 초기화를 모두 실행하는 것이 아니라 DNS → TCP → HTTP/TLS 순서로 실패 지점을 좁혀 가는 것입니다.
이렇게 확인하면 “인터넷은 되는데 특정 사이트만 안 열린다”는 증상이 브라우저, DNS, 네트워크, TLS 중 어디의 문제인지 비교적 빠르게 구분할 수 있습니다.
참고 자료
- Microsoft Learn —
netsh winhttp명령 및 WinHTTP Proxy 관리 (Microsoft Learn) - Microsoft Learn — Windows TLS/Schannel 레지스트리 설정 및 문제 해결 지침 (Microsoft Learn)
- Microsoft Learn — Windows Schannel 이벤트 로깅 (Microsoft Learn)