AI 도구접속 완전 가이드

대부분의 웹사이트는 판정이 아주 느슨합니다. 연결이 되고 내용이 돌아오면 통과입니다. AI 서비스는 다릅니다. 가입, 로그인, 대화 요청 하나하나마다 판단을 하고, 그 근거도 하나가 아닙니다. 이 층을 정리해 두면 이후에 나타나는 “회선만 바꾸면 된다”는 현상이 모두 설명됩니다.

출구 IP의 소속 지역과 유형

AI 서비스는 요청을 받으면 가장 먼저 그 요청이 어느 IP에서 나왔는지 봅니다. 소속 지역, 통신사 또는 데이터센터, 그리고 그 IP가 데이터센터 주소인지 가정용 주소인지까지 확인합니다. 데이터센터 IP 자체가 문제는 아닙니다. 정상적인 기업 출구도 대부분 데이터센터 IP입니다. 문제는 그 IP가 최근에 얼마나 집중적으로 쓰였는지, 비정상적인 호출 기록이 있는지입니다. 같은 IP 대역에서 짧은 시간에 대량 가입이나 고빈도 요청이 발생하면 대역 전체의 신뢰도가 떨어집니다. 페이지는 열리는데 로그인 API가 막히고 인증이 반복해서 요구되는 증상이 여기서 나옵니다.

“첫 화면이 열린다”와 “정상적으로 쓸 수 있다”는 전혀 다른 이야기입니다. 첫 화면은 대부분 정적 리소스라 판정이 가장 느슨하고, 실제 위험 판정은 로그인 API와 대화 API에서 일어납니다. 첫 화면이 열리는지로 회선의 좋고 나쁨을 판단하는 것은 사실상 아무것도 판단하지 않는 것과 같습니다.

지역 판정은 IP만 보지 않습니다

IP 외에도 서비스는 브라우저 시간대, 인터페이스 언어, 계정의 가입 지역과 과거 로그인 지역을 함께 참고합니다. IP는 미국인데 시스템 시간대는 한국 표준시, 브라우저 언어는 한국어라면 이 신호들이 겹치면서 현재 환경이 계정의 평소 환경과 다르다고 판단할 가능성이 높아집니다. 곧바로 제한이 걸리지는 않더라도 추가 인증이 뜰 확률은 확실히 올라갑니다. 시간대와 언어를 출구 지역에 맞추는 것이 비용이 가장 적게 드는 대응입니다.

장기 연결과 스트리밍 출력이 회선에 요구하는 것

대화형 도구의 응답은 스트리밍으로 옵니다. 한 번의 답변 동안 클라이언트와 서버 사이의 연결이 끊기지 않고 유지되어야 하고, 내용이 조금씩 밀려옵니다. 이 과정은 길게는 수십 초까지 이어집니다. 이 연결이 가장 두려워하는 것은 높은 지연이 아니라 흔들림과 패킷 손실입니다. 지연이 안정적이지만 절대값이 조금 높은 회선은 쾌적하게 쓸 수 있고, 지연은 낮지만 간간이 패킷을 흘리는 회선은 답변이 중간에 멈추는 형태로 나타납니다.

그래서 회선이 적합한지는 세 가지 사용 방식으로 나눠서 봐야 합니다. 웹 대화형은 안정성과 출구 품질, 업로드·다운로드는 대역폭, API 호출은 지연과 출구 고정성을 봅니다. 하나의 기준으로 세 가지를 모두 재면 어느 한쪽은 늘 답답합니다.

일반 프록시가 어느 단계에서 무너지기 쉬운가

• 출구 순환: 연결할 때마다 출구 IP가 바뀌어 로그인 위치가 지도 위에서 계속 튀고, 계정 환경이 끊임없이 달라집니다.
• 장기 연결 회수: 경로 상의 중간 장비가 유휴 연결에 타임아웃을 걸어 두어 대화가 끝나기 전에 연결이 먼저 끊깁니다.
• UDP 지원 불완전: 일부 도구는 기본적으로 UDP 기반 HTTP/3를 쓰는데, 회선이 이를 지원하지 않으면 페이지가 계속 로딩만 돕니다.
• DNS가 로컬에서 해석됨: 도메인이 가깝지만 연결되지 않는 주소로 해석되어 연결 자체가 성립하지 않습니다.

가입과 로그인은 위험 판정이 가장 집중되는 두 순간입니다. 이 두 단계를 무사히 넘기면 일상 사용의 마찰이 훨씬 줄어듭니다. 반대로 여기서 막히면 이후에 회선을 아무리 바꿔도 답답합니다. 이 단계를 따로 떼어 설명하는 이유는, 회선과의 관계가 대부분 생각하는 것보다 훨씬 직접적이기 때문입니다.

가입 전에 출구를 먼저 고정하세요

가입하기 전에 회선 하나를 정해 계속 쓰는 것을 권합니다. 가입하면서 지역을 이리저리 바꾸지 마세요. 가입 시점의 출구 IP는 계정의 첫 환경 지문이 되고, 이후 로그인마다 이와 비교됩니다. 첫 로그인부터 대륙을 넘나들면 검증이 걸리기 가장 쉬운 행동 중 하나입니다.

본 서비스의 가입에는 사용자 이름과 비밀번호만 필요하며 이메일 주소는 필요하지 않습니다. 입력 자체는 금방 끝나고, 실제로 신경 써야 할 것은 가입할 때의 네트워크 환경과 이후 며칠간의 안정성입니다.

시간대와 언어를 일치시키기

특정 지역의 회선을 쓸 때는 시스템 시간대를 그 지역의 표준 시간대로 맞추고 브라우저 언어도 함께 맞추면 검증이 뜰 확률이 낮아집니다. 반드시 해야 하는 작업은 아니지만, 해 두면 “로그인할 때마다 인증을 요구받는” 상황이 크게 줄어듭니다. 반대로 IP는 도쿄, 시간대는 한국 표준시, 언어는 한국어라면 세 신호가 서로 어긋나 판정 시스템이 한 번 더 확인하려 듭니다.

로그인 실패는 세 가지 경우를 나눠서 봐야 합니다

“로그인이 안 된다”에는 적어도 세 가지 상황이 있고, 대응 방식도 완전히 다릅니다.

• 페이지 자체가 열리지 않음: 네트워크 계층 문제입니다. 다른 회선으로, 또는 다른 회선 유형으로 바꿔 보세요(직결은 중계로, 중계는 전용선으로).
• 페이지는 열리는데 로그인을 누르면 오류가 나거나 인증을 반복 요구: 위험 판정 계층 문제입니다. 보통 이 출구의 평판이 떨어진 경우이니, 출구가 더 깨끗한 회선으로 바꾸고 로그아웃한 뒤 다시 로그인하세요.
• 로그인은 되지만 몇 분 뒤 끊김: 세션 계층 문제입니다. 회선이 자주 흔들리는지 확인하고, 브라우저에 종료 시 데이터 삭제 같은 설정이 켜져 있지 않은지도 확인하세요.

한 계정은 되도록 한두 개 지역으로 좁히기

같은 계정이 오늘은 일본, 내일은 독일에서 로그인하면 위험 판정 입장에서는 “여러 사람이 함께 쓰는 계정”과 구분하기 어렵습니다. 일상 사용에서는 한두 개 지역으로 고정하는 것을 권합니다. 정말 지역을 바꿔야 할 때는 세션 도중에 바꾸지 말고, 먼저 로그아웃한 뒤 회선을 바꾸고 다시 로그인하세요.

본 서비스는 기기 수 제한이 없어 5개 기기를 동시에 연결할 수 있습니다. 여러 기기를 함께 쓸 때는 기기마다 다른 국가에 붙이는 것보다 모든 기기를 같은 지역 회선에 태우는 편이 안전합니다. 전자는 같은 계정이 몇 분 안에 여러 로그인 위치로 나타나게 만듭니다.

여러 계정은 서로 분리하기

여러 계정을 동시에 써야 한다면 같은 출구를 공유하게 두지 마세요. 같은 IP에서 로그인한 계정은 서로 연관되기 쉬워, 하나가 제한에 걸리면 나머지도 함께 처리될 수 있습니다. 계정마다 비교적 고정된 출구를 배정하는 것은 비용이 거의 들지 않는 격리 조치입니다.

웹은 대부분의 사람이 가장 많이 쓰는 형태이면서, 문제 양상이 가장 “알 수 없는” 곳이기도 합니다. 페이지는 열리고 입력창에 글자도 써지는데 답변이 중간에 멈춥니다. 한 번의 대화를 뜯어 보면 문제는 훨씬 구체적입니다.

한 번의 대화는 어떤 단계를 거치는가

질문을 입력하면 브라우저가 세션 자격 증명을 붙여 대화 API를 호출합니다. 서버가 인증을 통과시키면 스트리밍으로 내용을 돌려보내기 시작하고, 프런트엔드는 받는 대로 그립니다. 어느 한 단계에서 문제가 생겨도 사용자 눈에는 “멈췄다”로 보이지만 원인은 전혀 다릅니다. 인증 실패는 즉시 오류가 나고, 연결이 안 되면 계속 돌아가고, 전송 중 끊기면 내용이 문장 중간에서 멈춥니다.

세 가지 중단 양상과 그 원인

• 계속 돌기만 하고 첫 글자가 안 나옴: 연결이 성립하지 않은 경우입니다. 회선이 막혔거나 DNS 해석이 어긋났거나, 이 출구가 대상 서비스에서 거부된 것이 흔한 원인입니다.
• 출력이 중간에 멈춤: 전송 도중 연결이 끊긴 경우입니다. 회선 흔들림이나 경로 상의 중간 장비가 유휴 연결을 회수했을 때 자주 나타납니다.
• 답변은 완결됐는데 다음 메시지 전송이 실패: 세션 자격 증명이 만료되거나 지워진 경우입니다. 페이지를 새로 고쳐 세션을 다시 만들면 되고, 회선을 바꿀 필요는 없습니다.

오래 방치한 뒤에는 새로 고침

대화 페이지를 십여 분 동안 그대로 두면 서버가 연결을 회수합니다. 정상 동작이며 회선 고장이 아닙니다. 돌아와서 이어 쓰기 전에 페이지를 한 번 새로 고쳐 세션을 다시 만드는 편이, 예전 페이지에서 그대로 메시지를 보내는 것보다 간편합니다. 후자는 “메시지는 보냈는데 응답이 계속 없다”로 나타나기 일쑤입니다.

브라우저 쪽 몇 가지 스위치

• 탭 절전과 휴면: 백그라운드 탭이 동결되면 스트리밍 연결이 보류되어, 돌아왔을 때 내용이 불완전할 수 있습니다.
• 데이터 절약·압축 프록시: 중간 계층이 하나 더 생겨 장기 연결이 끊기기 쉬우니, 점검할 때는 먼저 끄세요.
• HTTP/3와 회선 호환성: 일부 도구는 기본적으로 UDP 기반 HTTP/3를 씁니다. 회선의 UDP 지원이 불완전하면 로딩이 느리거나 계속 도는 형태로 나타나니, 클라이언트에서 HTTP/3를 끄고 TCP로 바꿔 다시 시도해 보세요.
• 광고 차단 확장 프로그램: 일부 규칙이 대화 API의 스트리밍 요청을 잘못 막을 수 있으니, 점검할 때 한 번 꺼 두세요.

여러 탭과 동시 실행

대화 페이지를 여러 개 동시에 열어 두는 것은 장기 연결을 여러 개 유지하는 것과 같습니다. 트래픽이 적은 등급에서는 이 연결들이 대역폭을 서로 잡아먹어 모든 페이지가 느려집니다. 병렬 작업이 필요하면 시간을 엇갈리게 쓰거나, 트래픽이 더 넉넉한 등급으로 옮기세요. 월 구독 3종은 각각 ¥9.9/월 60GB, ¥18/월 250GB, ¥28/월 500GB이며, 트래픽은 개통일 기준으로 매월 초기화됩니다. 평소 동시 사용 습관에 맞춰 미리 가늠해 보세요.

같은 계정인데 웹은 멀쩡하고 API는 오류를 내는 조합은 아주 흔합니다. 서버 입장에서 이 두 가지는 거의 다른 클라이언트이기 때문입니다. 인증 방식도, 요청 특성도, 속도 제한 기준도 다릅니다.

인증 방식이 다릅니다

웹은 로그인 후 받은 세션 자격 증명을 브라우저 쿠키에 담아 두고 사용자는 의식할 필요가 없습니다. API는 키를 요청 헤더에 넣으며 호출하는 쪽이 직접 관리합니다. 키가 유출되면 다른 사람이 그것으로 계정 한도를 소진할 수 있고, 위험 판정 기록은 계정에 남습니다. 그래서 키는 서버의 환경 변수나 키 관리 시스템에만 두고, 프런트엔드 코드에 쓰거나 코드 저장소에 커밋하지 마세요.

본 서비스의 가입과 사용에는 이메일 주소가 필요하지 않지만, API 키의 보관 책임은 사용하는 쪽에 있습니다. 이 항목은 회선과 무관하지만 회선보다 사고가 나기 쉽습니다.

요청 특성이 다릅니다

웹은 적은 수의 장기 연결을 오래 유지하고, API는 많은 단기 연결을 높은 빈도로, 매번 적은 데이터로 보냅니다. 즉 두 사용 방식이 회선에 요구하는 것이 거의 반대입니다. 웹은 흔들림을 싫어하고, API는 지연과 출구 변화를 싫어합니다. 영상 시청에 맞는 회선으로 API를 돌린다고 해서 더 좋은 결과가 나오지는 않습니다.

동시 실행과 속도 제한

AI 서비스는 보통 API에 속도 제한을 두고, 분당 요청 수나 분당 처리 텍스트량으로 계산합니다. 초과하면 429(요청 과다)를 돌려줍니다. 여러 기기와 여러 프로세스가 같은 출구를 공유하면 제한은 합산됩니다. 각 호출자가 자기 몫은 적다고 생각해도 합치면 넘습니다. 동시 실행 수를 줄이고 배치 작업의 시간을 엇갈리게 하는 편이 보통 회선을 바꾸는 것보다 효과적입니다.

API에는 출구 안정성이 더 중요합니다

많은 서비스가 API 호출의 출발 IP를 계정의 평소 로그인 지역과 비교합니다. 웹은 가끔 지역이 바뀌어도 영향이 제한적이지만, API가 매일 다른 IP 대역에서 요청을 보내면 이상 징후로 판정되기 쉬워 간헐적인 403이나 재인증 요구로 나타납니다. API 호출용 출구 회선을 하나 고정하는 것이 이런 문제의 표준 해법입니다.

최소한으로 동작하는 호출 예시

아래는 본 서비스를 통해 요청을 보내는 최소 예시입니다. 주소, 키, 포트는 모두 자리 표시자이니 자신의 값으로 바꾸면 됩니다. 예시에는 실제 구독 주소나 키가 전혀 들어 있지 않습니다.

# 현재 터미널의 모든 요청을 클라이언트가 제공하는 로컬 프록시 포트로 보냅니다
export HTTPS_PROXY="http://127.0.0.1:7890"
export HTTP_PROXY="http://127.0.0.1:7890"

# 로컬 및 내부망 주소는 직접 연결하고 프록시를 거치지 않습니다
export NO_PROXY="localhost,127.0.0.1,.internal"

curl -sS "https://example.com/v1/chat/completions" \
  -H "Authorization: Bearer sk-xxxx" \
  -H "Content-Type: application/json" \
  -d '{"model":"your-model","messages":[{"role":"user","content":"ping"}]}'

포트는 클라이언트 화면에 표시되는 실제 값을 기준으로 하세요. 클라이언트마다 기본 포트가 다릅니다. 예시의 도메인과 키는 모두 자리 표시자이므로 그대로 쓸 수 없습니다.

개발 환경의 번거로움은 이렇습니다. 같은 도구가 브라우저에서는 되는데 터미널에서는 안 될 수 있고, 터미널에서 설정을 마쳐도 에디터 플러그인은 여전히 직접 연결로 나갈 수 있습니다. 각자 독립적인 네트워크 스택과 프록시 설정을 가지고 있고, 서로 자동으로 물려받지 않기 때문입니다.

터미널: 프로그램이 어떤 프록시를 인식하는지 먼저 구분

터미널 프로그램의 프록시 지원은 대략 세 단계로 나뉩니다. 환경 변수(HTTP_PROXY, HTTPS_PROXY, NO_PROXY)를 인식하는 부류, 자기 설정 파일만 보는 부류(예: git의 http.proxy), 그리고 프록시를 전혀 인식하지 않는 부류입니다. “환경 변수를 분명히 설정했는데 안 먹는다”면 이 프로그램이 어느 부류인지 먼저 확인하고, 환경 변수를 고칠지 설정 파일을 고칠지 정하세요. 환경 변수의 대소문자도 주의하세요. 대문자만 인식하는 프로그램도 있고 둘 다 인식하는 프로그램도 있습니다.

프록시가 필요한 트래픽만 프록시로

내부망 주소, 로컬 주소, 사설 저장소 도메인을 NO_PROXY 허용 목록에 넣으면 정체불명의 타임아웃을 크게 줄일 수 있습니다. 흔히 넣는 값은 localhost, 127.0.0.1, 그리고 내부망 도메인 접미사입니다. 반대로 어떤 도메인이 로컬 DNS로 해석되지만 접속할 때는 프록시를 거쳐야 한다면, 전역 모드가 알아서 해 주기를 기대하지 말고 그 도메인을 프록시 규칙에 명시적으로 추가하세요.

IDE 플러그인과 에디터

코드 자동 완성 플러그인이나 에디터 내장 AI 어시스턴트는 보통 별도 프로세스에서 요청을 보내며 시스템 프록시 설정을 따르지 않습니다. 에디터 자체 설정에서 프록시 주소를 따로 입력하거나, 클라이언트를 전역 모드로 두어 모든 트래픽을 넘겨받게 해야 합니다. 판별법은 간단합니다. 브라우저에서는 되는데 에디터에서만 계속 돈다면 플러그인이 프록시를 타지 않는 것입니다.

에디터에서 터미널 패널을 함께 열어 두었다면, 그 터미널은 에디터의 환경 변수를 물려받으므로 시스템 터미널과 다를 수 있습니다. 시스템 터미널에서 통과한 프록시 설정이 에디터 터미널에서는 적용되지 않을 수 있습니다.

CI와 컨테이너

• 클라우드 CI: 서비스 제공자의 자체 네트워크에서 돌기 때문에 보통 별도 프록시가 필요하지 않습니다. 특정 리소스에 접근해야 한다면 플랫폼 문서에 따라 출구를 설정하세요.
• 자체 runner: 프록시를 명시적으로 설정해야 하고, 프록시 주소를 자격 증명으로 관리하세요. 파이프라인 파일에 그대로 적지 마세요.
• 컨테이너: Docker 컨테이너는 기본적으로 호스트의 프록시 환경 변수를 물려받지 않으므로, 빌드나 실행 시점에 명시적으로 넘겨야 합니다.
• 로그: 파이프라인이 전체 요청 헤더를 출력하지 않게 하여 키가 빌드 로그에 기록되는 것을 막으세요.

컨테이너 안에서 쓰는 설정 조각

# 실행 시 호스트 프록시를 컨테이너에 전달합니다(주소는 이 PC에서 실제로 수신 중인 값 기준)
docker run --rm \
  -e HTTPS_PROXY="http://host.docker.internal:7890" \
  -e NO_PROXY="localhost,127.0.0.1" \
  your-image

Linux에서는 host.docker.internal을 쓰려면 추가 매핑이 필요하거나, Docker 브리지에서의 호스트 주소로 바꿔야 합니다. 예시의 포트는 자리 표시자이니 클라이언트가 실제로 수신하는 값으로 맞추세요.

설정을 한곳으로 모으기

터미널, 에디터, 컨테이너 세 곳에 프록시를 따로 설정하면 “한 곳만 고치고 나머지 두 곳은 예전 값 그대로”인 상황이 가장 흔합니다. 프록시 주소를 세 곳 모두 읽을 수 있는 한 곳에 적어 두는 것을 권합니다. 예를 들어 셸 시작 스크립트에서 변수를 정의하고 에디터와 컨테이너가 같은 값을 참조하게 하면, 회선을 바꿀 때 한 곳만 고치면 되므로 “어느 계층에 아직 예전 설정이 남아 있는지” 찾는 비용이 줄어듭니다.

“계정 정지”와 “속도 제한”은 자주 뒤섞여 불리지만 원인이 다릅니다. 속도 제한은 빈도 문제이고 보통 자동으로 풀립니다. 계정 정지나 임시 제한은 판정 문제이므로 이의 제기를 하거나 기다려야 합니다. 어느 쪽인지 먼저 구분하고 행동을 정하면 헛된 회선 교체 시도를 크게 줄일 수 있습니다.

속도 제한은 세 곳에서 올 수 있습니다

속도 제한은 세 곳에서 발생할 수 있습니다. AI 서비스 자체의 계정 단위 제한, 출구 IP의 공유 제한, 그리고 본 서비스 요금제의 트래픽 한도입니다. 앞의 둘은 “요청이 거부됨”으로, 세 번째는 “트래픽 소진”으로 나타납니다. 판별법은 이렇습니다. 같은 출구에서 다른 도구를 써 봤을 때 똑같이 오류가 나면 문제는 출구 쪽일 가능성이 큽니다. 다른 출구에서 같은 계정으로 써 봤을 때 정상으로 돌아오면 문제는 출구 IP의 평판입니다.

출구 평판은 쌓을 수 있습니다

같은 출구를 오래 쓸수록, 행동이 안정적일수록 위험 판정 기록은 일반 사용자에 가까워집니다. 반대로 회선을 자주 바꾸면 계정 환경이 계속 변하는 상태에 놓입니다. 한두 개 회선을 골라 오래 쓰는 편이 “빠른 것 아무거나” 쓰는 것보다 대개 안정적인 이유가 여기 있습니다. 후자는 매번 위험 판정에 새로운 비교 표본을 제공하는 셈입니다.

문제가 생긴 뒤의 처리 순서

1. 먼저 층을 나누기

   네트워크 계층(연결 불가), 위험 판정 계층(연결은 되지만 거부), 세션 계층(연결됐지만 끊김) 중 어디인지 확인합니다.

2. 네트워크 계층에서 할 일

   회선 유형을 바꿉니다. 직결은 중계로, 중계는 전용선으로. 또는 HTTP/3를 끄고 TCP로 한 번 더 시도합니다.

3. 위험 판정 계층에서 할 일

   출구가 더 깨끗한 회선으로 바꾸고 로그아웃한 뒤 다시 로그인합니다. 짧은 시간에 빠르게 반복 재시도하지 마세요. 집중적인 시도 자체가 이상 행위로 기록됩니다.

4. 세션 계층에서 할 일

   페이지를 새로 고쳐 세션을 다시 만들고, 브라우저가 종료 시 데이터를 지우도록 설정돼 있는지 확인하고, 회선이 자주 흔들리지 않는지 점검합니다.

5. 계정 계층에서 할 일

   계정 자체가 제한된 것이 확인되면 서비스 제공자의 이의 제기 채널을 이용하는 수밖에 없습니다. 이때는 회선을 바꿔도 해결되지 않지만, 출구를 고정해 두면 이의 제기 기간에 환경이 계속 변하는 것을 막을 수 있습니다.

IP 교체를 만능 해법으로 여기지 마세요

흔히 “IP가 차단됐다”고 말하는 상황은 실제로는 그 출구의 평판이 떨어진 것이고, 깨끗한 회선으로 바꾸면 회복됩니다. 하지만 계정 자체가 이미 제한 상태에 들어갔다면 출구를 바꾸는 것은 똑같이 거부당하는 위치를 바꾸는 것에 불과합니다. 판단 순서는 언제나 먼저 층을 나누고 그다음에 손을 대는 것이지, 회선부터 바꾸고 결과를 보는 것이 아닙니다.

AI 도구마다 네트워크에 요구하는 것이 다릅니다. 같은 기준으로 고르면 어느 한 종류는 늘 불편합니다. 아래에서 사용 형태별로 나눠 주의점과 맞는 회선 유형을 정리했습니다. 회선 전체 목록은 회선 목록 페이지에서 하나씩 확인할 수 있습니다.

세 가지 회선 유형의 차이

본 서비스의 회선은 접속 방식에 따라 세 종류로 나뉘며, 어울리는 상황이 각각 다릅니다.

회선 선택 순서: 형태 → 지역 → 등급

권장 순서는 이렇습니다. 먼저 사용 형태로 회선 유형을 정하고, 다음으로 도구가 지원하는 지역으로 출구 위치를 정하고, 마지막으로 월 사용량으로 요금제 등급을 정합니다. 지역 단계는 감으로 고르지 마세요. 같은 도구라도 지역에 따라 사용 가능 상태가 다를 수 있으니, 도구가 어떤 지역을 지원하는지 먼저 확인하고 본 서비스의 회선 목록에서 해당 출구를 고르세요.

등급 단계는 사용량을 봅니다. 월 구독 3종은 ¥9.9/월 60GB, ¥18/월 250GB, ¥28/월 500GB이고, 트래픽은 개통일 기준 매월 초기화되며, 중간에 업그레이드하면 차액이 남은 일수로 환산됩니다. 사용량이 특정 몇 달에 몰리고 평소에는 적다면 트래픽 팩이 더 맞습니다. ¥158/300GB, ¥358/1000GB, ¥658/3000GB이며, 다 쓰면 끝이고 만료되지 않습니다. 두 방식 모두 Alipay, WeChat, USDT 결제를 지원하고 14일 무조건 환불이 적용됩니다.

커버리지는 현재 120+ 국가 / 190+ 회선이며, 기기 수 제한 없이 5개 기기를 동시에 연결할 수 있습니다. 기기가 많고 동시 사용이 많을 때 병목이 되기 쉬운 것은 회선 자체보다 트래픽 한도입니다.

이 장은 찾아보기용입니다. 가장 가까운 증상을 찾아 순서대로 진행하고, 각 단계마다 멈춰서 한 번 시험해 보세요. 설정 다섯 개를 한꺼번에 바꾸지 마세요. 그러면 회복되더라도 어느 단계가 효과를 냈는지 알 수 없습니다.

증상: 도구 첫 화면이 열리지 않음

1. 클라이언트가 연결돼 있는지, 그리고 현재 회선의 지역이 대상 도구가 지원하는 지역과 일치하는지 확인합니다.
2. 같은 지역의 다른 회선으로 바꿔 봅니다(전용선을 중계로, 또는 그 반대로). 단일 회선 문제인지 가려내기 위해서입니다.
3. HTTP/3 또는 QUIC를 끄고 TCP로 강제해 다시 시도합니다.
4. 시스템 DNS가 로컬 네트워크에 넘어가 있지 않은지 확인하고, 필요하면 수동 지정 DNS로 바꿉니다.
5. 평범한 웹페이지 하나로 회선 자체가 인터넷에 되는지 확인해 “회선 불통”과 “대상 도구 불통”을 분리합니다.

증상: 페이지는 열리는데 로그인이 거부되거나 인증이 반복됨

1. 현재 로그인을 끝내고, 출구가 더 깨끗한 회선으로 바꾼 뒤 다시 로그인합니다.
2. 시스템 시간대와 브라우저 언어를 출구 지역에 맞춥니다.
3. 짧은 시간에 빠르게 반복 재시도하지 마세요. 집중적인 시도는 이상 행위로 기록됩니다.
4. 같은 출구에서 다른 도구도 이상하면 회선을 바꾸는 쪽을 우선하고, 이 도구만 이상하면 문제는 계정 쪽일 가능성이 큽니다.

증상: 답변 출력이 중간에 멈춤

1. 페이지를 새로 고쳐 세션을 다시 만들고 한 번 더 보내 봅니다. 간헐적인지 확인합니다.
2. 반복해서 나타나면 전용선 계열 회선으로 바꿉니다.
3. 브라우저 절전과 탭 휴면을 끄고, 광고 차단 확장 프로그램을 잠시 비활성화합니다.
4. 대화 페이지를 여러 개 켜 두었는지, 대용량 다운로드를 함께 돌리는지 확인하고 시간을 엇갈리게 합니다.

증상: 속도가 들쭉날쭉함

1. 같은 지역의 다른 회선과 비교해 회선 문제인지 대상 서비스의 혼잡 시간대인지 판단합니다.
2. 로컬 네트워크의 혼잡 시간대를 피하세요. 같은 네트워크의 다른 기기가 다운로드 중이면 체감 품질이 확 떨어집니다.
3. 대륙 간 회선은 저녁 시간대의 변동이 아시아 내 회선보다 큰 편이니, 중요한 작업은 안정적인 시간대에 배치하세요.

증상: 특정 도구만 안 됨

1. 그 도구가 지원하는 다른 지역 회선으로 바꿉니다.
2. 그 도구가 독자적인 네트워크 스택을 쓰는지(에디터 플러그인, 터미널 도구) 확인하고, 그렇다면 따로 프록시를 설정합니다.
3. 회선을 바꿔도 여전히 안 되는데 웹은 정상이라면, 회선을 계속 바꾸기보다 도구 자체나 계정 쪽을 먼저 의심하세요.

증상: 여러 기기를 함께 쓰면 불안정

1. 요금제 트래픽 등급이 동시 사용량을 감당하는지 확인합니다. 트래픽은 개통일 기준 매월 초기화되며, 사용량은 사용자 패널의 계정 개요에서 볼 수 있습니다.
2. 모든 기기를 같은 지역 회선에 태워 계정 환경의 변화를 줄입니다.
3. 대용량 작업(다운로드, 소재 업로드)과 장기 연결 작업(대화)의 시간대를 엇갈리게 합니다.

아래는 이 페이지에서 가장 많이 나온 질문들입니다. 여기서 다루지 않은 상황이라면 도움말 센터에서 분류별로 찾아보거나, 사용자 패널에서 티켓을 제출하세요.

다음으로 볼 만한 것

이 페이지는 각 단계를 깊이 설명하는 역할이고, 절차를 처음부터 따라가게 하는 역할은 아닙니다. 아직 클라이언트를 설치하지 않았거나 구독을 가져오지 않았다면 먼저 사용 가이드의 기본 흐름을 보세요. 구체적인 지역과 회선을 확인하려면 회선 목록, 가격과 환불 조건을 확인하려면 요금제 페이지로 가면 됩니다.