Starlink 문제일까요, Wi-Fi 문제일까요? 결함을 진단하는 방법
이를 가장 빠르게 판가름하는 방법은 동일한 테스트를 두 곳에서 동시에 실행하는 것입니다. 영향을 받은 기기에서, 그리고 Starlink 라우터 자체의 API를 통해 직접 실행합니다. 라우터 쪽 결과는 깨끗한데 기기 쪽은 그렇지 않다면, 결함은 안테나나 위성 링크가 아니라 로컬 네트워크에 있습니다. 그 한 가지 비교가 대부분의 "Starlink가 느려요" 불만을 해결하며, 이 가이드는 그 방법과, 안테나가 정말로 문제일 때 뒤따르는 점검을 안내합니다.
이 글은 결함 신고를 처리하는 설치업체와 엔지니어를 위해 작성되었지만, 자신의 연결을 진단하는 데도 똑같이 적용됩니다.
대부분의 Starlink 불만은 왜 Wi-Fi 문제로 밝혀질까요?
고객은 하나, 즉 "인터넷"을 경험하며, 대부분의 가정과 선박에서 가장 약한 고리는 그 마지막 10미터이기 때문입니다. 먼 방, 두꺼운 벽, 혼잡한 2.4 GHz, 컨디션이 좋지 않은 파워라인 어댑터, 이 모든 것이 "Starlink가 느려요"로 나타납니다. 안테나는 눈에 보이는 새로운 것이라서 비난을 받습니다. 사다리를 만지기 전에, 문제가 라우터의 어느 쪽에 있는지 증명하세요.
이중 경로 테스트는 어떻게 실행하나요?
Nexus Telemetry Pro에서 진단을 열고 8.8.8.8 같은 안정적인 대상에 핑을 실행하세요. Pro는 이를 병렬로 두 번 실행합니다. 한 번은 사용 중인 기기에서, 한 번은 Starlink 라우터의 API를 통해서, 그래서 라우터 자체가 동일한 대상까지의 자체 경로를 보고합니다. 결과가 나란히 놓입니다.
이렇게 읽으세요. 둘 다 깨끗하면, 연결은 처음부터 끝까지 정상이며 불만을 좁혀야 합니다(특정 서비스, 특정 시간대). 라우터 쪽은 깨끗한데 기기 쪽이 손실이나 높은 지연 시간을 보이면, 결함은 기기와 라우터 사이에 있습니다. Wi-Fi 커버리지, 간섭, 또는 로컬 네트워크 장비입니다. 양쪽 모두 동일한 손실이나 지연 시간을 보이면, 문제는 정말로 상류에, 안테나나 위성 링크에 있으며, 아래의 안테나 점검으로 넘어갑니다.
정말로 안테나가 문제일 때는 무엇을 확인하나요?
세 곳을, 순서대로.
이벤트 로그. 안테나는 모든 중단과 이벤트를 지속 시간과 타임스탬프와 함께 기록하며, 각각 원인이나 심각도로 태그가 붙습니다. no-downlink 이벤트, 핑 실패, 장애물로 인한 중단, 그리고 레인 페이드 권고 사항 등이 그 안에 있습니다. 패턴이 곧 진단입니다. 1초 미만의 no-downlink 이벤트 무리는 장애물을 가리킵니다. "switched" 플래그가 붙은 가끔의 더 긴 중단은 네트워크 쪽입니다. 매일 같은 시각에 시끄러워지는 로그는 하늘 시야를 가로지르는 어떤 환경적 요인을 시사합니다.
장애물. 비율만이 아니라 지도를 보세요. 초목은 자라고 물건은 옮겨지므로, 인계 시점에 깨끗했던 설치가 아무도 안테나를 건드리지 않아도 저하될 수 있습니다. 장애물 문제 해결 가이드가 그것을 읽고 해결하는 방법을 다룹니다.
정렬. 액추에이터가 달린 안테나는 스스로 다시 조준할 수 있고, 아주 드물게 펌웨어 업데이트가 하나를 움직이기도 합니다. 눈에 보이는 이유 없이 성능이 바뀌었다면, 현재의 기울기, 방위각, 고도각을 원하는 값과 비교하세요. 저희는 펌웨어 업데이트 후 안테나가 조용히 190° 회전한 것을 한 번 잡아낸 적이 있습니다. 재부팅으로 원위치되었습니다.
지연 시간 문제와 처리량 문제를 어떻게 구분하나요?
이들은 원인도 다르고 테스트도 다릅니다. 지연 시간의 경우, 핑 매트릭스가 여러 지역에 걸친 수십 개의 실제 목적지를 한 번에 테스트하는데, 이는 높은 지연 시간이 전반적인지(링크 문제) 아니면 한 지역이나 서비스에 국한되는지(직접 고칠 수 있는 대상이 아닌 라우팅 문제)를 즉시 보여 줍니다. 무엇이 정상으로 간주되는지는 좋은 Starlink 핑이란에서 다룹니다.
처리량의 경우, 브라우저 속도 테스트는 테스트 서버의 컨디션을 포함한 전체 경로를 측정합니다. iPerf는 직접 제어하는 두 대의 기기 사이의 순수 처리량을 측정하므로, "링크가 느려요" 주장에 대한 정직한 도구이며, 진단 모음에는 traceroute, DNS 조회, 포트 점검과 함께 iPerf 클라이언트가 포함됩니다. 경험에서 나온 한 가지 주의 사항: 공개 iPerf 서버는 자주 붐비거나 도달 불가능하므로, 실패한 공개 서버 테스트는 증거가 아니라 결론을 내릴 수 없는 것으로 취급하세요. Windows에서 iPerf를 설정하는 것은 그 자체로 작은 시련이므로, 저희가 정리해 두었습니다.
기준선은 대화를 어떻게 바꾸나요?
인계 시점에 녹화된 세션으로 설치가 검증되었다면, 결함 판단은 증거에서 시작됩니다. 그 정확한 위치에서 첫날에 안테나가 어떻게 작동했는지 말입니다. 짧은 진단 세션을 녹화하고, 보고서를 내보내고, 둘을 나란히 놓으세요. 패킷 손실률이 0이었던 곳에서 올라가고, 장애물이 0%에서 올라가고, 지연 시간은 그대로라면, 그 비교는 대개 누군가가 무언가를 오르기 전에 원인을 지목합니다. 그 기준선 워크플로가 바로 검증 가이드입니다.
짧은 요약
먼저 이중 경로 핑을 실행하세요. 기기와 라우터를 나란히. 깨끗한 라우터 쪽은 LAN 문제를 의미하며, 고객에게 현장에서 보여 줄 수 있습니다. 양쪽에서 일치하는 저하는 안테나를 의미합니다. 이벤트 로그에서 패턴을 읽고, 장애물 지도를 확인한 다음, 정렬을 확인하세요. 지연 시간 질문에는 핑 매트릭스를, 처리량 주장에는 직접 제어하는 서버에 대한 iPerf를 사용하고, 인계 기준선이 있다면 그것과 대조해 진단하세요.
설치업체와 전문가를 위한 Starlink의 일부입니다. Nexus Telemetry는 최초의 Starlink Enterprise 관리 플랫폼을 만든 팀인 Liquidbinary Ltd가 제작합니다. Pro는 Windows, macOS, Linux에서 네이티브로 실행되며 무료 체험판이 있습니다.