Windows 작업 표시줄에는 Wi-Fi 또는 인터넷이 연결된 것으로 표시되는데 Chrome이나 Edge에서 웹사이트가 열리지 않는 경우가 있습니다.
이런 상황에서 공유기부터 재부팅하거나 Windows 네트워크 설정을 무작정 초기화하면 실제 원인을 확인하지 못한 채 문제가 우연히 해결될 수도 있습니다.
인터넷 연결은 단순히 ‘된다 / 안 된다’ 두 가지 상태로만 나뉘지 않습니다.
PC가 공유기로부터 IP 주소를 정상적으로 받았는지, 공유기 밖의 외부 인터넷과 통신할 수 있는지, DNS가 도메인 이름을 정상적으로 IP 주소로 변환하고 있는지를 각각 확인해야 문제 범위를 좁힐 수 있습니다.
이번 글에서는 이 과정을 확인하기 위해 실제 Windows PC에서 CMD를 실행해 직접 테스트한 결과를 사용합니다.
테스트에 사용한 핵심 명령어는 다음 세 가지입니다.
단순히 명령어 사용법만 나열하지 않고 실제 정상 상태에서는 어떤 결과가 나타났는지 확인한 뒤, 인터넷에 문제가 발생했을 때 각 결과를 어떻게 비교해야 하는지 알아보겠습니다.
먼저 알아둘 점: Wi-Fi 연결과 인터넷 연결은 같은 의미가 아니다
Windows에서 Wi-Fi가 ‘연결됨’으로 표시된다고 해서 반드시 외부 인터넷까지 정상적으로 연결됐다는 의미는 아닙니다.
예를 들어 노트북과 공유기 사이의 Wi-Fi 연결은 정상인데 공유기의 인터넷 회선에 문제가 있을 수 있습니다.
또는 외부 IP와의 통신은 정상인데 DNS에 문제가 생겨 google.com 같은 도메인 주소로 접속하지 못할 수도 있습니다.
따라서 인터넷 문제를 진단할 때는 한 번에 결론을 내리기보다 다음처럼 구간을 나누는 것이 좋습니다.
1단계: PC의 IP 설정 확인
↓
2단계: 외부 IP와 실제 통신이 가능한지 확인
↓
3단계: DNS가 도메인을 정상적으로 조회하는지 확인
이번 테스트도 이 순서대로 진행했습니다.
테스트 환경과 방법
테스트는 실제 Windows PC의 명령 프롬프트에서 진행했습니다.
먼저 인터넷이 정상적으로 작동하는 상태에서 세 명령어를 실행해 정상 상태의 기준 결과를 확보했습니다.
왜 정상 상태를 먼저 확인할까요?
인터넷에 문제가 발생했을 때 오류 화면만 보면 어느 부분이 달라졌는지 판단하기 어렵기 때문입니다.
평소 정상적인 결과를 알고 있다면 문제가 생겼을 때 같은 명령어를 다시 실행하여 어느 단계부터 결과가 달라졌는지 비교할 수 있습니다.
1단계: ipconfig로 PC가 IP를 정상적으로 받았는지 확인
CMD를 실행하고 다음 명령어를 입력했습니다.
ipconfig
ipconfig는 현재 Windows PC의 기본적인 네트워크 설정을 확인할 때 사용하는 명령어입니다.
실제 테스트에서는 Ethernet 어댑터에 다음 정보가 정상적으로 표시되었습니다.
IPv4 주소
서브넷 마스크
기본 게이트웨이
CMVEXA Windows 테스트 환경에서 직접 실행한 ipconfig 결과. 개인정보 보호를 위해 일부 사용자 및 네트워크 정보는 가릴 수 있습니다.
이번 테스트 PC에서는 IPv4 주소가 정상적으로 할당되어 있었고 기본 게이트웨이도 확인할 수 있었습니다.
이 결과에서 중요한 것은 구체적인 IP 숫자를 외우는 것이 아닙니다.
PC가 네트워크에서 사용할 주소를 정상적으로 가지고 있는지 확인하는 것이 핵심입니다.
일반적인 가정이나 소규모 네트워크에서는 공유기의 DHCP 기능을 통해 PC가 자동으로 IP 주소를 받는 경우가 많습니다.
따라서 정상적인 환경이라면 대체로 IPv4 주소와 기본 게이트웨이를 확인할 수 있습니다.
ipconfig 결과에서 무엇을 봐야 할까?
처음에는 다음 세 항목부터 보면 됩니다.
IPv4 주소
현재 PC가 네트워크에서 사용하고 있는 IPv4 주소입니다.
서브넷 마스크
현재 네트워크 범위를 구분하는 데 사용됩니다.
기본 게이트웨이
PC가 다른 네트워크, 일반적으로 인터넷 방향으로 통신할 때 사용하는 경로와 관련된 주소입니다. 가정에서는 보통 공유기가 기본 게이트웨이 역할을 합니다.
이번 실제 테스트에서는 이 정보들이 정상적으로 확인됐습니다.
하지만 여기서 바로:
“IP가 있으니까 인터넷도 정상이다.”
라고 결론 내리면 안 됩니다.
PC와 공유기 사이의 설정은 정상이어도 공유기 이후 인터넷 연결에 문제가 있을 수 있기 때문입니다.
그래서 다음 단계에서는 외부 IP와 실제 통신이 가능한지 확인했습니다.
2단계: ping 8.8.8.8로 외부 통신 확인
다음으로 CMD에서 아래 명령어를 실행했습니다.
ping 8.8.8.8
이번 테스트에서 실제로 확인된 결과는 다음과 같았습니다.
전송 패킷: 4
수신 패킷: 4
손실 패킷: 0
패킷 손실률: 0%
응답 시간: 약 28~29ms
CMVEXA 테스트 PC에서 8.8.8.8로 직접 ping을 실행한 결과.
네 번의 요청이 모두 정상적으로 돌아왔으며 패킷 손실은 발생하지 않았습니다.
이번 테스트에서는 외부 IP까지 통신이 정상적으로 이루어지고 있음을 확인할 수 있었습니다.
왜 google.com 대신 8.8.8.8을 사용했을까?
여기가 인터넷 문제를 진단할 때 중요한 부분입니다.
google.com처럼 도메인 이름을 사용하면 DNS 이름 해석 과정이 개입됩니다.
반면:
ping 8.8.8.8
처럼 IP 주소를 직접 지정하면 도메인 이름을 IP 주소로 변환하는 과정과 어느 정도 분리해서 외부 네트워크 통신 여부를 확인할 수 있습니다.
따라서 다음처럼 결과를 해석하는 데 도움이 됩니다.
ping 8.8.8.8 정상
↓
외부 IP와 통신 가능
↓
그런데 도메인 웹사이트 접속 실패
↓
DNS 문제 가능성을 추가로 확인
물론 이것만으로 DNS 문제라고 확정할 수는 없습니다.
웹 브라우저, 방화벽, 프록시, VPN, 서버 자체 장애 등 다른 원인도 존재할 수 있기 때문입니다.
ping 실패만으로 인터넷 단절이라고 단정하면 안 된다
주의할 점도 있습니다.
특정 서버나 네트워크 장비는 보안 정책에 따라 ICMP 응답을 제한하거나 차단할 수 있습니다.
따라서 특정 대상에 ping 응답이 없다는 사실 하나만으로:
“인터넷이 완전히 끊겼다.”
라고 단정해서는 안 됩니다.
ping은 여러 진단 결과 중 하나로 사용하고 다른 테스트 결과와 함께 판단하는 것이 좋습니다.
이번 테스트에서는 8.8.8.8에서 4회 모두 정상적인 응답이 돌아왔으므로 다음 단계인 DNS 조회를 진행했습니다.
3단계: nslookup으로 DNS가 정상인지 직접 확인
외부 IP 통신이 확인됐다면 다음에는 DNS를 확인합니다.
CMD에서 다음 명령어를 실행했습니다.
nslookup google.com
실제 테스트에서는 사용 중인 DNS 서버 정보가 표시됐고, google.com에 대한 여러 IPv4 및 IPv6 주소가 반환되었습니다.
CMVEXA Windows 테스트 환경에서 google.com을 직접 조회한 결과.
이번 테스트에서 중요한 부분은 특정 IP 주소의 숫자가 아닙니다.
google.com이라는 도메인 이름을 DNS 서버가 실제 IP 주소로 변환해 결과를 반환했다는 것이 중요합니다.
즉 이번 테스트 환경에서는 DNS 조회도 정상적으로 이루어지고 있었습니다.
nslookup 결과를 어떻게 해석해야 할까?
DNS는 사람이 사용하는 도메인 이름을 네트워크 통신에 사용할 수 있는 IP 주소와 연결해주는 역할을 합니다.
예를 들어 사용자는 웹 브라우저에:
google.com
을 입력하지만 실제 통신에서는 해당 도메인과 연결된 IP 주소가 필요합니다.
이번 테스트에서:
nslookup google.com
을 실행했을 때 여러 주소가 반환됐으므로 DNS 이름 조회가 정상적으로 이루어지고 있음을 확인할 수 있었습니다.
반대로 인터넷 문제 상황에서:
ping 8.8.8.8
은 정상인데:
nslookup google.com
에서 정상적인 조회 결과를 얻지 못한다면 DNS 쪽을 우선적으로 점검해볼 근거가 생깁니다.
실제 테스트 결과를 한 번에 비교해보면
이번 Windows PC의 정상 인터넷 상태에서는 다음과 같은 결과를 얻었습니다.
ipconfig
IPv4 주소 확인됨
기본 게이트웨이 확인됨
↓
ping 8.8.8.8
4회 전송
4회 수신
손실 0%
약 28~29ms 응답
↓
nslookup google.com
DNS 서버 응답
google.com의 IPv4·IPv6 주소 반환
따라서 이번 테스트에서는:
PC 네트워크 설정 → 외부 IP 통신 → DNS 조회
세 단계가 모두 정상적으로 동작하고 있었습니다.
이 결과를 인터넷 문제가 발생했을 때 비교할 수 있는 정상 기준으로 사용할 수 있습니다.
인터넷이 안 될 때는 어느 단계에서 막히는지 찾는다
이제 실제 문제 상황을 생각해보겠습니다.
상황 1. ipconfig부터 이상한 경우
ipconfig를 실행했는데 평소 사용하던 네트워크 설정과 크게 다르거나 필요한 주소 정보를 정상적으로 받지 못한 것으로 보인다면 PC와 공유기 사이의 네트워크 설정부터 확인해야 합니다.
이 경우에는 다음과 같은 부분을 확인할 수 있습니다.
Wi-Fi 또는 랜 케이블 연결 상태
네트워크 어댑터 상태
공유기 DHCP 상태
IP 설정
단순히 DNS부터 변경하기보다 앞 단계부터 확인하는 편이 효율적입니다.
상황 2. IP는 정상인데 외부 IP ping이 실패하는 경우
ipconfig에서는 IPv4 주소와 기본 게이트웨이가 확인되는데 외부 IP와의 통신이 되지 않는다면 문제 범위를 조금 더 좁혀볼 수 있습니다.
이때는 먼저 기본 게이트웨이에 ping을 실행해보는 방법이 있습니다.
예를 들어 ipconfig에서 확인한 기본 게이트웨이가 다음과 같다고 가정하겠습니다.
192.168.x.x
실제 주소는 자신의 ipconfig 결과에서 확인해야 합니다.
다음처럼 실행합니다.
ping 기본게이트웨이주소
기본 게이트웨이에는 정상적으로 응답하지만 외부 IP에는 통신이 되지 않는다면 공유기 이후의 인터넷 연결이나 회선 상태 등을 추가로 확인할 필요가 있습니다.
반대로 기본 게이트웨이부터 통신되지 않는다면 PC와 공유기 사이의 연결을 우선 확인하는 것이 좋습니다.
상황 3. 8.8.8.8은 되는데 웹사이트가 안 열리는 경우
이번 글에서 특히 구분하고 싶은 상황입니다.
다음 명령어는 정상적으로 응답합니다.
ping 8.8.8.8
그런데:
nslookup google.com
이 정상적으로 동작하지 않거나 웹 브라우저에서 여러 도메인이 열리지 않습니다.
이런 경우 외부 네트워크 통신 자체보다는 DNS 설정이나 DNS 서버 응답을 추가로 확인할 필요가 있습니다.
다만 DNS만이 유일한 원인은 아닙니다.
VPN
프록시
보안 프로그램
방화벽
브라우저 문제
특정 사이트 장애
등도 비슷한 증상을 만들 수 있습니다.
따라서 CMD 결과를 이용해 가능성이 높은 구간부터 좁혀가는 것이 중요합니다.
상황 4. nslookup도 정상인데 특정 사이트만 안 열리는 경우
ping 8.8.8.8도 정상이고:
nslookup google.com
같은 DNS 조회도 정상인데 특정 웹사이트 하나만 열리지 않는다면 인터넷 전체 문제라고 보기 어려워집니다.
이 경우에는 해당 사이트 자체의 장애, 브라우저 문제, 보안 프로그램, VPN·프록시 설정, DNS 캐시 등 다른 원인을 확인할 필요가 있습니다.
즉 CMD 진단의 목적은 모든 문제를 명령어 하나로 해결하는 것이 아닙니다.
문제가 발생한 구간을 하나씩 제외하면서 원인의 범위를 줄이는 것입니다.
인터넷 문제를 진단할 때 추천하는 순서
실제로 문제가 발생하면 다음 순서로 진행해볼 수 있습니다.
1. IP 설정 확인
ipconfig
IPv4 주소와 기본 게이트웨이를 확인합니다.
2. 공유기까지 통신 확인
ping 기본게이트웨이주소
여기에는 인터넷에 있는 임의의 주소를 입력하는 것이 아니라 자신의 ipconfig 결과에 표시된 기본 게이트웨이를 사용합니다.
3. 외부 IP 통신 확인
ping 8.8.8.8
응답 여부와 패킷 손실을 확인합니다.
4. DNS 조회 확인
nslookup google.com
DNS 서버가 도메인을 정상적으로 조회하는지 확인합니다.
이렇게 하면:
PC → 공유기 → 외부 인터넷 → DNS
순서로 문제 범위를 좁힐 수 있습니다.
무작정 네트워크 초기화부터 하지 않는 이유
인터넷이 안 되면 검색 결과에서 다음과 같은 해결 방법을 쉽게 볼 수 있습니다.
DNS 변경
네트워크 초기화
Winsock 초기화
공유기 초기화
네트워크 드라이버 재설치
이 방법들이 특정 문제를 해결할 수는 있습니다.
하지만 원인을 확인하기 전에 여러 설정을 동시에 변경하면 무엇이 실제 원인이었는지 알기 어려워집니다.
예를 들어 외부 IP 통신까지 정상인데 DNS 조회만 실패한다면 공유기를 공장 초기화하거나 네트워크 드라이버부터 다시 설치하는 것은 우선순위가 낮을 수 있습니다.
반대로 PC가 네트워크 설정을 제대로 받지 못하고 있다면 DNS 주소만 변경하는 것으로 해결되지 않을 수도 있습니다.
따라서:
확인 → 문제 구간 특정 → 해당 구간 조치
순서로 진행하는 것이 좋습니다.
CMD 진단 결과별 다음 행동 정리
ipconfig에서 네트워크 설정부터 이상함
→ PC와 공유기 사이 연결 및 IP 설정 확인
기본 게이트웨이 ping 실패
→ PC와 공유기 사이 연결 상태 우선 확인
게이트웨이 정상 + 외부 IP 통신 실패
→ 공유기 이후 인터넷 회선 또는 네트워크 경로 추가 확인
외부 IP 정상 + DNS 조회 실패
→ DNS 서버 및 DNS 설정 우선 확인
외부 IP 정상 + DNS 정상 + 특정 사이트만 실패
→ 해당 사이트, 브라우저, VPN, 프록시, 보안 프로그램 등의 문제 확인
이런 식으로 보면 인터넷 문제를 처음부터 무작정 해결하려 하기보다 범위를 단계적으로 좁힐 수 있습니다.
이번 실제 테스트에서 확인한 정상 기준
이번 글에서는 설명을 위해 만들어낸 예시 결과가 아니라 실제 Windows PC에서 직접 명령어를 실행했습니다.
테스트 결과는 다음과 같습니다.
ipconfig
→ IPv4 주소와 기본 게이트웨이 정상 확인
ping 8.8.8.8
→ 4회 전송 / 4회 수신 / 손실 0%
→ 약 28~29ms 응답
nslookup google.com
→ 사용 중인 DNS 서버 응답 확인
→ google.com의 IPv4 및 IPv6 주소 정상 반환
따라서 테스트 당시 PC는 IP 설정, 외부 네트워크 통신, DNS 이름 조회가 모두 정상인 상태였습니다.
이 정상 결과를 기준으로 저장해두면 나중에 같은 PC에서 인터넷 문제가 발생했을 때 동일한 명령어를 다시 실행해 어느 단계의 결과가 달라졌는지 비교할 수 있습니다.
자주 하는 실수
첫 번째는 Wi-Fi 연결 표시만 보고 인터넷도 정상이라고 생각하는 것입니다.
PC와 공유기 연결과 공유기에서 외부 인터넷으로 나가는 연결은 구분해서 확인해야 합니다.
두 번째는 ping 하나만으로 모든 문제를 판단하는 것입니다.
특정 서버가 ICMP 응답을 제한할 수 있기 때문에 다른 결과도 함께 봐야 합니다.
세 번째는 IP 주소와 도메인 이름을 같은 테스트로 생각하는 것입니다.
ping 8.8.8.8과 nslookup google.com은 확인하려는 부분이 다릅니다.
네 번째는 원인을 확인하기 전에 설정부터 여러 개 변경하는 것입니다.
DNS, 네트워크 초기화, 드라이버 재설치 등을 한꺼번에 하면 어떤 조치가 실제로 효과가 있었는지 확인하기 어려워집니다.
다섯 번째는 정상 상태의 결과를 모르는 것입니다.
문제가 없을 때 한 번 실행해서 결과를 확인해두면 이후 장애가 발생했을 때 비교하기 훨씬 쉽습니다.
핵심 명령어 다시 정리
IP 설정 확인:
ipconfig
기본 게이트웨이 통신 확인:
ping 기본게이트웨이주소
외부 IP 통신 확인:
ping 8.8.8.8
DNS 조회 확인:
nslookup google.com
이 네 단계를 기억해두면 Windows에서 인터넷 문제가 발생했을 때 어디부터 확인해야 할지 판단하기 쉬워집니다.
마무리
Windows에서 Wi-Fi가 연결됐는데 인터넷이 되지 않는다면 처음부터 공유기를 초기화하거나 Windows 네트워크 설정을 모두 변경하기보다 문제가 어느 구간에서 발생했는지 확인하는 것이 먼저입니다.
이번 실제 테스트에서는:
ipconfig
↓
ping 8.8.8.8
↓
nslookup google.com
순서로 직접 확인했습니다.
테스트 결과 IPv4 주소와 기본 게이트웨이가 정상적으로 존재했고, 8.8.8.8에 대한 ping은 4회 모두 응답했으며 패킷 손실은 0%였습니다. 이후 nslookup google.com에서도 DNS 서버가 정상적으로 응답하고 여러 IPv4·IPv6 주소를 반환했습니다.
즉 이번 테스트 환경에서는:
PC 네트워크 설정 정상
↓
외부 인터넷 통신 정상
↓
DNS 조회 정상
이라는 정상 상태를 직접 확인할 수 있었습니다.
인터넷 문제가 실제로 발생한다면 같은 순서로 명령어를 다시 실행하면 됩니다.
ipconfig부터 이상하다면 PC의 네트워크 설정 쪽을 먼저 보고, 기본 게이트웨이까지 통신되지 않는다면 PC와 공유기 사이를 확인합니다.
기본 게이트웨이는 정상인데 외부 IP와 통신되지 않는다면 공유기 이후 구간을 살펴보고, 외부 IP는 정상인데 DNS 조회가 실패한다면 DNS 관련 문제를 우선적으로 확인합니다.
이렇게 PC → 공유기 → 외부 인터넷 → DNS 순서로 하나씩 확인하면 단순히 “인터넷이 안 된다”는 증상에서 실제 문제가 발생한 구간을 훨씬 체계적으로 좁힐 수 있습니다.
무엇보다 이번 글에서 사용한 결과는 정상 인터넷 상태의 Windows PC에서 직접 실행한 값입니다.
따라서 인터넷 문제를 해결할 때 명령어 자체를 외우는 것보다 정상 상태의 결과와 문제가 발생했을 때의 결과가 어디서 달라지는지를 비교하는 것이 더 중요합니다.