안녕하세요. 일본서버, 미국서버 호스팅 전문 지구 IDC 기술팀입니다.
오늘은 Windows 10에서 ping은 정상적으로 응답하지만 특정 웹사이트에 접속되지 않을 때 원인을 확인하고 해결하는 방법을 알아보겠습니다. ping 성공은 ICMP 통신이 가능하다는 의미일 뿐이며, 실제 웹사이트 접속에 필요한 TCP 80·443 포트, DNS, 프록시, TLS 인증서, 브라우저 설정까지 모두 정상이라는 뜻은 아닙니다.
따라서 이 문제는 먼저 해당 도메인의 DNS 결과와 HTTPS 443 포트 연결을 확인한 뒤, 결과에 따라 프록시·방화벽·hosts 파일·브라우저·시스템 시간·네트워크 스택 순서로 원인을 좁히는 것이 효율적입니다. 특정 사이트만 열리지 않는다고 바로 네트워크 어댑터를 초기화하기보다 어느 단계에서 통신이 실패하는지 먼저 확인하는 것이 중요합니다.
적용 환경
| 항목 | 내용 |
|---|---|
| 운영체제 | Windows 10 |
| 주요 도구 | ping, nslookup, Resolve-DnsName, Test-NetConnection, ipconfig, netsh, curl.exe |
| 대상 증상 | 다른 인터넷 사이트는 정상이며 대상 도메인에 ping 응답도 있지만 브라우저에서 특정 사이트만 열리지 않는 경우 |
참고: Microsoft의 일반 Windows 10 지원은 2025년 10월 14일 종료되었습니다. 아래 진단 절차는 기존 Windows 10 시스템에서도 사용할 수 있지만, 인터넷에 연결되는 장기 운영 환경은 Windows 11 또는 현재 지원되는 Windows 버전으로 이전하는 것이 권장됩니다.
목차
- ping 성공의 의미와 가장 먼저 확인할 항목
- DNS와 hosts 파일 확인
- HTTP·HTTPS 포트 연결 확인
- curl로 HTTP·HTTPS 응답 확인
- 프록시 설정 확인
- 브라우저와 TLS·시스템 시간 확인
- 방화벽·보안 프로그램·상위 네트워크 확인
- 마지막 단계의 네트워크 초기화
- 증상별 원인 판단
- 관련 기술자료와 공식 참고자료
- 자주 묻는 질문
ping 성공의 의미와 가장 먼저 확인할 항목
ping은 ICMP Echo Request와 Echo Reply를 이용해 대상까지의 기본 네트워크 도달 가능성을 확인합니다. 웹 브라우저는 일반적으로 HTTP의 TCP 80 포트 또는 HTTPS의 TCP 443 포트를 사용하므로 ping이 성공해도 웹 접속은 별도로 실패할 수 있습니다.
문제가 발생하는 도메인을 다음과 같이 확인합니다. 아래 server.example.com은 실제 접속되지 않는 도메인으로 변경하십시오.
ping server.example.com도메인 이름 옆에 IP 주소가 표시되고 응답도 정상적으로 돌아온다면 최소한 이름을 어떤 IP로 해석했고 ICMP 통신도 가능하다는 의미입니다. 다음 단계에서는 해당 IP가 올바른지와 TCP 443 포트까지 실제로 연결되는지를 확인해야 합니다.
중요: ping 응답이 있다고 해서 웹 서버가 정상이라는 뜻은 아닙니다. 같은 서버라도 ICMP는 허용하면서 TCP 443을 차단할 수 있고, 웹 서버 프로세스·TLS 인증서·프록시·CDN·방화벽 정책 때문에 HTTPS만 실패할 수도 있습니다.
DNS와 hosts 파일 확인
도메인으로 ping이 성공한다면 이름 해석 자체는 동작하고 있을 가능성이 높지만, 오래된 DNS 캐시나 hosts 파일 때문에 잘못된 IP 주소로 연결되는 경우는 여전히 확인해야 합니다.
1. DNS 조회 결과 확인
명령 프롬프트에서 DNS 서버가 반환하는 주소를 확인합니다.
nslookup server.example.comPowerShell에서는 다음과 같이 A 레코드와 AAAA 레코드를 각각 확인할 수 있습니다.
Resolve-DnsName -Name server.example.com -Type A
Resolve-DnsName -Name server.example.com -Type AAAA사이트 운영자가 안내한 IP 또는 정상 PC에서 조회되는 IP와 비교합니다. 동일한 네트워크의 다른 PC에서는 정상인데 문제 PC에서만 전혀 다른 주소가 조회된다면 로컬 캐시나 hosts 파일을 우선 확인합니다.
2. DNS 캐시 초기화
Microsoft 문서에 따르면 ipconfig /flushdns는 DNS Client resolver 캐시를 초기화하고 캐시된 부정 응답도 제거할 수 있습니다.
ipconfig /flushdns초기화 후 다시 nslookup 또는 Resolve-DnsName으로 주소를 확인합니다.
3. hosts 파일 우회 여부 확인
Windows DNS Client는 캐시와 로컬 hosts 파일을 확인한 뒤 DNS 서버에 질의할 수 있습니다. PowerShell의 -NoHostsFile 옵션을 사용하면 hosts 파일을 제외한 조회 결과와 비교할 수 있습니다.
Resolve-DnsName -Name server.example.com
Resolve-DnsName -Name server.example.com -NoHostsFile두 결과가 다르고 기본 조회에서만 오래된 IP 주소가 나온다면 다음 파일의 수동 등록 내용을 확인합니다.
C:\Windows\System32\drivers\etc\hosts주의: 회사 내부 시스템, 개발 서버, 광고 차단 또는 보안 솔루션이 의도적으로 hosts 파일을 사용하는 환경이 있습니다. 항목을 무조건 삭제하지 말고 해당 설정의 용도를 확인한 뒤 백업 후 수정하십시오.
HTTP·HTTPS 포트 연결 확인
특정 웹사이트 접속 실패를 구분하는 데 가장 중요한 단계입니다. PowerShell에서 HTTPS 443 포트에 실제 TCP 연결이 가능한지 확인합니다.
Test-NetConnection server.example.com -Port 443결과에서 TcpTestSucceeded : True라면 대상 서버의 TCP 443 포트까지 연결은 성립된 것입니다. 이 경우 방화벽에서 443이 완전히 차단된 문제보다는 브라우저, 프록시, TLS 인증서 또는 HTTP 응답 단계의 문제를 우선 확인합니다.
TcpTestSucceeded : False라면 ping이 성공하더라도 HTTPS 포트에는 연결되지 않는 상태입니다. HTTP 사이트라면 80 포트도 비교합니다.
Test-NetConnection server.example.com -Port 80
Test-NetConnection server.example.com -Port 443| ping | TCP 443 | 우선 의심할 범위 |
|---|---|---|
| 성공 | 성공 | HTTP 응답, TLS, 브라우저, 프록시, 쿠키·확장 프로그램, 서버 측 애플리케이션 |
| 성공 | 실패 | TCP 443 차단, 서버 측 포트 미수신, 로컬·상위 방화벽, 보안 제품, 특정 IP 차단 |
| 실패 | 성공 | ICMP만 차단된 정상적인 서버일 수 있음 |
curl로 HTTP·HTTPS 응답 확인
TCP 443 연결은 성공하지만 브라우저에서 사이트가 열리지 않는다면 HTTP 요청 단계까지 확인합니다. Windows 10 환경에 curl.exe가 제공되는 경우 다음 명령으로 응답 헤더를 확인할 수 있습니다.
curl.exe -I https://server.example.com/HTTP 상태 코드가 반환된다면 최소한 HTTPS 요청이 서버까지 전달되고 응답도 돌아온 것입니다. 예를 들어 리디렉션, 인증 요구, 접근 금지 또는 서버 오류 상태가 반환될 수 있으므로 브라우저의 단순한 “접속 안 됨” 증상만 보는 것보다 원인을 좁히기 쉽습니다.
curl.exe에서 인증서 이름 불일치, 인증 기관 문제 또는 TLS 협상 오류가 표시된다면 네트워크 연결 자체보다 인증서·TLS·중간 보안 장비를 우선 확인합니다.
주의: 인증서 오류를 해결하기 위해 브라우저 경고를 무시하거나 인증서 검증을 상시 비활성화하지 마십시오. 시스템 시간, 인증서의 도메인 이름과 유효기간, 인증 경로, 사내 SSL 검사 장비 여부를 먼저 확인해야 합니다.
프록시 설정 확인
특정 웹사이트만 접속되지 않을 때 프록시 서버나 자동 구성 스크립트(PAC)가 해당 도메인만 다른 경로로 보내는 경우가 있습니다. Windows 10에서는 설정 → 네트워크 및 인터넷 → 프록시에서 수동 프록시와 자동 설정 스크립트를 확인합니다.
WinHTTP를 사용하는 Windows 서비스나 일부 애플리케이션의 프록시 상태는 관리자 권한 명령 프롬프트에서 다음 명령으로 확인할 수 있습니다.
netsh winhttp show proxyMicrosoft 문서에 따르면 netsh winhttp reset proxy는 WinHTTP 프록시 설정을 직접 연결(DIRECT) 상태로 되돌립니다. 다만 회사나 서버 환경에서 의도적으로 프록시를 사용하는 경우에는 실행하면 정상 업무 연결이 끊길 수 있으므로 먼저 현재 설정과 조직 정책을 확인해야 합니다.
주의: 회사·학교·보안망에서 프록시가 필수인 경우 netsh winhttp reset proxy를 임의로 실행하지 마십시오. 먼저 netsh winhttp show proxy로 현재 값을 기록하고 네트워크 관리자에게 필요한 설정인지 확인하십시오.
브라우저와 TLS·시스템 시간 확인
TCP 443 테스트와 curl.exe 요청이 정상인데 특정 브라우저에서만 열리지 않는다면 브라우저 자체의 캐시·쿠키·확장 프로그램·프록시 연동 문제일 가능성이 높습니다.
- 다른 브라우저에서 같은 URL을 열어 증상을 비교합니다.
- 시크릿 또는 InPrivate 창에서 접속해 확장 프로그램·저장 데이터 영향을 비교합니다.
- 문제 사이트의 쿠키와 사이트 데이터만 삭제한 뒤 다시 접속합니다.
- 광고 차단, 보안, VPN, 프록시 관련 브라우저 확장 기능이 있다면 일시적으로 영향을 확인합니다.
- Windows 날짜·시간·시간대가 실제 값과 일치하는지 확인합니다.
HTTPS 인증서 검증은 시스템 시간의 영향을 받습니다. 시스템 시간이 크게 틀리면 아직 유효하지 않거나 이미 만료된 인증서처럼 판단되어 HTTPS 접속이 실패할 수 있습니다.
시간 동기화 상태를 확인하려면 관리자 권한 명령 프롬프트에서 다음 명령을 사용할 수 있습니다.
w32tm /query /status사이트가 다른 PC에서도 동일하게 접속되지 않는다면 로컬 브라우저 문제보다 웹 서버 또는 사이트 운영 측 장애 가능성을 함께 확인합니다.
방화벽·보안 프로그램·상위 네트워크 확인
Test-NetConnection server.example.com -Port 443가 실패한다면 웹 브라우저보다 낮은 네트워크 계층에서 막혔을 가능성이 있습니다. 다음 항목을 순서대로 확인합니다.
- Windows Defender 방화벽 또는 조직의 보안 정책에서 특정 목적지·포트를 차단하는지
- 백신·웹 보안·SSL 검사 프로그램이 HTTPS 연결을 필터링하는지
- VPN 연결 중에만 문제가 발생하거나 반대로 VPN을 끄면 정상화되는지
- 회사·학교·IDC·클라우드의 상위 방화벽이나 보안 게이트웨이가 대상 IP를 차단하는지
- 웹사이트가 사용자의 공인 IP 또는 국가·지역을 서버 측에서 차단하고 있는지
가능하다면 같은 PC를 다른 네트워크에 연결해 비교합니다. 예를 들어 휴대전화 테더링에서는 사이트가 열리지만 기존 회선에서만 실패한다면 Windows 브라우저 문제보다 기존 공유기·방화벽·통신사 또는 상위 네트워크 경로를 우선 확인할 수 있습니다.
주의: 문제 확인을 위해 Windows 방화벽이나 백신을 장시간 전체 비활성화하는 방식은 권장하지 않습니다. 정책·로그·예외 규칙을 확인하고, 필요한 경우 허용된 유지보수 절차에 따라 짧게 비교 테스트하십시오.
마지막 단계의 네트워크 초기화
특정 사이트뿐 아니라 여러 사이트에서 비슷한 문제가 발생하고 DNS·프록시·포트 테스트에서도 원인이 명확하지 않다면 Winsock 또는 TCP/IP 스택 문제를 확인할 수 있습니다. 다만 특정 사이트 하나만 실패하는 상황에서는 이 단계를 가장 먼저 실행할 필요는 없습니다.
관리자 권한 명령 프롬프트에서 현재 구성을 기록한 뒤 다음 명령을 사용할 수 있습니다.
ipconfig /all
netsh winsock reset
netsh int ip reset resetlog.txt명령 실행 후 Windows를 재부팅하고 IP 주소, 기본 게이트웨이, DNS 서버가 정상적으로 복원되었는지 확인합니다.
ipconfig /all주의: 고정 IP, 사용자 지정 DNS, 특수 라우팅, VPN 또는 네트워크 필터가 있는 PC에서는 초기화 후 설정을 다시 적용해야 할 수 있습니다. 원격 접속 중인 시스템에서는 네트워크 설정 변경으로 세션이 끊길 수 있으므로 콘솔 접근 수단과 기존 설정값을 확보한 뒤 진행하십시오.
증상별 원인 판단
| 증상 | 가능한 원인 | 우선 확인 |
|---|---|---|
ping 성공, TCP 443 실패 |
443 포트 차단, 서버 측 HTTPS 미수신, 방화벽·보안 장비·IP 차단 | Test-NetConnection ... -Port 443, 다른 네트워크 비교 |
ping과 TCP 443 모두 성공하지만 브라우저만 실패 |
프록시, 브라우저 데이터·확장 프로그램, TLS 또는 인증서 문제 | curl.exe -I, 다른 브라우저, 프록시 설정 |
| 문제 PC만 다른 IP 주소를 조회 | DNS 캐시 또는 hosts 파일 |
nslookup, Resolve-DnsName -NoHostsFile, ipconfig /flushdns |
| 한 브라우저에서만 실패 | 브라우저 캐시·쿠키·확장 기능·브라우저별 프록시 설정 | InPrivate/시크릿 창, 다른 브라우저와 비교 |
| 다른 회선에서는 정상 | 공유기·상위 방화벽·통신사 경로·공인 IP 차단 | 테더링 등 다른 네트워크와 동일 PC 비교 |
| 모든 PC에서 같은 사이트만 실패 | 사이트 장애, DNS 레코드 문제, 서버 측 차단 또는 상위 네트워크 문제 | 사이트 운영자 상태, 다른 회선·DNS·지역에서 비교 |
관련 지구 IDC 기술자료
- Windows 10에서 DNS 캐시 문제로 인터넷 접속이 되지 않을 때 해결하는 방법
- Windows 10에서 네트워크 어댑터를 초기화하여 인터넷 연결 문제를 해결하는 방법
- Windows 10에서 라우팅 테이블을 확인하고 잘못된 기본 게이트웨이를 수정하는 방법
공식 참고자료
| 기관 | 문서 | 확인 내용 | 조회일 |
|---|---|---|---|
| Microsoft Learn | ping | ICMP Echo 기반 연결 확인과 이름 확인 동작 | 2026년 11월 10일 |
| Microsoft Learn | Test-NetConnection | 원격 TCP 포트 연결 테스트와 네트워크 진단 | 2026년 11월 10일 |
| Microsoft Learn | Resolve-DnsName | DNS 조회와 -NoHostsFile 옵션을 이용한 hosts 영향 구분 |
2026년 11월 10일 |
| Microsoft Learn | ipconfig | DNS Client 캐시 조회·초기화와 TCP/IP 구성 확인 | 2026년 11월 10일 |
| Microsoft Learn | DNS 클라이언트 이름 확인 문제 해결 | DNS 캐시·hosts 파일·DNS 서버 문제의 구분 | 2026년 11월 10일 |
| Microsoft Learn | netsh winhttp | WinHTTP 프록시 설정 조회와 초기화 기능 | 2026년 11월 10일 |
| Microsoft Support | Windows 10 지원 종료 안내 | Windows 10 일반 지원 종료일 확인 | 2026년 11월 10일 |
자주 묻는 질문
ping이 되면 인터넷 연결은 정상 아닌가요?
아닙니다. ping은 ICMP 통신을 확인합니다. 웹사이트는 주로 TCP 80·443을 사용하므로 ICMP는 성공해도 HTTPS 443 포트가 차단되거나 웹 서버·프록시·TLS 단계에서 실패할 수 있습니다.
ping도 되고 Test-NetConnection의 443도 True인데 사이트가 안 열립니다.
이 경우 네트워크 경로와 TCP 연결은 대체로 성립된 상태입니다. curl.exe -I로 HTTP 응답을 확인하고, 프록시, 브라우저 확장 프로그램·쿠키, TLS 인증서, 시스템 시간과 서버 측 HTTP 오류를 우선 점검하십시오.
DNS를 바꾸면 무조건 해결되나요?
그렇지 않습니다. 도메인이 정상 IP로 해석되고 443 포트 연결도 성공한다면 DNS 변경은 핵심 해결책이 아닐 수 있습니다. 먼저 nslookup과 Resolve-DnsName으로 실제 조회 결과가 잘못됐는지 확인해야 합니다.
다른 브라우저에서는 정상인데 특정 브라우저에서만 안 됩니다.
브라우저별 쿠키·캐시·확장 프로그램·프록시 또는 보안 설정을 우선 확인합니다. 시크릿/InPrivate 창에서 비교하고 문제 사이트의 데이터만 제거한 뒤 다시 테스트하는 것이 좋습니다.
휴대폰 테더링에서는 사이트가 열리는데 회사 인터넷에서는 안 됩니다.
같은 PC에서 네트워크만 바꿨을 때 정상화된다면 로컬 브라우저 자체보다 회사 방화벽·프록시·DNS·보안 게이트웨이·공인 IP 차단 또는 통신 경로를 우선 확인하는 것이 합리적입니다.
마무리
Windows 10에서 ping은 되지만 특정 웹사이트에 접속되지 않는다면 먼저 Test-NetConnection으로 TCP 443 연결이 가능한지 확인하는 것이 가장 빠른 분기점입니다. 443 연결이 실패하면 방화벽·네트워크 경로·서버 측 포트를 확인하고, 443은 성공하지만 브라우저만 실패하면 DNS·프록시·TLS·브라우저 설정을 중심으로 점검하면 됩니다.
특정 사이트 하나의 문제에 곧바로 전체 네트워크 초기화를 적용하기보다 DNS 조회 결과, 포트 연결, HTTP 응답을 순서대로 확인하면 불필요한 설정 변경 없이 원인을 좁힐 수 있습니다.
지구 IDC는 일본서버와 미국서버를 포함한 다양한 서버 호스팅 환경에서 안정적인 운영에 도움이 되는 기술정보를 지속적으로 제공하겠습니다.
