로컬 네트워크 점검
브라우저가 답할 수 없는 질문들과, 직접 답을 얻는 명령어입니다.
이 페이지가 있는 이유
웹사이트는 내 네트워크 내부를 볼 수 없으며, 이는 의도된 설계입니다. 서버가 받는 것은 하나뿐입니다. 게이트웨이의 공인 주소입니다. 사설 주소, 서브넷, 공유기, 거기에 연결된 기기는 애초에 HTTP 요청에 실려 오지 않으므로, 여기에 어떤 코드를 넣어도 알아낼 수 없습니다.
MyIPKit이 할 수 있는 것은, 브라우저 샌드박스가 적용되지 않는 내 컴퓨터에서 각 질문에 답하는 명령어를 정확히 알려주는 것입니다. 이 페이지가 바로 그것입니다.
브라우저에서 자동으로 감지했습니다. 다르면 직접 바꾸세요.
실행하기 전에
- 이 페이지의 모든 명령어는 읽기 전용입니다. 설정을 바꾸지 않습니다.
- 관리자 권한이 필요하다고 표시된 명령어는 비밀번호를 묻습니다. 실행 전에 내용을 확인하세요.
- 소유하거나 점검 권한이 있는 네트워크만 스캔하세요. 예의의 문제가 아니라 대부분의 국가에서 법적 경계입니다.
- 이 페이지를 포함해 어디서든, 이해하지 못한 명령어를 붙여넣지 마세요. 아래 각 항목은 무엇을 하는지 설명합니다.
내 주소
MyIPKit은 인터넷에 보이는 공인 주소를 보여줍니다. 아래는 내 네트워크 안에서 기기가 갖는 사설 주소, 즉 웹사이트가 절대 받을 수 없는 부분입니다.
활성 인터페이스의 사설 IPv4 주소
ipconfig getifaddr en0hostname -I | awk '{print $1}'ipconfig192.168.x.x, 10.x.x.x, 172.16–31.x.x 중 하나가 나옵니다. macOS에서 en0은 보통 Wi-Fi, en1은 유선입니다. 둘 다 시도해 보세요.
IPv6를 포함한 모든 인터페이스와 주소
ifconfigip addr showipconfig /allinet(IPv4)과inet6(IPv6) 줄을 보세요. fe80: 으로 시작하는 IPv6 주소는 링크 로컬이라 네트워크를 벗어나지 않습니다. 전역 주소는 보통 2나 3으로 시작합니다.IPv6 연결이 실제로 동작하는지
curl -6 -s https://api64.ipify.org || echo "no IPv6"curl -6 -s https://api64.ipify.org || echo "no IPv6"curl.exe -6 -s https://api64.ipify.org주소가 출력되면 종단 간 IPv6가 있는 것입니다. 실패하면 IPv4 전용이며, 이것도 완전히 정상입니다.
명령줄에서 보는 공인 주소
curl -s https://api.ipify.orgcurl -s https://api.ipify.orgcurl.exe -s https://api.ipify.orgMyIPKit이 보여주는 값과 일치해야 합니다. 다르다면 보통 VPN, 프록시, 또는 브라우저가 curl과 다른 경로를 쓰고 있다는 뜻입니다.
내 네트워크 구성
공유기, 서브넷, 연결된 기기입니다. 사람들이 웹사이트에서 가장 많이 기대하는 정보이자, 브라우저가 가장 단호하게 내주지 않는 정보입니다.
공유기(기본 게이트웨이)
route -n get defaultip route | grep defaultipconfig | findstr /i "Default Gateway"게이트웨이 주소가 공유기입니다. 브라우저에서 열면 보통 관리 페이지로 연결됩니다.
전체 라우팅 테이블
netstat -rnip route showroute print특정 목적지로 가는 트래픽이 어느 인터페이스로 나가는지 보여줍니다. VPN은 보통 기본 경로를 가로채는 경로를 추가합니다.
서브넷 마스크 — 네트워크 크기 확인
ipconfig getpacket en0 | grep subnet_maskip -o -f inet addr show | awk '{print $4}'ipconfig | findstr /i "Subnet Mask"주소와 마스크를 이 사이트의 서브넷 계산기에 넣으면 정확한 사용 가능 범위를 볼 수 있습니다.
최근 통신한 로컬 네트워크의 기기들
arp -aip neigh showarp -aARP 테이블은 최근에 본 이웃만 나열하며, 존재하는 모든 기기를 보여주지는 않습니다. 부팅 후 통신이 없던 기기는 빠집니다.
현재 살아 있는 네트워크 내 호스트
기본 설치되지 않음nmap -sn 192.168.1.0/24nmap -sn 192.168.1.0/24nmap -sn 192.168.1.0/24nmap은 기본 설치되지 않습니다. macOS:
brew install nmap. Debian/Ubuntu:sudo apt install nmap. Windows: nmap.org.ping 스윕이므로 ICMP를 무시하는 호스트는 온라인이어도 나타나지 않습니다.
범위를 본인 것으로 바꾸세요 — 위의 게이트웨이와 마스크에서 확인할 수 있습니다. 소유하거나 관리하는 네트워크만 스캔하세요. 타인의 네트워크 스캔은 지역에 따라 형사 범죄이며, 기록이 남습니다.
네트워크에 자신을 알리는 서비스 검색
기본 설치되지 않음dns-sd -B _services._dns-sd._udp local.avahi-browse -a -tWindows 에는 직접적인 대응 명령이 없습니다.
Linux:
sudo apt install avahi-utils.프린터, 스피커, NAS 등이 mDNS로 스스로를 알립니다. 스캔이 아니라 동의에 의한 검색입니다.
외부로 나가는 경로
이 사이트의 네트워크 리포트는 MyIPKit 엣지까지의 HTTP 지연시간만 측정합니다. 아래는 실제 경로를 홉 단위로 측정합니다.
진짜 ICMP ping — 브라우저가 할 수 없는 것
ping -c 10 1.1.1.1ping -c 10 1.1.1.1ping -n 10 1.1.1.1이 사이트의 네트워크 리포트와 비교해 보세요. 자주 다릅니다. 많은 네트워크가 일반 웹 트래픽보다 ICMP의 우선순위를 낮추기 때문입니다.
목적지까지의 모든 홉
기본 설치되지 않음traceroute 1.1.1.1traceroute 1.1.1.1tracert 1.1.1.1Debian/Ubuntu:
sudo apt install traceroute.첫 홉은 공유기입니다. 별표는 그 홉이 응답하지 않았다는 뜻이며, 흔한 일이고 그 자체로 문제는 아닙니다. 지연시간이 급격히 뛰는 지점을 보세요.
홉별 손실과 지연시간 연속 측정
기본 설치되지 않음mtr 1.1.1.1mtr 1.1.1.1pathping 1.1.1.1macOS:
brew install mtr. Debian/Ubuntu:sudo apt install mtr.간헐적 문제에 가장 좋은 도구입니다. 특정 홉에서만 손실이 보이고 이후 홉에서 사라진다면, 실제 패킷 손실이 아니라 그 라우터가 ICMP 우선순위를 낮춘 것입니다.
분할 없이 지나갈 수 있는 최대 패킷 크기 찾기
ping -D -s 1472 -c 3 1.1.1.1ping -M do -s 1472 -c 3 1.1.1.1ping -f -l 1472 1.1.1.11472 + 헤더 28바이트 = 1500, 일반적인 이더넷 MTU입니다. 이 크기는 실패하고 더 작은 크기는 성공한다면 MTU 문제일 가능성이 큽니다. VPN과 PPPoE 회선에서 “어떤 사이트는 열리고 어떤 사이트는 멈추는” 전형적인 원인입니다.
내 컴퓨터에서 보는 DNS
이 사이트의 DNS 조회 도구는 공개 리졸버에 질의합니다. 아래는 내 네트워크가 실제로 지정해 준 리졸버에 질의합니다. 트래픽이 실제로 어디로 갈지를 결정하는 것은 이쪽입니다.
내 컴퓨터가 사용하도록 설정된 리졸버
scutil --dns | grep nameserverresolvectl status | grep "DNS Servers"ipconfig /all | findstr /i "DNS Servers"공유기나 통신사라면 내 질의가 그들에게 보입니다. 1.1.1.1 이나 8.8.8.8 이라면 기본값을 직접 바꾼 것입니다.
내 리졸버로 이름 해석하기
dig example.comdig example.comnslookup example.com이 사이트의 DNS 조회 도구와 비교해 보세요. 결과가 다르면 내 리졸버가 캐시되었거나 필터링되었거나 덮어쓴 답을 주고 있는 것입니다.
내 리졸버와 공개 리졸버 비교
dig example.com @1.1.1.1dig example.com @1.1.1.1nslookup example.com 1.1.1.1DNS 수준의 필터링, 캡티브 포털, 오래된 캐시를 가장 확실하게 찾아내는 방법입니다.
루트 서버부터 이름을 추적하기
dig +trace example.comdig +trace example.comWindows 에는 직접적인 대응 명령이 없습니다.
전체 위임 체인을 보여줍니다. 어떤 사람에게는 도메인이 해석되고 어떤 사람에게는 안 될 때 쓰는 도구입니다.
로컬 DNS 캐시 비우기
관리자 권한 필요sudo dscacheutil -flushcache; sudo killall -HUP mDNSRespondersudo resolvectl flush-cachesipconfig /flushdnsDNS 레코드를 변경한 뒤, 변경이 적용되지 않았다고 결론 내리기 전에 실행해 보세요.
이 컴퓨터의 포트와 연결
내 컴퓨터가 무엇을 대기(listen)하고 무엇과 연결되어 있는지입니다. 완전히 로컬이며, 인터넷에서 자기 자신을 스캔하는 것의 올바른 대안입니다.
들어오는 연결을 대기 중인 모든 것
관리자 권한 필요sudo lsof -nP -iTCP -sTCP:LISTENsudo ss -tulpnnetstat -ano | findstr LISTENING0.0.0.0 이나 :: 에 바인드된 것은 네트워크에서 연결을 받습니다. 127.0.0.1 에 바인드되어 있으면 이 컴퓨터에서만 접근할 수 있습니다.
현재 수립된 연결
netstat -an | grep ESTABLISHEDss -tan state establishednetstat -an | findstr ESTABLISHED“이 컴퓨터가 지금 실제로 무엇과 통신하는가?” 에 답할 때 유용합니다.
특정 호스트의 특정 포트에 닿는지 확인
nc -vz example.com 443nc -vz example.com 443Test-NetConnection example.com -Port 443관리하는 호스트의 개별 포트를 확인하세요. 소유하지 않은 호스트의 포트를 훑는 것은 포트 스캐너가 하는 일이며, MyIPKit이 결코 제공하지 않을 기능입니다.
내 컴퓨터가 보는 TLS 인증서 확인
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -datesopenssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -datesWindows 에는 직접적인 대응 명령이 없습니다.
주체, 발급자, 유효 기간을 출력합니다. 발급자가 예상과 다르다면 누군가 연결을 가로채고 있는 것입니다. 회사 프록시일 수도 있고, 더 나쁜 것일 수도 있습니다.
Wi-Fi 품질
문제가 기기와 공유기 사이에 있다면, 인터넷 쪽에서 아무리 측정해도 찾을 수 없습니다.
신호 세기, 잡음, 협상된 전송률
system_profiler SPAirPortDataType | grep -A 10 "Current Network"iwconfig 2>/dev/null || nmcli dev wifinetsh wlan show interfacesmacOS에서 RSSI가 −60 dBm 이상이면 강하고 −75 dBm 이하면 약합니다. 신호 자체보다 신호와 잡음의 차이가 더 중요합니다.
주변 네트워크가 사용 중인 채널
system_profiler SPAirPortDataType | grep -i channelsudo iwlist scan | grep -E "ESSID|Channel|Quality"netsh wlan show networks mode=bssid2.4 GHz에서는 채널 1, 6, 11만 서로 겹치지 않습니다. 이웃들이 내 채널에 몰려 있는 것은 통신사 장애처럼 보이는 지연의 흔한 원인입니다.
참고 자료 — 이 페이지는 아무것도 실행하거나 전송하지 않습니다
브라우저가 웹사이트에 주는 것과 주지 않는 것
많은 사이트가 그렇지 않은 것처럼 암시하기 때문에, 이 부분은 정확히 짚어 둘 가치가 있습니다.
서버가 실제로 받는 것
- 게이트웨이의 공인 IP 주소 — 내가 만든 그 연결 하나에 대한 주소 하나.
- User-Agent와 언어처럼 브라우저가 보내기로 한 HTTP 헤더.
- 그 공인 주소로부터 엣지 네트워크가 추정한 대략적인 위치. 언제나 근사치입니다.
서버가 결코 받지 못하는 것
- 사설 주소, 서브넷 마스크, 공유기 주소.
- 네트워크에 있는 기기 목록.
- MAC 주소, 호스트 이름, ARP 테이블.
- 내 컴퓨터나 네트워크의 다른 장비에서 열려 있는 포트.
과거의 두 누출 경로와, 그것이 막힌 이유
WebRTC 는 ICE 후보에 사설 주소를 노출하곤 했습니다. 2020년부터 Chrome, Edge, Firefox, Opera, Brave는 이를 .local 로 끝나는 무작위 호스트 이름으로 기본 대체하며, Safari도 거의 같습니다. 이제 읽을 주소 자체가 없습니다.
타이밍 기반 스캔 — 사설 주소에 요청을 보내고 실패 속도로 무엇이 있는지 추론하는 방식 — 이 다른 하나였습니다. Chrome 142는 2025년 10월 Local Network Access를 도입해, 공개 사이트가 사설 또는 루프백 주소로 보내는 모든 요청을 권한 프롬프트 뒤에 두었습니다. 구글이 밝힌 이유에는 사이트가 방문자의 로컬 네트워크를 핑거프린팅하는 것을 줄이는 것이 포함됩니다.
MyIPKit은 두 기법이 아직 동작하더라도 구현하지 않을 것입니다. 방문자의 네트워크를 탐색하는 공개 사이트는 동의한 적 없는 사람들의 네트워크를 스캔하는 사이트이며, 그에 걸맞은 평판을 얻게 됩니다.
이 웹사이트가 그냥 제 로컬 네트워크를 보여주면 안 되나요?
권한 문제가 아닙니다. 브라우저는 구조적으로 그 정보를 웹사이트에 넘기지 않습니다. 서버가 받는 것은 NAT 게이트웨이의 공인 주소뿐이며, 사설 주소·서브넷·공유기·연결된 기기는 애초에 요청에 포함되지 않습니다. 또한 브라우저는 WebRTC의 로컬 주소를 무작위 .local 호스트 이름으로 대체하고, Chrome 142부터는 공개 사이트가 로컬 IP에 접근하려면 명시적 권한 프롬프트가 필요합니다. 바로 사이트가 네트워크를 핑거프린팅하지 못하게 하려는 조치입니다.
이 명령어들을 실행해도 안전한가요?
여기 나열된 모든 명령어는 읽기 전용이며 설정을 바꾸지 않습니다. 일부는 모든 프로세스를 보기 위해 관리자 권한이 필요하며 그렇게 표시해 두었습니다. 진짜 주의가 필요한 것은 네트워크 스캔 하나이며, 소유하거나 관리하는 네트워크에만 사용해야 합니다.
명령어 출력이 MyIPKit이 보여주는 값과 다릅니다. 어느 쪽이 맞나요?
보통 둘 다 맞습니다. 서로 다른 것을 측정하기 때문입니다. MyIPKit은 인터넷에 보이는 주소를, 내 컴퓨터는 로컬에서 갖고 있는 주소를 보고합니다. NAT 뒤에서는 언제나 다릅니다. curl과 이 사이트의 공인 주소가 다르다면 보통 한쪽에만 VPN이나 프록시가 적용된 것입니다.