연결 오류 점검 매뉴얼

01 · 원인 파악

먼저 문제가 어느 계층에서 생겼는지 판단

연결 실패는 원인이 하나인 경우가 드뭅니다. 문제가 생길 수 있는 지점을 세 계층으로 나누면 점검이 훨씬 빨라집니다. 첫째는 기기 자체로, 클라이언트 설정, 시스템 시간, 방화벽, 절전 정책이 해당합니다. 둘째는 로컬 네트워크 구간으로, 가정용 회선, 회사 네트워크, 공용 Wi-Fi가 프로토콜과 포트를 제한하는 경우입니다. 셋째가 회선과 계정으로, 회선 혼잡, 구독 만료, 트래픽 소진입니다. 세 계층은 대응 방식이 완전히 다르므로, 먼저 계층을 특정한 뒤 해결책을 이야기해야 합니다.

순서가 노력보다 중요합니다. 연결이 안 된다고 클라이언트를 곧바로 재설치하는 분이 많은데, 그러면 화면에 뜬 가장 중요한 안내 문구를 그대로 잃어버립니다. 재설치는 설정 파일이 실제로 손상된 경우에만 유효하고, 그 밖의 상황에서는 점검 시간을 0으로 되돌릴 뿐입니다.

한 가지 더 짚을 점이 있습니다. 세 계층은 서로 영향을 줍니다. 기기 성능이 부족하면 회선이 '느린' 것처럼 보이고, 로컬 DNS 설정이 잘못되면 '접속 불가'와 '연결은 되지만 페이지가 안 열림'이 동시에 나타납니다. 그래서 각 장 마지막에는 '어떤 경우에 상위 계층으로 돌아가야 하는지'를 적어 두었습니다. 한 장에서 끝까지 매달릴 필요는 없습니다.

30초면 되는 세 가지 확인

도구 없이 세 가지만 해보면 범위가 절반 이상 줄어듭니다.

1. 클라이언트를 끄고 일반 웹페이지를 열어 봅니다. 열리지 않으면 로컬 네트워크 자체가 끊긴 것이니, 클라이언트에서 원인을 찾지 말고 네트워크부터 해결합니다.
2. 기기와 네트워크는 그대로 두고 다른 회선으로 다시 연결합니다. 연결되면 특정 회선의 문제이므로 노드 회선에서 같은 지역의 다른 유형 회선을 골라 보세요.
3. 다른 기기로 시도하거나, 같은 기기를 다른 네트워크에 연결합니다. 기기를 바꿔 연결되면 원래 기기의 로컬 설정 문제이고, 네트워크를 바꿔 연결되면 원래 네트워크의 송출 정책 문제입니다.

증상을 기록하고, 재설치부터 서두르지 않기

문의를 접수할 때 가장 값진 정보는 '연결이 안 됩니다'라는 한마디가 아니라 아래 항목들입니다. 미리 적어 두면 결국 누군가의 도움을 받아야 할 때도 한 번의 주고받기를 아낄 수 있습니다.

• 문제가 발생한 시각과 시간대, 특정 시간대에 집중되는지
• 플랫폼과 OS 버전(Windows / macOS / iOS / Android / Linux)
• 클라이언트 화면에 표시된 안내 문구 원문, 스크린샷 또는 그대로 옮겨 적기
• 당시 선택한 회선 이름과 회선 유형
• 공유기에서 사용 중인지, 공유기 아래에 기기가 몇 대 연결돼 있는지
• 문제 발생 전에 바꾼 것: DNS 변경, 보안 프로그램 설치, 분할 라우팅 모드 전환

마지막 장으로 바로 넘어가도 되는 경우

두 가지 경우는 장을 하나씩 짚을 필요가 없습니다. 하나는 패널에서 구독이 만료됐거나 트래픽이 소진된 경우로, 계정 문제이므로 '계정과 문의'를 바로 보면 됩니다. 다른 하나는 같은 계정으로 여러 기기에서 동시에 완전히 같은 증상이 나타나고 네트워크와 회선을 바꿔도 효과가 없는 경우로, 보통 계정 측 세션 상태 문제이므로 계속 시도하기보다 문의를 접수하는 편이 빠릅니다. 그 밖의 증상은 장 순서대로 한 번씩 짚어 보기를 권합니다. 많은 증상이 같은 원인의 다른 표현이기 때문입니다.

02 · 연결 수립

완전히 접속 불가

클라이언트에서 연결을 눌렀는데 계속 로딩만 돌거나, 오류가 뜨거나, 연결 직후 끊어지는 경우를 모두 여기에 해당합니다. 먼저 클라이언트가 보여 주는 안내가 어느 유형인지 확인하세요. 네 가지 유형은 대응 경로가 완전히 다릅니다.

먼저 네 가지 '접속 불가'를 구분합니다

계정과 트래픽

사용자 패널에 로그인해 두 가지를 확인하세요. 구독이 유효 기간 내에 있는지, 트래픽이 남아 있는지입니다. 월 구독 트래픽은 달력 기준이 아니라 개통일을 기준으로 매월 초기화됩니다. 트래픽 패키지는 다 쓸 때까지 유효하며 영구적으로 만료되지 않으므로, 패키지에 남은 용량이 월이 바뀐다고 사라지지 않습니다. 패널에는 두 종류의 잔여량이 각각 표시되며, 패널 표시가 기준입니다.

패널에는 구독이 유효하고 트래픽도 충분한데 클라이언트가 인증 실패를 표시한다면, 먼저 로그아웃 후 다시 로그인해 클라이언트가 계정 정보를 새로 받아 오게 하세요. 그래도 실패하면 문의를 접수하세요. 트래픽 패키지와 월 구독을 어떻게 조합하는 게 유리한지는 트래픽 패키지와 월 구독 선택에 사용량 기준 계산 방식이 정리돼 있습니다.

시스템 시간

암호화 연결은 인증서 검증에 의존하고, 인증서 검증의 첫 관문은 시간입니다. 시스템 시간이 실제 시간과 몇 분 이상 어긋나면 핸드셰이크가 실패하는데, 안내 문구가 '네트워크 불통'과 비슷해 오판하기 쉽습니다. Windows, macOS, iOS, Android 모두 자동 시간 설정 스위치가 있으니 켜 두고, 한 번 수동으로 동기화하세요.

# Linux: 시간, 시간대, 동기화 상태 확인
timedatectl status

# 자동 시간 설정을 켜고 즉시 한 번 동기화
sudo timedatectl set-ntp true

로컬 네트워크 구간

회사 네트워크, 학교 네트워크, 일부 호텔과 공용 Wi-Fi는 UDP와 비표준 포트를 제한합니다. 판단 방법은 간단합니다. 같은 기기를 다른 네트워크에 연결해 다시 시도해 보세요. 원래 네트워크에서는 안 되고 다른 네트워크에서는 된다면 원래 네트워크의 송출 정책 문제입니다. 이 경우 클라이언트에서 전송 프로토콜을 UDP 계열에서 TCP 계열로 바꾸거나, 더 흔히 쓰이는 포트로 바꿔 볼 수 있습니다.

방화벽과 보안 프로그램

데스크톱 보안 프로그램, 운영체제 기본 방화벽, 일부 '네트워크 최적화' 도구는 가상 네트워크 어댑터를 가로챕니다. 증상은 클라이언트는 연결됨으로 표시되는데 시스템에 가상 어댑터가 새로 생기지 않거나, 연결이 순간적으로 끊기는 것입니다. 대응 방법은 클라이언트를 허용 목록에 추가해 가상 어댑터 생성과 DNS 설정 변경을 허용하는 것입니다. 점검 중에는 서드파티 보안 프로그램을 잠시 끄고 대조 테스트를 한 뒤 즉시 원상 복구해도 됩니다.

공유기와 다중 기기

공유기에서 설정할 때는 클라이언트가 관여하지 않으므로, 문제는 보통 공유기 펌웨어, 시간 동기화, 규칙 파일 호환성에서 나옵니다. 순서대로 확인하세요. 공유기 자체가 정상적으로 인터넷에 연결되는지, 공유기 시간이 동기화됐는지, 구독으로 규칙을 정상적으로 받아 왔는지, 규칙 형식이 펌웨어와 맞는지입니다. 네 가지를 모두 통과해도 연결되지 않는다면 공유기 모델명과 펌웨어 종류를 적어 문의에 함께 첨부하세요.

03 · 이름 해석과 분할 라우팅

연결은 되는데 페이지가 안 열림

클라이언트는 연결됨으로 표시되고 송출 지역도 바뀌었는데 브라우저가 계속 로딩만 돌거나, 일부 사이트만 열립니다. 이 유형의 공통점은 터널은 이미 수립됐고, 터널 위에서 이뤄지는 이름 해석과 분할 라우팅에서 막힌다는 것입니다.

먼저 세 가지 양상을 구분합니다

DNS 누출과 DNS 실패의 차이

DNS 누출은 조회가 터널을 통하지 않아 로컬 DNS가 노출되는 것이고, DNS 실패는 조회가 아예 결과를 반환하지 않는 것입니다. 둘 다 '페이지가 안 열림'으로 나타나지만 대응이 다릅니다. 누출은 클라이언트의 DNS 처리 설정을 바꿔야 하고, 실패는 먼저 시스템 DNS에 도달할 수 있는지 확인해야 합니다.

# Windows: DNS 설정 확인 및 캐시 비우기
ipconfig /all
ipconfig /flushdns

# macOS: DNS 캐시 비우기
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux(systemd-resolved): 상태 확인 및 캐시 비우기
resolvectl status
sudo resolvectl flush-caches

# 공통: 도메인이 어떤 주소로 해석되는지 조회
nslookup example.com

nslookup의 결과가 통신사나 공유기의 주소로 나오는데 클라이언트에서 이미 DNS를 터널로 보내도록 설정했다면, 조회가 시스템에서 우회된 것입니다. 대응 방법은 클라이언트에서 DNS를 터널이 처리하도록 설정하거나, 1.1.1.1, 8.8.8.8처럼 사용 가능한 공용 DNS를 직접 지정하는 것입니다. 변경 후에는 시스템 캐시를 한 번 비우세요.

분할 라우팅 모드와 규칙

규칙 모드에서는 클라이언트가 도메인 목록을 보고 프록시로 보낼지 직접 연결할지 결정합니다. 대상 사이트가 목록에 없거나 목록 버전이 오래됐다면 직접 연결로 처리됩니다. 판단 방법은 모드를 잠시 전체(글로벌)로 바꿔 보는 것입니다. 전체 모드에서는 열리고 규칙 모드에서는 열리지 않는다면 규칙의 문제입니다. 대응은 규칙을 갱신하거나 해당 도메인을 사용자 규칙에 추가하는 것입니다.

분할 라우팅 규칙에는 놓치기 쉬운 경계가 하나 더 있습니다. 같은 도메인이 '직접 연결 목록'과 '프록시 목록'에 동시에 걸릴 수 있고, 최종 결과는 클라이언트의 우선순위에 따릅니다. 규칙이 많다고 좋은 것이 아니며, 충돌하는 규칙은 점검을 어렵게 만듭니다. 규칙은 최대한 간결하게 유지하고, 정말 필요한 항목만 추가하세요.

MTU와 큰 패킷 손실

터널은 헤더를 한 겹 더 감싸므로 실제로 쓸 수 있는 최대 전송 단위가 물리 링크보다 작습니다. MTU를 크게 잡으면 작은 요청은 통과하고 큰 응답은 버려져, 페이지 뼈대는 나오는데 이미지와 스타일이 로드되지 않거나 로그인 같은 동작이 계속 로딩만 도는 형태로 나타납니다. MTU를 한 단계 낮춰 보는 것이 가장 비용이 적은 검증 방법입니다.

04 · 처리량

속도 저하

느림은 정량화하기 가장 어려운 유형입니다. 먼저 기준선을 세우세요. 프록시를 끈 상태의 로컬 네트워크 실제 속도가 얼마인지, 켠 뒤에 얼마나 떨어지는지입니다. 기준선이 없으면 '느리다'는 주관적 감각일 뿐이고, 회선을 열 개 바꿔도 개선되지 않을 수 있습니다.

먼저 기준선을 재고, 그다음 최적화

클라이언트를 끈 상태에서 같은 기기, 같은 위치에서 로컬 대역폭을 한 번 측정해 기록하세요. 그다음 프록시를 연결하고 같은 방식으로 다시 측정합니다. 두 결과의 차이가 바로 프록시 경로에서 생기는 손실입니다. 로컬 대역폭 자체가 매우 낮다면 회선을 바꿔도 눈에 띄는 개선은 없습니다. 병목이 회선에 있지 않기 때문입니다.

속도 측정 자체에도 요령이 있습니다. 측정 서버의 위치가 결과에 크게 영향을 줍니다. 측정 노드는 국내에 있고 프록시 송출 지점은 해외라면, 측정값은 '국내에서 국내까지'를 반영할 뿐 실제 국가 간 속도가 아닙니다. 실제 체감에 더 가까운 방법은 평소 쓰는 사이트를 열어 첫 화면 표시 시간, 이미지 로딩, 영상 재생 시작까지의 세 가지를 보는 것입니다.

단일 스레드와 다중 스레드

단일 스레드 다운로드는 연결 하나의 품질을, 다중 스레드 다운로드는 전체 대역폭을 반영합니다. 단일 스레드는 느린데 다중 스레드는 정상이라면 회선이 연결 하나에 대한 속도 제한을 강하게 걸고 있다는 뜻으로, 여러 작업을 병렬로 돌리기에는 적합하지만 대용량 파일 단일 다운로드에는 적합하지 않습니다. 다중 스레드도 느리다면 병목은 링크 전체 대역폭이나 로컬 구간에 있습니다. 판단할 때는 같은 파일, 같은 시간대에 각각 한 번씩 측정해야 비교가 됩니다.

회선 유형의 영향

직접 연결 회선은 경로가 가장 짧지만 거치는 공용 인터넷 노드가 많아 저녁 피크에 국제 구간 혼잡의 영향을 받기 쉽습니다. 중계 회선은 중간에 한 홉이 더 있지만 경로를 더 통제할 수 있습니다. IEPL 전용선은 독립 통로를 사용해 지연과 지터가 더 안정적이며 비용도 높습니다. 같은 지역에 세 유형의 회선이 동시에 있을 수 있고 속도 차이가 크므로, 하나씩 시도해 볼 가치가 있습니다. 노드 회선 페이지에 지역별로 각 회선의 유형이 정리돼 있으니 회선을 고를 때 참고하세요.

기기와 Wi-Fi

암호화와 복호화에는 CPU가 필요합니다. 오래된 기기, 저전력 모드의 노트북, 백그라운드에서 자원을 다 쓰는 프로그램은 실제 처리량을 회선 성능보다 낮춥니다. 판단 방법은 성능이 더 좋은 기기에 같은 회선을 연결해 비교하는 것입니다. Wi-Fi의 경우 2.4GHz 대역의 실제 처리량은 5GHz보다 훨씬 낮고, 벽을 하나 사이에 두면 더 빠르게 떨어집니다. 유선 연결이 가장 안정적인 대조군입니다.

특정 사이트만 느림

특정 사이트만 느리고 나머지는 정상이라면 문제는 대개 회선에 있지 않습니다. CDN은 송출 IP를 기준으로 노드를 배정하므로, 송출 지역을 멀리 고르면 배정되는 CDN 노드도 멀어집니다. 송출 지역을 대상 사이트의 서비스 권역에 더 가까운 곳으로 바꾸는 편이 회선을 바꾸는 것보다 효과적일 때가 많습니다. 100+ 국가 / 220+ 회선 규모라면 대부분의 대상 서비스에 대해 지리적으로 더 가까운 송출 지점을 찾을 수 있습니다.

05 · 시간대

저녁 피크 버벅임

문제가 특정 시간대에만 나타난다면, 즉 낮에는 정상이고 밤에만 버벅인다면 무작위 고장이 아니라 규칙적인 혼잡입니다. 국내 가정용 회선과 국제 구간은 해 질 무렵부터 밤 사이에 부하가 가장 높고, 국가 간 링크의 지연과 패킷 손실이 함께 올라갑니다. 직접 연결 계열 회선이 가장 큰 영향을 받습니다.

저녁 피크에 더 심해지는 이유

국가 간 링크는 국제 구간을 거쳐야 하고, 이 구간의 대역폭은 공유 자원입니다. 저녁 피크에는 가정용 회선의 동시 접속 사용자가 가장 많아져 구간의 대기 지연이 올라가고 패킷 손실률도 함께 상승합니다. 패킷 손실이 전송에 미치는 영향은 누적됩니다. 손실 한 번이 재전송과 혼잡 윈도 축소를 유발하므로, 실제 처리량 감소 폭은 손실률 퍼센트보다 훨씬 큽니다. 저녁 피크에 '조금 버벅이는 정도'가 체감으로는 '영상이 계속 로딩만 도는' 상황이 되는 이유입니다.

먼저 시간 규칙성 확인

며칠 연속 같은 회선, 같은 시간대에 기록해 보세요. 연결이 정상인지, 웹페이지가 몇 초 만에 열리는지, 영상이 몇 번 버퍼링하는지입니다. 사흘치 기록이면 규칙성이 보입니다. 버벅임이 시간과 무관하다면 '속도 저하' 장으로 돌아가고, 특정 회선에서만 나타난다면 회선 자체의 문제이므로 회선을 바꾸면 됩니다.

회선 유형 선택

저녁 피크의 양상은 회선 유형과 강하게 연관됩니다. 직접 연결 회선은 공용 인터넷을 지나므로 혼잡할 때 지터가 두드러집니다. 중계 회선은 중간 노드에서 트래픽을 모아 주어 안정성이 조금 낫습니다. IEPL 전용선은 독립 통로를 사용해 공용 인터넷 혼잡의 영향을 가장 적게 받습니다. 예산이 허락한다면 저녁 피크 시간대에 전용선 계열로 바꾸는 것이 가장 직접적인 개선 방법입니다.

송출 지역 선택

같은 사이트라도 송출 지역에 따라 응답 차이가 큽니다. 아시아 방향 회선은 저녁 피크의 지연이 태평양 횡단 방향보다 대체로 낮습니다. 대상 서비스가 여러 지역에 노드를 두고 있다면 지리적으로 더 가까운 송출 지점을 우선 선택하고, 특정 지역에만 노드가 있다면 그 지역 안에서 회선 유형을 고르는 수밖에 없습니다.

사용 습관 조정

• 대용량 파일 다운로드와 시스템 업데이트는 비피크 시간대로 옮기기
• 영상 화질을 자동에서 고정 단계로 바꿔 비트레이트가 반복 전환되며 버퍼링이 반복되는 것 방지
• 동시에 시청하는 기기가 많을수록 기기 한 대가 받는 대역폭은 줄어듭니다. 기기 수 무제한이 총 대역폭 무제한을 뜻하지는 않습니다
• 게임류 애플리케이션은 최대 대역폭보다 지연과 지터를 우선 확인

라이브 방송과 경기 중계

스포츠 라이브 방송은 지연과 동시 접속에 더 민감합니다. 경기 시작 10분 전이 연결 수립의 피크이므로, 미리 연결하고 재생 페이지를 미리 열어 두는 편이 경기 시작 후에 회선을 급히 바꾸는 것보다 안정적입니다. 경기 기간의 회선 선택 요령은 스포츠 라이브 회선 비교에 더 자세한 대조가 있습니다.

06 · 안정성

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

끊김은 두 가지로 나뉩니다. 연결이 능동적으로 끊긴 경우와, 연결은 남아 있지만 애플리케이션 계층에 트래픽이 없는 경우입니다. 전자는 클라이언트가 끊김과 재연결을 표시하고, 후자는 계속 연결된 것처럼 보이지만 실제로는 아무것도 통하지 않습니다. 대응 방식이 완전히 다릅니다.

일정 간격으로 끊김

일정 시간마다 한 번씩 끊긴다면 보통 하트비트 타임아웃이나 유휴 타임아웃과 관련이 있습니다. 중간 장비는 오랫동안 트래픽이 없는 세션 항목을 정리하는데, 클라이언트는 연결이 살아 있다고 보고 장비 쪽은 이미 그 세션을 잊은 상태가 됩니다. 대응 방법은 클라이언트에서 하트비트 간격을 켜거나 짧게 줄이는 것이고, 또는 연결이 가벼운 백그라운드 트래픽을 조금이라도 유지하게 하는 것입니다.

무작위 끊김

규칙성 없이 끊긴다면 대개 링크 지터입니다. 판단 방법은 끊긴 순간 클라이언트 상태를 바로 보는 것입니다. '연결됨, 트래픽 없음'으로 표시되면 링크 문제이고, '연결 끊김'으로 표시되면 로컬 네트워크나 가상 어댑터 문제입니다. Wi-Fi 신호 약화, 공유기 부하, 통신사 회선 지터가 모두 이 유형을 만듭니다.

데스크톱 절전 모드에서 깨어날 때

노트북 덮개를 닫아 절전에 들어갔다가 깨어나면 가상 어댑터가 트래픽을 다시 넘겨받지 못해, 클라이언트는 연결됨으로 표시되지만 실제로는 통하지 않을 수 있습니다. 연결을 끊고 다시 연결하면 복구됩니다. 깨어날 때마다 수동으로 재연결해야 한다면 클라이언트의 시작 프로그램 등록과 네트워크 변경 시 자동 재연결 옵션을 확인하세요.

공유기 아래의 세션 테이블

공유기는 NAT 세션 테이블을 유지해야 하는데, 테이블이 가득 차면 새 연결이 만들어지지 않아 '인터넷은 살아 있는데 새 페이지가 열리지 않는' 형태로 나타납니다. 보급형 공유기는 세션 테이블 용량이 제한적이라 기기가 많아지고 동시 접속이 늘면 쉽게 한계에 부딪힙니다. 공유기를 재시작하면 일시적으로 완화되지만, 장기적인 해법은 동시 연결 기기를 줄이거나 메모리가 더 큰 공유기로 바꾸는 것입니다.

모바일 백그라운드 연결 종료

iOS와 Android 모두 백그라운드 앱의 네트워크 활동을 제한합니다. 백그라운드로 내려간 뒤 일정 시간이 지나면 시스템이 VPN 구성을 회수하거나 클라이언트 프로세스를 중단시켜, 다시 앞으로 가져오면 재연결 중으로 표시됩니다. 이는 시스템 정책이지 회선 고장이 아닙니다.

• iOS: VPN 구성의 필요 시 연결(On-Demand)이 켜져 있는지 확인하고, 해당 클라이언트의 저전력 모드 제한을 해제하며, 백그라운드 앱 새로 고침을 허용하세요.
• Android: 배터리 최적화에서 클라이언트를 '제한 없음'으로 설정하고, 제조사 절전 정책이 해당 앱을 정리하지 않도록 하며, 백그라운드 활동을 허용하세요.
• 공통: '백그라운드 정리' 방식으로 클라이언트를 종료하지 마세요. 많은 시스템이 VPN 구성까지 함께 중단시킵니다.

07 · 설정 가져오기

구독 갱신 실패

구독 갱신은 본질적으로 클라이언트가 서버에서 설정 파일을 받아 오는 작업입니다. 실패 원인은 세 지점에 집중됩니다. 받아 올 때 프록시를 거치지 않은 경우, 구독 주소가 무효화된 경우, 클라이언트가 이전 설정을 캐시한 경우입니다. 이 순서로 확인하면 대부분 한 번에 원인을 찾을 수 있습니다.

먼저 요청 경로 확인

많은 클라이언트가 구독을 갱신할 때 프록시를 거치지 않고 직접 연결로 받아 옵니다. 구독 주소가 현재 네트워크에서 도달할 수 없는 곳이라면 갱신이 실패합니다. 대응 방법은 클라이언트를 전체(글로벌) 모드로 바꾸거나, 갱신 요청이 이미 수립된 터널을 지나가게 한 뒤 갱신을 누르는 것입니다. 갱신이 성공하면 다시 규칙 모드로 돌아오면 됩니다.

구독 주소와 자격 증명

구독 주소에는 신원 정보가 들어 있어 비밀번호와 같습니다. 주소가 재설정되거나 만료되면 갱신 시 오류가 반환됩니다. 사용자 패널에서 구독 주소를 다시 발급받아 클라이언트의 이전 주소를 교체하세요.

# 예시: 구독 주소의 형태(예시 값이며 실제 주소가 아님)
https://example.com/sub?token=YOUR_TOKEN

위 주소는 형태를 설명하기 위한 것입니다. 실제 구독 주소는 사용자 패널에서 받아 오세요. 인터넷에 떠도는 예시를 복사하지 말고, 자신의 주소를 공개된 장소에 올리지도 마세요.

클라이언트 캐시

갱신은 성공했는데 회선 목록이 그대로라면 보통 클라이언트가 캐시를 사용한 것입니다. 캐시를 비우거나 구독을 삭제한 뒤 다시 가져오면 강제로 새로 고칠 수 있습니다. 일부 클라이언트는 '전체 업데이트'를 직접 눌러야 규칙을 다시 받아 오며, 노드만 업데이트하면 분할 라우팅 규칙은 갱신되지 않습니다.

공유기에서의 갱신

공유기 환경에서 갱신 실패는 보통 세 가지 원인에서 나옵니다. 공유기 시간이 동기화되지 않아 인증서 검증이 실패하는 경우, DNS가 구독 도메인을 해석하지 못하는 경우, 저장 공간이 부족해 쓰기에 실패하는 경우입니다. 하나씩 배제하세요. 먼저 시간을 맞추고, 다음으로 DNS를 바꾸고, 마지막으로 저장 공간을 확인합니다.

구독 형식과 클라이언트 호환

같은 구독 주소라도 클라이언트에 따라 다른 형식이 필요할 수 있습니다. 형식이 맞지 않으면 클라이언트가 해석 실패를 표시하거나, 가져오기는 성공했는데 회선 목록이 비어 있게 됩니다. 이런 경우 먼저 패널에서 구독 형식 옵션을 확인하고, 클라이언트에서 그에 맞는 가져오기 방식을 선택하세요. 형식을 구분하기 어렵다면 클라이언트가 기본으로 권장하는 방식을 우선 사용하세요.

08 · 분할 라우팅 인계

특정 앱이 프록시를 타지 않음

브라우저는 정상인데 특정 앱만 연결되지 않는다면 터널 자체는 통하고 있다는 뜻이며, 문제는 그 앱의 트래픽이 넘겨받아지지 않았거나, 넘겨받은 뒤 이름 해석에 실패한 것입니다.

먼저 전체 모드로 대조

클라이언트를 전체(글로벌) 모드로 바꾸고 같은 앱을 열어 보세요. 전체 모드에서 정상이라면 규칙이 그 앱의 도메인을 포함하지 않은 것이고, 전체 모드에서도 비정상이라면 앱이 가상 어댑터를 타지 않거나 자체적인 네트워크 구현을 쓰는 것입니다.

시스템 프록시와 가상 어댑터

시스템 프록시는 시스템 프록시 설정을 읽는 앱에만 적용됩니다. 게임, 일부 데스크톱 클라이언트, 명령줄 도구를 비롯한 많은 앱은 시스템 프록시를 읽지 않고 가상 어댑터만 사용합니다. 이런 트래픽을 넘겨받으려면 클라이언트에서 TUN 모드나 가상 어댑터 모드를 켜야 합니다.

앱 자체의 네트워크 구현

• 자체 DNS를 쓰는 앱: 시스템 DNS를 우회해 고정 주소로 직접 조회하므로 분할 라우팅 규칙이 잘못 판정할 수 있습니다.
• IP를 하드코딩한 앱: 도메인 해석을 거치지 않아 도메인 기준 규칙에 걸리지 않습니다.
• QUIC를 쓰는 앱: UDP를 사용하는데 일부 네트워크가 이를 제한해, 연결은 수립되지만 로딩이 안 되는 형태로 나타납니다.
• 독자 프로토콜을 쓰는 클라이언트: 별도로 프록시를 설정하거나 가상 어댑터를 강제로 태워야 합니다.

앱별 프록시

일부 클라이언트는 앱별 분할을 지원합니다. 어떤 앱이 프록시를 타고 어떤 앱이 직접 연결될지 지정하는 방식입니다. 규칙이 반대로 들어가면 '타야 할 앱이 안 타고, 직접 연결돼야 할 앱이 타는' 상황이 생깁니다. 목록에서 대상 앱이 프록시 쪽에 있는지 확인하고, 수정한 뒤 앱을 한 번 재시작하고 다시 테스트하세요.

명령줄 도구와 환경 변수

명령줄 도구는 보통 환경 변수만 인식하고 시스템 프록시는 읽지 않습니다. 터미널에서 한 번 설정한 뒤 네트워크가 필요한 명령을 실행하세요.

# 포트는 클라이언트가 실제로 수신 중인 값을 기준으로
export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890

# 송출 확인: 반환값이 현재 회선의 송출 지역과 일치해야 함
curl -s https://example.com/ip

실제로 프록시를 타고 있는지 검증

앱에서 송출 주소를 조회하는 페이지를 열어, 반환되는 주소가 회선의 송출 지점인지 확인하세요. 이 단계로 트래픽이 실제로 넘겨받아졌는지 확인할 수 있습니다. 더 자세한 자가 점검 방법은 연결 후 정상 작동 확인 방법에 있습니다.

09 · 계정과 상담

계정, 기기, 문의 접수

앞의 여덟 장은 기술적 고장을 다뤘습니다. 이 장은 계정 차원의 문제와, 실제로 사람의 개입이 필요할 때 어떻게 해야 하는지를 다룹니다.

기기 수 무제한의 의미

이 서비스의 요금제는 기기 수를 제한하지 않으며, 기기 대수로 과금하지 않습니다. 같은 계정을 Windows, macOS, iOS, Android, Linux에 동시에 설치할 수 있고, 두 번째 기기 때문에 추가로 구매할 필요가 없습니다. 무제한은 기기 대수를 뜻하며 총 대역폭 무제한과 같지 않습니다. 동시에 접속한 기기가 많을수록 기기 한 대가 받는 대역폭은 줄어듭니다.

공유기와 공유 사용

공유기에 설정하면 공유기가 기기 한 대로 계산되고, 그 뒤에 연결된 모든 기기가 이 연결을 공유합니다. 가정에서는 가장 간편한 방식이지만 공유기 성능을 주의해야 합니다. 보급형 공유기는 암호화 처리량이 제한적이라 기기가 많아지면 쉽게 병목이 됩니다. 판단 방법은 간단합니다. 클라이언트를 컴퓨터에 직접 설치해 비교했을 때 직접 연결이 확실히 빠르다면 병목은 공유기에 있습니다.

기기 수 관련 안내를 어떻게 이해할까

이 서비스는 기기 수를 제한하지 않으므로 정상적인 상황에서는 기기 대수 때문에 거부되지 않습니다. 특정 클라이언트에 기기 수와 관련된 안내가 뜬다면 먼저 로그아웃 후 다시 로그인해 계정 정보를 새로 받아 오게 하세요. 그래도 안내가 남아 있다면 스크린샷을 찍어 안내가 나타난 클라이언트와 시각을 적어 문의를 접수하세요.

트래픽과 만료

월 구독 트래픽은 달력 기준이 아니라 개통일을 기준으로 매월 초기화됩니다. 중간에 요금제를 업그레이드하면 차액이 남은 일수로 환산됩니다. 트래픽 패키지는 다 쓸 때까지 유효하고 영구적으로 만료되지 않아 월이 바뀌어도 영향받지 않습니다. 두 종류의 용량은 패널에 각각 표시되니, 갱신 전에 어느 쪽이 먼저 소진되는지 확인하세요.

계정 자격 증명 관리

가입에는 사용자 이름과 비밀번호만 필요하고 이메일 주소는 필요하지 않으므로, 계정 자격 증명은 이 두 가지입니다. 즉 이메일로 찾는 절차를 쓸 수 없으니 비밀번호는 반드시 직접 관리하고, 구독 주소와 함께 공개된 장소에 두지 마세요. 요금제와 트래픽 패키지의 대응 관계는 요금제 가격에서 확인할 수 있고, 결제 수단은 알리페이 / 위챗 / USDT를 지원합니다.

환불

30일 무조건 환불입니다. 신청 경로와 필요한 정보는 환불 정책에서 확인할 수 있으며, 제출할 때 주문 시각과 요금제 이름을 함께 적으면 확인이 더 빠릅니다.

고객 지원이 필요한 상황

• 지역이 다른 회선을 최소 세 개 이상 바꾸고, 네트워크도 바꾸고, 프로토콜도 전환했는데 여전히 전혀 연결되지 않음
• 패널에는 구독이 유효하고 트래픽도 충분한데 클라이언트가 계속 인증 실패를 표시함
• 구독 갱신이 여러 네트워크에서 모두 실패함
• 특정 회선이 여러 날 연속 특정 시간대에 사용 불가
• 계정 관련 과금, 환불, 요금제 변경 문제

문의에 첨부할 항목

정보가 충실한 문의 한 건이면 보통 한 번에 원인을 찾습니다. 다음을 첨부하세요.

• 문제가 발생한 시각과 시간대
• 플랫폼과 OS 버전
• 클라이언트 화면 안내 문구 원문, 스크린샷 또는 텍스트
• 당시 선택한 회선 이름과 회선 유형
• 이미 수행한 점검 동작과 결과
• 공유기에서 사용 중인지, 공유기 아래에 기기가 몇 대 연결돼 있는지

문제 증상: 연결 후 브라우저에서 페이지가 열리지 않고, 클라이언트는 연결됨으로 표시
발생 시각: 2026-10-20 21:30 (UTC+8)
플랫폼: Windows / 클라이언트 현재 버전
현재 회선: 일본 · 도쿄(중계)
점검 완료: 전체 모드 전환 무효, DNS 변경 후에도 실패,
        싱가포르 회선으로 바꾸면 정상적으로 열림
추가: 공유기 아래 기기 세 대 연결

구독 주소 전체, 비밀번호 또는 기타 자격 증명은 첨부하지 마세요. 계정을 설명해야 할 때는 사용자 이름만 알려 주면 됩니다.

접수 전에 한 번 확인

많은 문제가 도움말 센터에 이미 답이 있습니다. 특히 과금과 요금제 관련 항목이 그렇습니다. 확인한 뒤 문의를 넣으면 문제 설명이 더 정확해지고, 같은 문제로 중복 대기하는 일도 피할 수 있습니다.