연결이 느릴 때 점검하는 순서

“인터넷이 느리다”는 원인이 최소 여섯 가지인 증상이고, 보통의 대응인 “공유기 재부팅하고 잘 되길 빌기”는 그중 하나만 해결합니다. 바깥쪽으로 순서대로 확인하면 몇 분 만에 여섯 중 어느 것인지 나옵니다. 다섯 개는 공유기가 아니기 때문에 이게 중요합니다.

처음 실패하는 단계에서 멈추세요. 그 뒤의 것들은 어차피 전부 이상하게 보입니다.

1. 전부 그런가, 하나만 그런가

아무것도 건드리기 전에, 문제가 되는 것과 전혀 상관없는 걸 하나 열어보세요. 다른 서비스의 다른 사이트로요.

한 사이트만 느리면 그 사이트 문제고, 내가 로컬에서 뭘 하든 나아지지 않습니다. 그쪽 서버, 그쪽 CDN, 그쪽 지역의 문제입니다. 압도적으로 가장 흔한 답인데 가장 자주 건너뛰는 확인입니다.

전부 느리면 다음으로.

2. 이 기기만 그런가

같은 네트워크의 다른 기기로 해보세요. 휴대폰이면 충분합니다.

휴대폰은 멀쩡한데 노트북만 느리면 네트워크는 정상이고 노트북이 문제입니다. 흔한 순서대로: 뭔가가 회선을 다 쓰고 있거나(백업, 동기화 클라이언트, OS 업데이트), VPN이 멀리 있는 서버로 전부 우회시키고 있거나, 그 기기의 와이파이가 낮은 속도로 협상됐거나.

다른 걸 탓하기 전에 뭐가 네트워크를 쓰는지부터 보세요.

nettop -m tcp                   # macOS
ss -tunp                        # Linux
netstat -b                      # Windows, 관리자 권한 필요

목록 맨 위의 프로세스 하나가 답인 경우가 많습니다.

3. 와이파이인가, 회선인가

가능하면 랜선을 꽂아보세요. 랜선으로 해결되면 인터넷 문제가 아니라 와이파이 문제입니다. 와이파이 문제는 별개의 조사 영역입니다. 거리, 옆집 신호와의 간섭, 혼잡한 채널, 또는 오래된 기기 하나가 AP 전체를 느린 속도로 끌어내리는 경우.

랜선이 없다면 공유기 바로 옆에서 다시 해보세요. 확 좋아지면 신호 문제입니다.

실제로 어떤 속도로 연결됐는지 확인하세요.

wdutil info                     # macOS, sudo 필요
iw dev wlan0 link               # Linux
netsh wlan show interfaces      # Windows

하드웨어가 지원하는 것보다 수신 속도가 한참 낮거나 RSSI가 −70 dBm보다 나쁘면, 뒤쪽 회선이 아니라 신호가 원인입니다.

4. 내 네트워크가 공유기까지는 가는가

게이트웨이(내 네트워크에서 공유기의 주소)로 ping을 보내세요.

ping -c 20 192.168.1.1

본인 게이트웨이로 바꿔 쓰세요. macOS는 netstat -rn | grep default, Linux는 ip route | grep default, Windows는 ipconfig로 찾습니다.

볼 건 두 가지입니다. 손실은 0이어야 합니다. 여기서 손실이 나면 로컬 문제입니다. 케이블, 와이파이, 또는 맛이 가는 중인 공유기. 그리고 지연시간은 1~2ms로 안정적이어야 합니다. 2ms와 300ms 사이를 널뛰면 내 네트워크의 뭔가가 회선을 포화시키고 있다는 뜻이고, 범인만 다를 뿐 2단계로 돌아가게 됩니다.

게이트웨이가 아예 응답이 없고 내 주소가 169.254로 시작한다면 사설 IP와 공인 IP를 보세요. 느린 게 아니라 DHCP가 실패한 것입니다.

5. 회선이 아니라 DNS인가

DNS 장애는 느린 것처럼 아주 그럴듯하게 위장합니다. 페이지가 몇 초 멈춰 있다가 시작되면 순식간에 뜨거든요. 기다린 건 전송이 아니라 이름 풀이였기 때문입니다.

이름으로 가는 것과 주소로 직접 가는 것을 비교하세요.

ping -c 5 1.1.1.1
dig example.net

주소 ping은 멀쩡한데 이름 조회가 느리거나 실패하면, 회선은 건강하고 리졸버가 문제입니다. 1.1.1.1이나 8.8.8.8로 잠깐 바꿔서 해결되면 ISP 리졸버나 공유기의 DNS 중계가 범인입니다.

확실히 하려면 시간을 재세요.

dig example.net | grep "Query time"

캐시된 답이라면 50ms 안쪽이 정상입니다. 계속 500ms를 넘으면 리졸버 문제입니다.

6. 나가는 길 어디서 나빠지는가

이제서야 traceroute가 의미를 갖습니다. 앞의 다섯 단계가 나에게 가까운 것들을 전부 걷어냈기 때문에 비로소 쓸모가 있습니다.

mtr 1.1.1.1

1분쯤 돌려두세요. 어떤 홉에서 시작해 그 뒤 모든 홉까지 이어지는 손실이나 지연을 찾는 겁니다. 한 홉만 나쁘고 뒤가 멀쩡하면 거의 항상 그 라우터가 응답 생성을 뒤로 미루는 것이지 장애가 아닙니다. 이유는 traceroute 결과 읽는 법에 자세히 있습니다.

2~3번째 홉부터 나빠지기 시작해서 계속된다면 ISP 구간이고, 이제 제보할 구체적인 근거가 생긴 것입니다.

제보할 때 담을 것

두루뭉술한 제보에는 두루뭉술한 답이 옵니다. 이걸 담으세요.

• 언제 그런지. 상시인가, 특정 시간대인가? 시간대가 뚜렷하면 장애보다 혼잡일 가능성이 큽니다.
• 뭐가 아직 되는지. “전부 느린데 1.1.1.1은 손실 없이 12ms”가 “인터넷이 안 돼요”보다 훨씬 쓸모 있습니다.
• mtr이나 traceroute 3회 실행 결과, 실행 시각과 함께.
• 정상인 목적지와의 비교.
• 공인 주소와 ISP. 네트워크 리포트가 대신 모아줍니다. 원하시면 주소를 가린 채로요.

대략 1~3단계는 본인이 고칠 것, 4단계는 본인 장비, 5단계는 리졸버, 그리고 6단계만이 진짜 사업자 책임입니다. 전화하기 전에 어느 쪽인지 알고 가면, 저쪽이 “공유기 재부팅해보세요”로 쓸 20분을 아낄 수 있습니다.