문제 해결 총정리

점검 전: 4계층 경로부터 구분

가속 서비스의 장애 양상은 천차만별이지만, 문제가 생기는 위치는 네 곳뿐입니다. 계층별로 점검하면 클라이언트를 반복해서 재시작하는 것보다 훨씬 빠르고, 무관한 설정에 시간을 낭비하지 않아도 됩니다. 네 계층은 가까운 쪽부터 기기 네트워크, 클라이언트 트래픽 처리, 구독과 계정, 출구 노드입니다.

네 계층이 각각 담당하는 것

• 기기 네트워크 계층. 기기에서 공유기까지, 공유기에서 통신사까지입니다. 이 계층이 끊기면 어떤 회선도 연결되지 않으며, 모든 사이트가 열리지 않는 형태로 나타납니다.
• 클라이언트 계층. 클라이언트 프로세스가 실제로 트래픽을 넘겨받았는지, 시스템 프록시가 적용되었는지, 분기 규칙이 어떻게 판정하는지입니다. 이 계층에 문제가 생기면 연결됨으로 표시되지만 앱이 프록시를 타지 않습니다.
• 구독과 계정 계층. 구독 링크의 토큰이 유효한지, 회선 목록이 최신인지, 이용 기간이 남아 있는지입니다. 이 계층에 문제가 생기면 회선 목록이 비어 있거나 갱신에 실패합니다.
• 출구 노드 계층. 착지 노드에서 목표 사이트까지의 경로입니다. 이 계층에 문제가 생기면 특정 지역이나 특정 사이트만 안 되는 형태로 나타납니다.

판단 순서는 가까운 쪽에서 먼 쪽으로 갑니다. 먼저 기기가 정상적으로 인터넷에 접속되는지 확인하고, 다음으로 클라이언트가 트래픽을 넘겨받았는지, 그다음 구독과 계정 상태를 보고, 마지막에야 노드를 의심하세요. 순서를 뒤집으면 흔히 로컬 네트워크 문제를 노드 문제로 오인해 모든 회선을 바꿔 봐도 해결되지 않는 결말을 맞습니다.

30초 출발점

클라이언트를 끄고 국내 사이트를 하나 엽니다. 열리면 기기 네트워크는 정상이므로 다음으로 넘어가고, 열리지 않으면 기기 네트워크부터 고쳐야 하며 뒤 단계는 할 필요가 없습니다. 너무 단순해 보이는 단계지만, 실제 점검에서는 상당수의 '연결 불가'가 결국 여기서 판명됩니다. 공유기 다운, 인터넷 요금 미납, 공용 Wi-Fi의 포털 인증 필요 같은 경우입니다.

세 가지 명령으로 경로 확인

GUI로는 보이지 않는 문제도 명령줄에서는 더 구체적인 정보를 볼 수 있습니다. 아래 명령은 각 운영체제에 기본 포함되어 있어 따로 설치할 필요가 없습니다.

명령에 있는 www.example.com은 접속하려는 임의의 도메인으로 바꿔도 됩니다. 도메인 ping은 실패하는데 알려진 주소로 ping이 통한다면 문제는 경로가 아니라 해석에 있으므로 DNS 장으로 바로 넘어가세요.

한 번에 변수 하나만 바꾸기

점검에서 가장 흔한 실수는 한 번에 세 가지를 바꾸는 것입니다. 회선 교체, 프로토콜 교체, 클라이언트 재설치를 동시에 하는 경우입니다. 잘 되면 무엇이 효과가 있었는지 모르고, 안 되면 어느 단계로 되돌려야 할지 모릅니다. 올바른 방법은 현재 상태를 기록하고 한 항목만 바꾼 뒤 즉시 다시 측정하고, 안 되면 되돌리는 것입니다. 이 습관은 문의를 접수할 때도 유용합니다. 상담원이 이를 근거로 환경을 재현할 수 있습니다.

먼저 증거를 남기고 손대기

클라이언트에는 보통 연결 로그나 진단 메뉴가 있습니다. 문제가 생기면 먼저 로그를 내보내거나 화면을 캡처하세요. 특히 오류 메시지 원문이 중요합니다. 클라이언트를 재설치하면 로컬 로그가 지워지므로 순서는 증거 확보가 먼저, 재설치는 그다음입니다. 문의에서 가장 가치 있는 세 가지는 오류 원문, 오류 발생 시각, 이미 시도한 단계입니다.

완전히 연결 불가: 오류가 뜨거나 계속 로딩만 될 때

먼저 두 가지 양상을 구분합니다. 하나는 클라이언트가 연결 실패나 연결 시간 초과를 명확히 알려 주는 경우로, 핸드셰이크 단계에서 실패했다는 뜻이므로 원인이 비교적 분명합니다. 다른 하나는 계속 연결 중으로만 표시되고 아무 반응이 없는 경우로, 대개 경로에서 패킷이 유실되거나 클라이언트 프로세스가 멈춘 상태입니다. 전자는 오류 메시지를 따라가고, 후자는 네트워크 환경을 따라가며 확인하세요.

네 단계로 원인 좁히기

1. 기기 네트워크 확인. 클라이언트를 끄고 국내 사이트에 접속합니다. 열리지 않으면 기기 네트워크부터 고치세요. 랜선, Wi-Fi 연결, 공유기 표시등, 공용 네트워크의 포털 인증을 확인합니다.
2. 다른 회선으로 재시도. 클라이언트에서 다른 지역의 회선으로 바꿉니다. 모든 회선이 실패하면 문제는 계정이나 구독 계층에 있고, 일부 회선만 실패하면 다른 회선으로 바꾸면 되니 더 손댈 필요가 없습니다.
3. 다른 네트워크로 재시도. 다른 네트워크로 한 번 연결해 봅니다. 네트워크를 바꾸면 연결된다면 원래 네트워크가 특정 포트나 프로토콜을 제한하는 것이지 계정 문제가 아닙니다.
4. 계정 상태 확인. 사용자 패널에 로그인해 구독이 유효 기간 내인지, 트래픽을 다 썼는지 확인합니다. 월 구독의 트래픽은 개통일 기준으로 매달 초기화되며, 트래픽 팩은 소진될 때까지 사용할 수 있고 만료되지 않습니다.

흔한 원인 대조

네 단계를 마쳤는데도 원인을 못 찾았다면 아래 표를 위에서부터 차례로 시도해 보세요.

시스템 시간은 가장 놓치기 쉬운 항목

암호화 핸드셰이크는 시간에 민감합니다. 기기 시각이 표준시와 몇 분만 어긋나도 인증서 검증이 실패해, 연결되자마자 끊기거나 핸드셰이크가 그대로 시간 초과되는 형태로 나타납니다. 노트북을 오래 인터넷에 연결하지 않았거나, 메인보드 배터리가 노후했거나, 시간대를 직접 바꾼 경우에 오차가 생깁니다. 시스템의 자동 시간 설정을 켜고 동기화가 끝난 뒤 다시 시도하세요.

보안 소프트웨어와 시스템 프록시 잔여 설정

일부 보안 소프트웨어는 클라이언트 프로세스의 네트워크 동작을 차단합니다. 특히 첫 실행 시 그렇습니다. 이때는 클라이언트가 연결됨으로 표시되지만 트래픽이 나가지 못합니다. 클라이언트를 신뢰 목록이나 허용 규칙에 추가한 뒤 다시 시도하세요. 다른 경우는 이전에 비정상 종료하면서 시스템 프록시 설정이 남아, 시스템이 이미 존재하지 않는 로컬 포트를 가리키는 상황입니다. 시스템 설정에서 프록시를 꺼짐으로 되돌린 뒤 클라이언트가 다시 넘겨받도록 하세요.

네 단계와 대조표를 모두 시도했는데도 문제가 안정적으로 재현되고, 네트워크와 기기를 바꿔도 결과가 같다면 로컬 환경 문제가 아니라고 판단할 수 있습니다. 마지막 장의 목록에 맞춰 정보를 정리해 문의를 접수하세요.

연결은 되는데 웹페이지가 안 열릴 때

클라이언트는 연결됨으로 표시되는데 브라우저는 계속 로딩만 되거나, 이 사이트에 접속할 수 없다는 메시지나 DNS 해석 실패가 뜹니다. 이 유형은 노드 고장으로 오인하기 쉽지만 실제로는 대부분 트래픽 처리 방식이나 해석 설정의 문제입니다. 먼저 모든 사이트가 안 되는지, 일부 사이트만 안 되는지 둘로 나눠 보세요.

모든 사이트가 안 열림

트래픽이 아예 나가지 못했거나, 나갔는데 돌아오지 못한 상태입니다. 세 곳을 순서대로 확인하세요.

• 시스템 프록시가 적용되었는지. Windows는 설정의 네트워크 및 인터넷 항목에서 프록시를 확인합니다. 클라이언트가 켜져 있으면 로컬 주소와 포트가 보여야 합니다. 꺼짐으로 표시되는데 클라이언트가 시스템 프록시 모드를 쓰고 있다면 트래픽 처리에 실패한 것입니다.
• 클라이언트가 TUN 모드인지. TUN 모드는 네트워크 인터페이스의 트래픽을 직접 넘겨받으므로 시스템 프록시가 꺼짐으로 표시되는 것이 정상입니다. 이때는 클라이언트 자체의 연결 상태와 트래픽 카운터가 증가하는지 확인해야 합니다.
• MTU가 맞는지. 연결은 되지만 큰 패킷이 버려지면 웹페이지가 절반쯤 로드되다 멈추고 결국 시간 초과가 납니다. 클라이언트의 MTU를 한 단계 낮춰 다시 시도하세요.

일부 사이트만 안 열림

트래픽은 나갔지만 분기 규칙이 해당 대상을 직결로 판정했거나, 대상 사이트가 지역 기준으로 요청을 거부한 상태입니다. 먼저 클라이언트를 전역 모드로 바꿔 한 번 검증하세요. 전역 모드에서 열리면 규칙 문제이고, 전역 모드에서도 안 열리면 대상 사이트나 회선 지역의 문제입니다.

규칙 모드에서 클라이언트는 도메인이나 주소를 보고 프록시를 탈지 결정합니다. 어떤 사이트는 여러 도메인을 쓰는데, 주 도메인은 프록시를 타고 정적 리소스 도메인은 직결로 판정되어 페이지 구조만 로드되고 스타일과 이미지가 모두 빠지는 경우가 있습니다. 이럴 때는 해당 사이트를 프록시 규칙에 추가하거나 임시로 전역 모드를 사용하세요.

브라우저 자체부터 배제하기

시크릿 창으로 같은 사이트를 열어 보세요. 시크릿 창에서는 열리고 일반 창에서는 안 열린다면 대개 캐시나 HSTS 기록 문제이므로 캐시를 한 번 지우면 됩니다. 또한 브라우저에 내장된 보안 DNS는 시스템 해석을 우회해 분기 규칙을 무력화하므로 점검하는 동안은 꺼 두세요.

출구 지역 확인

어떤 사이트는 열리지 않는 것이 아니라 열린 뒤 지역 사용 불가 메시지가 뜹니다. 이는 고장이 아니라 출구 지역이 사이트 요구 조건과 맞지 않는 것입니다. 클라이언트의 연결 상세에서 현재 출구 지역을 확인하고, 대상 사이트가 지원하는 지역으로 바꾸세요. 스트리밍과 AI 도구는 지역 판정이 특히 엄격한데, 자세한 내용은 사이트 내 AI 가속 특집에서 확인할 수 있습니다.

속도 저하와 저녁 피크 버벅임

느린 상황에도 최소 세 가지 유형이 있고 대처법이 전혀 다릅니다. 웹페이지가 느린 것은 첫 바이트 시간이 긴 경우로 대개 지연이 높거나 해석이 느린 탓입니다. 다운로드가 느린 것은 지속 속도가 나오지 않는 경우로 대개 대역폭 제한이나 경로 혼잡 때문입니다. 영상이 끊기는 것은 화질이 떨어지고 버퍼링이 잦은 경우로 대개 대역폭은 충분하지만 지터가 큰 상태입니다. 어느 유형인지 먼저 구분한 뒤 맞춰 대응하세요.

구간별로 먼저 측정

1. 클라이언트를 끄고 기준 측정. 기기에서 국내 사이트까지의 속도를 한 번 측정해 결과를 기록합니다.
2. 클라이언트를 켜고 측정. 가장 가까운 지역에 연결해 다시 측정합니다. 하락 폭이 크다면 이 회선의 로컬 구간 품질이 보통이라는 뜻입니다.
3. 같은 지역의 다른 유형으로 다시 측정. 같은 지역에도 전용선, 중계, 직결 등 여러 유형의 회선이 있는 경우가 많습니다. 각각 측정하면 차이가 뚜렷하게 드러납니다.

속도를 측정할 때는 백그라운드 다운로드, 클라우드 동기화, 시스템 업데이트를 꺼 두세요. 속도 측정 앱의 순간 최고치는 참고 가치가 크지 않으며, 1분간 지속 다운로드의 평균값이 실제 체감에 더 가깝습니다.

저녁 피크는 물리적 현상

20:00부터 23:00까지는 국제 구간이 가장 혼잡한 시간대입니다. 이 시간에는 국제 출구의 공용 대역폭을 다수 사용자가 공유하므로 지연이 올라가고 패킷 손실이 늘어나며, 어떤 서비스도 이를 피할 수 없습니다. 차이는 회선 유형에서 갈립니다. 전용선은 독립 통로를 사용해 공용 출구와 대역폭을 다투지 않으므로 피크 시간대에도 비교적 안정적입니다. 중계는 중계 노드를 거쳐 해외로 나가므로 비용이 낮은 대신 피크 시간대 변동이 전용선보다 큽니다. 직결은 공용 인터넷 출구를 그대로 사용하므로 가격이 가장 낮고 피크 시간대에 가장 불안정합니다.

주 용도가 저녁 시간대 4K 시청이나 장시간 회의라면 전용선 유형을 우선 선택하세요. 낮에 자료만 검색한다면 직결로도 충분합니다. 회선 페이지에는 90+ 국가 / 220+ 회선이 지역별로 묶여 있으니 용도에 맞춰 고를 수 있습니다.

로컬에서 할 수 있는 최적화

• 유선 우선. Wi-Fi는 2.4GHz 대역에서 간섭을 받기 쉬우므로 랜선을 꽂을 수 있으면 꽂으세요.
• 듀얼 밴드 분리. 공유기에서 2.4G와 5G를 하나의 이름으로 묶으면 기기가 2.4G에 붙을 수 있습니다. 이름을 분리한 뒤 5G에 직접 연결하세요.
• 프로토콜 교체. 같은 노드라도 프로토콜마다 간섭 내성이 다릅니다. 특정 네트워크에서 한 프로토콜이 속도 제한을 받는다면 다른 프로토콜로 바꿨을 때 회복되는 경우가 있습니다.
• 백그라운드 점유 끄기. 시스템 업데이트, 클라우드 동기화, 클라우드 백업은 모두 백그라운드에서 대역폭을 잡아먹습니다.
• 브라우저 부담 줄이기. 광고 차단 확장을 너무 많이 설치하거나 탭을 수십 개 열어 두면 웹페이지도 느리게 느껴집니다.

4K와 장시간 회의의 요구 조건

4K 스트리밍 플랫폼은 보통 십수에서 이십수 Mbps의 안정적인 대역폭을 권장합니다. 중요한 것은 최고치가 아니라 안정성입니다. 화상 회의는 지연과 지터를 더 중요하게 보므로 대역폭이 충분해도 지터가 크면 끊기고 소리가 빠집니다. 두 시나리오 모두 속도 측정 숫자만 볼 것이 아니라 전용선 유형을 우선 선택해야 합니다.

느낌보다 기록이 정확

같은 회선도 시간대에 따라 성능 차이가 클 수 있습니다. 아침, 저녁, 심야에 각각 측정해 결과를 기록한 뒤 회선 문제인지 시간대 문제인지 판단하세요. 이 기록은 문의를 접수할 때도 가장 유용한 자료 중 하나로, '느린 것 같다'보다 훨씬 구체적입니다.

잦은 연결 끊김과 모바일 백그라운드 종료

끊김은 두 가지로 나뉩니다. 데스크톱에서 일정 시간마다 끊기는 경우와, 모바일에서 백그라운드로 보낸 뒤 한동안 지나면 끊기는 경우입니다. 원인이 전혀 다르므로 따로 처리하세요.

데스크톱의 주기적 끊김

• 시스템 절전. PC가 절전 상태에서 깨어나면 연결을 보통 다시 세워야 합니다. 클라이언트에 절전 해제 후 자동 재연결 옵션이 있는지 확인하세요.
• 네트워크 어댑터 전원 관리. Windows는 기본적으로 전원 절약을 위해 어댑터를 끌 수 있게 허용하며, 어댑터가 꺼지면 연결도 자연히 끊깁니다. 장치 관리자에서 이 항목을 해제하세요.
• 공유기 세션 만료. 트래픽이 없는 상태가 길어지면 공유기가 세션 테이블 항목을 회수합니다. 클라이언트의 연결 유지(keep-alive) 또는 하트비트 기능을 켜세요.
• Wi-Fi 로밍. 집에 액세스 포인트가 여러 대라면 기기가 액세스 포인트 사이를 옮길 때 잠시 끊깁니다.
• 통신사 정기 재접속. 일부 인터넷 회선은 24시간마다 한 번 재접속하며, 끊기는 시점이 일정하므로 그 시각에 맞춰 검증할 수 있습니다.

모바일 백그라운드 끊김

iOS와 Android 모두 백그라운드에서 네트워크 활동을 회수합니다. 이는 시스템의 절전 정책이지 클라이언트 고장이 아닙니다. 백그라운드에서도 연결을 유지하려면 클라이언트를 시스템 화이트리스트에 추가해야 합니다.

시스템 설정 외에 흔한 상황이 두 가지 더 있습니다. 하나는 네트워크 전환입니다. Wi-Fi에서 셀룰러 데이터로 바뀔 때 연결을 다시 세워야 하므로 잠깐 끊기는 것은 정상입니다. 다른 하나는 화면 잠금 후 끊김입니다. 일부 기기의 절전 모드는 화면이 잠기면 백그라운드 네트워크를 제한하므로 클라이언트를 화이트리스트에 추가하면 완화됩니다.

클라이언트만 끊긴 것인지 기기 전체가 끊긴 것인지 먼저 구분

끊김이 발생했을 때 국내 사이트를 동시에 열어 보세요. 국내 사이트도 열리지 않으면 기기 전체의 네트워크 문제로 가속 서비스와 무관하고, 국내 사이트는 정상인데 프록시를 타는 트래픽만 끊긴다면 클라이언트나 회선의 문제입니다. 이 단계만으로 점검 범위를 절반으로 줄일 수 있습니다.

프록시 도구를 여러 개 겹쳐 쓰지 않기

더 안정적이길 바라며 클라이언트 두 개나 프록시 도구 두 개를 동시에 실행하는 것은 흔한 실수입니다. 서로 시스템 프록시 설정과 라우팅 테이블을 두고 다투기 때문에 양쪽 모두 불안정해지고, 로그까지 서로 오염되어 점검할 때 누구의 문제인지 알 수 없습니다. 같은 시점에는 하나만 유지하세요.

끊김이 일정 주기로 반복된다면(예: 한 시간에 한 번) 구체적인 시각을 기록하세요. 고정 주기는 대개 시스템 작업, 공유기 정책, 통신사 동작을 가리키므로 무작위 끊김보다 원인을 찾기 쉽습니다.

구독 갱신 실패

구독 링크는 토큰이 포함된 주소로, 클라이언트가 어떤 회선을 받아오고 어느 출구를 쓸지 결정합니다. 링크가 만료되거나 잘리거나 차단되면 갱신에 실패합니다. 더 자세한 원리는 사이트 내 글 “구독 링크란 무엇인가: 어디서 받고, 어떻게 가져오고, 얼마나 자주 갱신하나”에서 확인할 수 있습니다.

먼저 오류 유형 확인

처리 순서

1. 패널에서 다시 복사. 채팅 기록, 스크린샷, 오래된 메일에서 옮겨 적지 마세요. 복사할 때 한 글자만 빠져도 실패합니다.
2. 기존 구독을 삭제한 뒤 다시 가져오기. 갱신 버튼만 누르면 이미 손상된 로컬 캐시를 덮어쓰지 않는 경우가 있습니다.
3. 다른 네트워크 상태로 재시도. 먼저 프록시를 끄고 갱신해 보고, 프록시를 끄면 오히려 실패한다면 프록시를 켜고 시도하세요. 두 경우는 각각 구독 주소가 직결을 필요로 하는 상황과 프록시를 필요로 하는 상황에 해당합니다.
4. 기기 시간 확인. 시각 오차는 인증서 검증 실패를 일으켜 링크 만료와 비슷하게 보입니다.
5. 보안 소프트웨어 확인. 일부 보안 소프트웨어는 구독 주소 요청을 차단합니다.

구독 주소의 형식은 대략 다음과 같습니다. 이 문자열은 예시이며 그대로 사용할 수 없고, 실제 링크는 사용자 패널에서 복사합니다.

https://example.com/sub?token=YOUR_TOKEN

링크는 곧 자격 증명

구독 링크에는 토큰이 들어 있어, 이를 확보하면 회선을 받아갈 수 있습니다. 공개 그룹이나 스크린샷에 붙이지 말고 문의 본문에도 적지 마세요. 유출이 의심되면 패널에서 구독 링크를 재설정하세요. 기존 링크는 즉시 무효가 되고 클라이언트는 새 링크로 다시 가져와야 합니다. 재설정 후 기존 링크를 가져다 둔 클라이언트는 다음 갱신에서 실패하지만, 캐시된 회선이 목록에 남아 연결은 되는데 목표 사이트에 닿지 못하는 상황이 생길 수 있습니다. 이런 증상이 보이면 노드 고장으로 단정하지 말고 먼저 구독을 갱신하세요.

얼마나 자주 갱신해야 하나

클라이언트에서 자동 갱신을 설정할 수 있으며 하루 한 번이면 충분합니다. 회선이 조정되면 수동으로 한 번 갱신하면 됩니다. 자주 새로 고침해도 회선이 빨라지지 않고 불필요한 요청만 늘어납니다. 갱신 후 회선 수가 눈에 띄게 줄었다면 먼저 계정 상태를 확인하고, 그다음 클라이언트가 오래된 데이터를 캐시했는지 보세요.

갱신은 성공했는데 연결이 안 됨

이것은 다른 유형의 문제입니다. 구독 자체는 정상이지만 받아온 회선에 연결이 안 되는 경우입니다. 1장의 네 계층 판단으로 돌아가 기기 네트워크를 먼저 확인하고 회선을 바꿔 보세요. 모든 회선이 실패하는데 구독 갱신은 정상이라면 계정 상태와 로컬 네트워크 제한을 중점적으로 확인하세요.

특정 앱이 프록시를 타지 않을 때

시스템 프록시와 TUN 모드는 적용 범위가 다릅니다. 어떤 앱은 시스템 프록시 설정을 읽지 않고, 어떤 앱은 시스템에서 제한을 받으며, 어떤 앱은 자체 네트워크 스택을 구현합니다. 그래서 브라우저는 정상인데 특정 프로그램만 안 되는 상황이 생깁니다.

앱이 프록시를 타는지 먼저 확인

1. 클라이언트 로그 확인. 연결 로그를 열어 해당 앱의 요청 기록이 있는지 봅니다. 기록이 있으면 트래픽이 들어온 것이므로 문제는 출구에 있고, 기록이 없으면 트래픽이 아예 넘겨지지 않은 것입니다.
2. 전역 모드로 검증. 전역 모드에서는 모든 트래픽이 프록시를 탑니다. 이때 통하면 규칙 문제이고, 그래도 안 되면 앱 자체가 프록시를 지원하지 않는 것입니다.
3. 다른 기기로 검증. 같은 계정으로 다른 기기에서 같은 앱을 시험합니다. 두 기기 모두 안 되면 회선이나 앱의 문제이고, 한 기기에서만 안 되면 그 기기의 설정 문제입니다.

흔한 세 가지 상황

시스템 프록시를 읽지 않는 앱. 일부 데스크톱 소프트웨어, 게임 런처, 업데이터는 하위 네트워크 인터페이스를 직접 사용해 시스템 프록시 설정을 읽지 않습니다. 해결책은 TUN 모드로 모든 트래픽을 넘겨받는 것입니다.

앱 스토어 앱의 루프백 제한. 이런 앱은 기본적으로 로컬 루프백 주소 접근을 허용하지 않는데, 프록시 클라이언트는 보통 로컬에서 수신 대기합니다. 시스템에서 해당 앱의 루프백 예외를 켜야 하며, 그렇지 않으면 계속 네트워크 오류를 표시합니다.

UDP 앱. 음성, 게임, 일부 화상 통화는 UDP를 사용합니다. 현재 회선이 UDP를 지원하지 않으면 이런 기능은 실패하지만 웹페이지는 정상입니다. UDP를 지원하는 회선으로 바꾸거나 앱에서 QUIC을 끄세요.

브라우저 확장도 방해할 수 있음

일부 프록시 계열 브라우저 확장은 시스템 프록시를 덮어써서 브라우저와 시스템이 서로 다른 출구를 쓰게 만듭니다. 브라우저에서는 열리는 사이트가 데스크톱 프로그램에서는 안 열리거나 그 반대인 형태로 나타납니다. 점검할 때는 모든 프록시 계열 확장을 비활성화하고 클라이언트만 남기세요.

지역 판정이 엄격한 상황

스트리밍과 AI 도구는 출구 지역으로 사용 가능 여부를 판정하므로, 회선 지역이 맞지 않으면 연결이 되어도 거부됩니다. Midjourney는 Discord 안에서 돌아가 장기 연결의 안정성을 더 요구하며, 끊기면 이미지 생성이 그대로 실패합니다. 자세한 내용은 사이트 내 글 “AI 이미지 도구 가속 추천: Midjourney와 Discord 연결 실측 비교”에서 확인할 수 있습니다. ChatGPT 같은 도구는 지역에 더 민감하므로 사용 불가 메시지가 뜨면 먼저 지역을 바꾸고 그다음 다른 원인을 고려하세요.

DNS 이상과 해석 오류

DNS는 도메인을 주소로 변환합니다. 해석에 문제가 생기면 네트워크는 분명히 연결되어 있는데 도메인이 열리지 않는 형태로 나타납니다. 이 유형의 장애는 노드 고장으로 오인되기 가장 쉽습니다.

세 가지 전형적인 증상

• 해석 시간 초과. 브라우저가 오래 로딩하다가 결국 접속할 수 없다고 표시합니다.
• 잘못된 주소로 해석. 도메인이 무관한 주소로 해석되어 페이지가 열리지 않거나 다른 사이트로 넘어갑니다.
• 일부 도메인만 해석 실패. 같은 네트워크에서 어떤 도메인은 열리고 어떤 도메인은 열리지 않습니다.

로컬 해석과 원격 해석

프록시를 쓰지 않을 때 DNS 조회는 로컬 통신사로 향합니다. 프록시를 켠 뒤 클라이언트가 로컬 해석으로 설정되어 있으면 조회는 여전히 통신사를 거치고 결과만 연결 수립에 쓰입니다. 원격 해석으로 설정되어 있으면 조회가 출구 노드로 전달되어 출구 측 DNS가 해석하므로 결과가 대상 사이트의 실제 위치에 더 가깝습니다. 국제 구간을 오가는 상황에서는 로컬 해석이 겪을 수 있는 간섭을 피할 수 있어 원격 해석이 보통 더 신뢰할 만합니다.

점검 단계

1. 명령줄 검증. nslookup www.example.com으로 해석 결과를 확인하고, macOS와 Linux에서는 dig www.example.com +short도 사용할 수 있습니다.
2. 프록시를 켜고 끈 결과 비교. 프록시를 끄면 잘못된 주소로 해석되고 켜면 정상이라면 로컬 해석이 간섭을 받는 것이므로 원격 해석으로 바꿔야 합니다.
3. 브라우저 보안 DNS 확인. 브라우저 내장 보안 DNS는 시스템 해석을 우회해 분기 규칙을 무력화합니다. 점검하는 동안은 꺼 두세요.
4. 클라이언트 DNS 설정 확인. 원격 해석을 우선 선택하세요. 로컬 해석을 반드시 써야 한다면 시스템 DNS를 신뢰할 수 있는 공용 해석 서비스로 바꾸세요.
5. 캐시 삭제. 시스템과 브라우저 모두 DNS 캐시를 가지므로 설정을 바꾼 뒤 한 번 지워야 합니다.

nslookup www.example.com
dig www.example.com +short

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache

앞의 두 가지는 조회이고, 뒤의 두 가지는 캐시 삭제입니다. Linux에서는 resolvectl flush-caches를 쓰거나 로컬 해석 서비스를 재시작하면 됩니다.

설정 변경 도구를 여러 개 겹쳐 쓰지 않기

DNS를 바꾸는 도구를 여러 개 동시에 설치하면 서로 덮어써서 설정이 적용된 것처럼 보이지만 실제로는 바뀌지 않습니다. 점검할 때는 하나만 남기고, 변경 후 클라이언트를 재시작하세요.

원격 해석을 켜고 캐시도 지웠는데도 일부 도메인만 실패한다면 실패한 도메인과 해석 결과를 기록해 오류 발생 시각과 함께 문의로 접수하세요. 이런 문제는 특정 도메인의 해석 경로와 관련된 경우가 많아 출구 측 확인이 필요합니다.

계정 상태, 기기 수, 문의 접수

앞의 여덟 장은 연결과 설정을 다뤘습니다. 이 장은 계정 차원의 문제, 그리고 점검을 마친 뒤 문제를 어떻게 넘겨야 하는지를 다룹니다.

기기 수는 제한 항목이 아님

본 서비스는 동시 접속 기기 수에 제한이 없습니다. Windows, macOS, iOS, Android, Linux에서 동시에 로그인해 사용할 수 있으며, 기기가 하나 늘었다고 요금제를 올릴 필요가 없습니다. 따라서 기기 수 초과 같은 안내는 본 서비스에서 나오지 않습니다. 로그인 후 접속이 끊긴다면 같은 계정으로 여러 곳에서 반복 로그인했거나 비밀번호가 다른 사람에게 알려진 경우일 가능성이 크므로 먼저 패널에서 비밀번호를 변경하세요.

계정 상태의 세 가지 경우

• 구독 만료. 월 구독은 개통일 기준으로 매달 트래픽이 초기화되며, 만료 후에는 회선 목록이 비거나 연결할 수 없습니다.
• 트래픽 소진. 월 구독 트래픽을 다 쓰면 그달에는 계속 사용할 수 없습니다. 패널에서 상위 요금제로 업그레이드할 수 있으며 차액은 남은 일수로 계산됩니다. 트래픽 팩을 구매할 수도 있고, 트래픽 팩은 소진될 때까지 사용할 수 있으며 만료되지 않습니다.
• 비밀번호 문제. 가입에는 사용자 이름과 비밀번호만 필요하며 이메일 주소는 필요하지 않습니다. 비밀번호를 잊었다면 패널의 찾기 메뉴를 이용하세요.

월 구독은 세 가지입니다: ¥9.9/월 60GB, ¥18/월 250GB, ¥28/월 500GB. 트래픽 팩도 세 가지입니다: ¥158/300GB, ¥358/1000GB, ¥658/3000GB. 결제 수단은 알리페이, 위챗, USDT를 지원합니다. 가격과 용량은 요금제 페이지를 기준으로 합니다.

언제 점검을 멈추고 문의해야 하는가

앞의 장들을 모두 따라 했는데도 아래 중 하나라도 해당하면 더 손대지 마세요.

• 문제가 안정적으로 재현되고 네트워크, 기기, 회선을 바꿔도 결과가 같습니다.
• 계정 상태가 실제와 다릅니다. 예를 들어 결제했는데 미개통으로 표시되거나 트래픽 집계가 명백히 이상합니다.
• 구독 링크를 재설정한 뒤에도 갱신이 되지 않습니다.
• 클라이언트 로그에 일정한 오류 코드가 남고 대조표의 처리 방법이 모두 효과가 없습니다.

문의에 첨부할 정보

구독 링크 전체, 비밀번호, 결제 스크린샷의 전체 주문 번호는 첨부하지 마세요. 주문을 설명해야 할 때는 주문 시각과 금액만 알려 주면 됩니다.

환불과 이후 절차

본 서비스는 60일 무조건 환불을 제공합니다. 첫 결제 후 60일 이내에 신청할 수 있으며, 문의에 주문 정보를 적으면 됩니다. 문의를 접수한 뒤에는 현재 상태를 그대로 고정하고 설정을 더 바꾸지 않는 편이 좋습니다. 상담원이 같은 환경에서 재현할 수 있기 때문입니다. 문제가 결국 로컬 네트워크로 밝혀지더라도, 문의에 남긴 기록은 같은 상황을 겪는 다음 사용자에게 도움이 됩니다.