해외 연결장애 점검 매뉴얼

점검 순서: 어떤 설정보다 세 가지 판단이 먼저

연결 장애는 복잡해 보이지만 실제로는 세 계층으로만 나뉩니다. 계정과 구독, 클라이언트와 기기, 라인과 네트워크입니다. 세 계층 중 어디서 문제가 생겨도 드러나는 증상은 비슷할 수 있습니다. 계속 로딩, 타임아웃, 페이지가 열리지 않음 같은 것들입니다. 그래서 이 매뉴얼은 계층을 먼저 특정하고 설정을 바꾸는 순서를 따릅니다. 한 번에 변수 하나만 바꾸고, 바꾼 즉시 다시 측정하세요. 세 곳을 동시에 바꾸면 복구되어도 어디서 효과가 났는지 알 수 없고, 다음에 재발하면 처음부터 다시 해야 합니다.

판단 1: 계정과 구독이 유효한가. 사용자 패널에 로그인해 요금제가 유효 기간 내에 있고 이번 달 트래픽이 남아 있는지 확인합니다. 트래픽은 개통일 기준 매월 초기화되며, 다 써도 자동으로 채워지지 않습니다. 증상은 모든 라인이 연결되지 않거나, 연결은 되는데 트래픽이 흐르지 않는 것입니다. 이 단계에서는 패널만 보고 클라이언트는 건드리지 않습니다.

판단 2: 장애가 전체인지 단일 지점인지. 다른 기기로 바꾸고, 다른 네트워크로 바꾸고(예: 다른 기기로 핫스팟 켜기), 다른 대상 사이트로 바꿔 봅니다. 세 번 중 한 번이라도 정상이면 계정과 라인 풀 자체에는 문제가 없고 로컬에 문제가 있다는 뜻입니다. 셋 다 실패해야 라인을 의심할 만합니다.

판단 3: 문제가 클라이언트에 있는지 라인에 있는지. 같은 라인에서 반복 실패하고 다른 라인으로 바꾸면 정상이라면 라인 문제입니다. 어느 라인으로 바꿔도 똑같이 실패하면 클라이언트나 로컬 네트워크 문제입니다. 이 판단이 이후에 2장을 볼지 3장을 볼지를 결정합니다.

이 세 가지를 마치면 보통 어느 장으로 넘어가야 할지 정해집니다. 아래 표는 흔한 증상과 장을 대응시킨 것이니, 증상으로 먼저 찾은 뒤 해당 장에서 하나씩 따라 하면 됩니다.

점검을 시작하기 전에 세 가지를 준비해 두면 좋습니다. 문제가 발생한 기기, 문제가 발생한 시각, 클라이언트 로그에서 그 시각에 해당하는 몇 줄입니다. 문의에서 가장 값진 정보는 “연결이 안 된다”는 한마디가 아니라 “몇 시 몇 분, 어느 라인, 오류 원문이 무엇인지”입니다. 로그를 꺼내는 방법은 10장에서 한꺼번에 설명합니다.

재측정 방법도 고정해야 합니다. 같은 대상 사이트, 같은 시간대, 같은 명령입니다. 설정을 바꾼 뒤 서로 다른 지역의 사이트 세 곳을 바로 열어 보는 편이 연결 버튼을 여러 번 누르는 것보다 문제를 잘 드러냅니다. 바꾼 뒤 첫 시도에 바로 되더라도 바로 끝내지 말고 10분 뒤에 한 번 더 재측정하세요. 간헐적 장애는 첫 성공에 가장 쉽게 가려집니다.

완전 연결 불가: 구독부터 로컬 포트까지 단계별 점검

먼저 “연결 안 됨”을 세 가지 증상으로 나눕니다. 연결을 누른 뒤 계속 로딩만 도는 경우, 몇 초 안에 바로 실패하는 경우, 연결됨으로 표시되지만 트래픽 카운트가 계속 0인 경우입니다. 첫 번째는 대개 핸드셰이크에서 막히고, 두 번째는 대개 로컬 설정이나 포트 문제이며, 세 번째는 터널은 만들어졌지만 트래픽이 지나가지 않는다는 뜻입니다. 세 증상은 점검 시작점이 다르므로, 섞어서 보면 볼수록 더 엉킵니다.

아래 여섯 단계는 계정에서 로컬 순으로 배열했고, 각 단계만으로도 결론을 낼 수 있습니다. 어느 단계에서 통하면 거기서 멈추면 되고, 굳이 계속 내려갈 필요는 없습니다.

1. 구독이 유효 기간 내에 있고 이번 달 트래픽이 남아 있는지 확인

   사용자 패널에 로그인해 요금제 만료 시각과 이번 달 남은 트래픽을 봅니다. 월 구독의 트래픽은 개통일 기준 매월 초기화되고, 다 써도 자동으로 채워지지 않습니다. 트래픽 패키지는 소진될 때까지 쓸 수 있고 영구적으로 만료되지 않으며, 월 구독 트래픽과 별도로 계산됩니다. 이 단계에서는 패널만 보고 클라이언트는 바꾸지 않습니다.

2. 다른 라인으로 바꿔 보기

   같은 지역에서 도시를 바꾸거나(도쿄→서울), 라인 유형을 바꿉니다(IEPL→중계). 서로 다른 지역의 라인 세 개가 연속으로 실패하면 단일 라인 문제는 거의 배제할 수 있고, 하나만 실패한다면 그 라인 문제이므로 바꾸면 됩니다.

3. 다른 네트워크로 바꾸기

   다른 기기로 핫스팟을 켜서 PC에 연결하거나, 모바일 네트워크로 바꿔 봅니다. 회사망, 학교망, 호텔 네트워크는 포트와 프로토콜을 제한하는 경우가 많습니다. 네트워크만 바꿨는데 통한다면 계정 문제가 아니라 로컬 네트워크 정책입니다. 이 항목 하나로 클라이언트 설정을 만지느라 쓰는 시간을 크게 줄일 수 있습니다.

4. 시스템 시간 맞추기

   시스템 시간을 자동 동기화로 설정합니다. 시간 오차가 몇 분을 넘으면 TLS 핸드셰이크가 실패하는데, 클라이언트는 보통 “연결 실패” 한 줄만 보여줘서 진짜 원인을 알 수 없습니다. 맞춘 뒤 클라이언트를 다시 시작하고 한 번 더 시도하세요.

5. 다른 프록시류 프로그램 종료

   클라이언트 두 개가 동시에 실행되면 같은 로컬 포트를 두고 다투며, 나중에 실행된 쪽이 조용히 실패하는 경우가 많습니다. 트레이와 작업 관리자를 확인해 쓰지 않는 프록시, 가속기, 패킷 캡처 도구를 모두 종료하고 하나만 남깁니다.

6. 방화벽과 보안 프로그램 확인

   처음 실행할 때 차단된 인바운드 규칙은 저절로 복구되지 않습니다. 시스템 방화벽에서 해당 클라이언트를 찾아 인바운드와 아웃바운드가 모두 허용되어 있는지 확인하세요. 서드파티 보안 프로그램의 “네트워크 보호” 기능도 터널을 막을 수 있으니, 잠시 끄고 다시 테스트합니다.

놓치기 쉬운 원인 몇 가지

로컬 포트 충돌. 클라이언트 기본 로컬 포트를 다른 프로그램이 이미 점유하고 있을 수 있습니다. 화면은 정상이고 연결 버튼도 눌리지만, 시스템 프록시가 가리키는 포트에 서비스가 없는 상태입니다. 포트를 바꾸거나 점유한 프로그램을 종료하면 됩니다.

네트워크의 UDP 제한. 일부 네트워크는 UDP를 속도 제한하거나 아예 버립니다. 클라이언트에서 TCP로 바꾸거나 전송 방식을 바꿔 다시 시도해 보고, 연결되면 이 원인입니다.

루프백 프록시. 분할 터널링 규칙이 구독 도메인과 패널 도메인까지 프록시로 보내는데 프록시가 아직 연결되지 않은 상태라면, 구독 갱신과 연결 수립이 서로를 기다리게 되어 아무리 해도 연결이 안 되는 것처럼 보입니다. 이 두 도메인을 직접 연결로 지정한 뒤 다시 연결하세요.

공유기 쪽 차단. 자녀 보호, 인터넷 사용 시간 관리, DNS 필터링은 모두 공유기 계층에서 막습니다. 모바일 네트워크와 한 번 비교하면 확인됩니다.

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

서로 다른 지역·서로 다른 라인 유형의 라인 세 개가 모두 실패하고, 서로 다른 네트워크 두 곳에서도 똑같이 실패하고, 시스템 시간이 맞춰져 있고 다른 프록시 프로그램이 모두 종료된 상태 — 이 세 조건이 동시에 성립하면 로컬 문제가 아니라고 판단할 수 있습니다. 이때는 클라이언트 로그와 문제 발생 시각을 붙여 문의하는 편이 계속 시도하는 것보다 효율적입니다. 문의에 어떤 정보를 붙여야 하는지는 10장을 보세요.

연결은 되는데 웹페이지가 안 열릴 때: 전체인지 일부인지부터

클라이언트는 연결됨으로 표시되고 트래픽도 흐르는데 브라우저가 페이지를 열지 못합니다. 첫 번째 할 일은 설정을 바꾸는 것이 아니라 구분입니다. 모든 사이트가 안 열리는지, 일부만 안 열리는지입니다. 이 구분이 이후 경로의 90%를 결정합니다.

전부 안 열림

전부 안 열린다면 보통 DNS가 터널을 따라가지 않거나, 패킷이 경로에서 버려지고 있다는 뜻입니다. 아래 세 가지를 차례로 확인합니다.

DNS가 터널 안에서 확인되는지. 클라이언트에서 “DNS를 터널에서 확인” 같은 옵션이 켜져 있는지, 시스템 DNS가 특정 로컬 주소로 고정되어 있지 않은지 확인합니다. 판단 방법은 9장에 있습니다.

MTU가 맞는지. 터널 캡슐화는 패킷 길이의 일부를 차지합니다. 로컬이 여전히 1500이면 큰 패킷이 버려지고, 전형적으로 첫 화면은 열리는데 이미지와 영상이 로드되지 않고 페이지가 중간에서 멈춥니다. 단편화 금지 ping으로 한 번 측정해 보세요:

# Windows
ping -f -l 1472 example.com

# Linux / macOS
ping -M do -s 1472 example.com

1472에 28바이트 헤더를 더하면 정확히 1500입니다. 통과하면 MTU에 문제가 없습니다. 패킷 분할이 필요하다는 메시지가 나오거나 그냥 타임아웃이면, 값을 1400 근처까지 단계적으로 낮춰 다시 시도하고 클라이언트 MTU를 1400에서 1450 사이로 맞추세요. 터널류 문제에서 흔히 쓰는 값이라 정확히 맞출 때까지 반복할 필요는 없습니다.

분할 터널링 규칙이 브라우저를 직접 연결로 판정했는지. 전역 모드로 한 번 돌려 보고 열리면 규칙 문제이므로, 다시 규칙 모드로 돌아가 화이트리스트를 하나씩 보완합니다.

일부만 안 열림

특정 사이트만 안 열린다면 문제는 보통 터널이 아니라 대상 사이트 쪽에 있습니다.

지역 제한. 사이트가 출구 지역을 기준으로 서비스를 제공한다면 해당 지역 라인을 쓰면 됩니다. 자주 쓰는 지역과 적합한 용도의 대응표는 4장에 있습니다.

출구 IP로 인한 추가 인증. 같은 출구를 여러 사람이 쓰면 사이트가 추가 인증을 요구하거나 아예 거부할 수 있습니다. 같은 지역의 다른 라인으로 바꾸면 보통 통과됩니다.

로컬 캐시. 브라우저와 앱이 오래된 확인 결과나 오래된 연결을 캐시하고 있을 수 있습니다. DNS 캐시를 한 번 비우고(명령은 9장) 새로 고침하세요.

스트리밍과 계정 지역. 스트리밍은 출구 지역뿐 아니라 계정 가입 지역도 봅니다. 출구는 바꿨는데 계정 지역이 그대로면 여전히 일부 콘텐츠만 볼 수 있습니다. 이런 경우는 라인을 바꿔도 해결되지 않고, 계정 쪽을 일치시켜야 합니다.

분할 터널링 모드 선택

점검할 때는 전역 모드로 한 번 돌려 보세요. 전역에서는 통하고 규칙에서는 안 통하면 90%는 분할 터널링 규칙 문제이고, 두 모드 모두 안 통하면 DNS와 MTU 항목으로 돌아갑니다. 원인이 분명해진 뒤 규칙 모드로 돌아가 빠진 도메인을 화이트리스트에 추가하세요. 전역 모드를 오래 켜 두는 것은 권장하지 않습니다. 내부망 접속, 같은 네트워크의 기기, 로컬 개발 서버까지 전부 터널로 밀어 넣어 대가가 적지 않습니다.

속도 저하와 저녁 피크 버벅임: 먼저 세 가지 느림을 구분

느림은 적어도 세 가지입니다. 계속 느린 경우, 특정 시간대에 느린 경우, 특정 사이트만 느린 경우입니다. 원인과 대처가 완전히 다르므로 섞어서 고치면 수고만 들고 끝납니다. 2분만 들여 어느 유형인지 확인한 뒤 손을 대세요.

계속 느림

연결 직후부터 어느 시간대든 느리다면 보통 로컬 문제입니다. 차례로 확인하세요. 로컬 회선 자체의 실제 속도, Wi-Fi가 2.4GHz 대역에서 동작 중인지(가까우면 5GHz 우선), 공유기가 오래되었거나 속도 제한이 걸려 있는지, 백그라운드에서 시스템 업데이트·클라우드 동기화·백업이 돌고 있는지.

출구 지역을 너무 멀리 고른 경우도 흔합니다. 물리적 거리가 하한을 결정하므로, 아시아에서 유럽 출구로 접속하면 라인이 아무리 좋아도 한 구간을 더 지나야 합니다. 가까운 지역을 고르는 것이 체감 속도를 올리는 가장 직접적인 방법입니다.

특정 시간대에 느림

낮에는 정상인데 저녁에 느려지는 것은 국제 대역폭의 공통 현상이며 특정 서비스만의 문제가 아닙니다. 저녁에는 재연결을 반복하기보다 라인 유형을 바꾸는 쪽이 답입니다.

라인 유형은 클라이언트의 라인 목록에서 바로 볼 수 있고, 각 라인 뒤에 유형이 표시됩니다. 저녁에는 자주 쓰는 라인을 직접 연결에서 같은 지역의 IEPL 전용선으로 바꾸는 편이 지역을 바꾸는 것보다 보통 더 효과적입니다.

특정 사이트만 느림

특정 사이트만 느리다면 먼저 사이트 자체를 의심하세요. 공유 출구에 속도 제한을 두는지, 단일 연결에 제한을 두는지, CDN이 먼 노드로 보내고 있는지입니다. 판단은 간단합니다. 같은 라인에서 비슷한 다른 사이트를 열어 속도가 정상이라면 터널 문제가 아닙니다.

브라우저 확장 프로그램도 속도를 떨어뜨립니다. 광고 차단, 스크립트 관리, 번역 확장은 해외 접속 시 대기 시간을 증폭시킵니다. 시크릿 창(기본적으로 확장을 불러오지 않음)으로 한 번 비교하면 확인됩니다.

어떻게 측정해야 의미가 있는가

속도 측정 앱의 최고값을 보지 말고 실제 작업 완료 시간을 보세요. 같은 영상이 재생되기까지 걸린 시간, 같은 파일이 다운로드 완료되기까지 걸린 시간입니다. 측정할 때는 세 가지를 고정합니다. 같은 대상, 같은 시간대, 같은 조작입니다. 라인 A와 B를 각각 세 번씩 측정해 중간값을 비교해야 두 결론이 비교 가능해집니다.

이 사이트의 라인 표에는 지연 수치를 적지 않고, 페이지에도 실시간 속도 측정을 넣지 않습니다. 지연은 로컬 네트워크, 시간대, 대상 사이트에 따라 달라지므로 고정값을 적는 것은 참고 가치가 없습니다. 실제 체감은 자기 네트워크에서만 측정할 수 있습니다.

용도별 출구 지역 선택

더 자세한 라인 선택 규칙은 라인 선택 입문 가이드를, 전체 지역과 라인 분포는 서버 페이지를 보세요.

요금제를 올릴 때를 판단하는 기준

느림과 “트래픽 소진”은 다른 문제입니다. 트래픽을 다 쓰면 보통 느려지는 것이 아니라 아예 연결되지 않습니다. 트래픽이 부족한 것이 확인되면 월 구독은 세 가지가 있습니다. ¥9.9 매월 60GB, ¥18 매월 250GB, ¥28 매월 500GB이며, 트래픽은 개통일 기준 매월 초기화되고 중간에 업그레이드하면 남은 일수만큼 차액을 정산합니다. 사용량 변동이 큰 경우에는 트래픽 패키지를 더할 수도 있습니다. ¥158/300GB, ¥358/1000GB, ¥658/3000GB이며 소진될 때까지 쓸 수 있고 영구적으로 만료되지 않습니다. 자세한 비교는 요금제 페이지를 보세요.

잦은 끊김: 끊기는 시간 규칙으로 원인 역추적

끊김은 라인 불안정으로 오해하기 쉽습니다. 먼저 라인을 바꾸지 말고 규칙을 보세요. 일정 간격으로 끊김, 무작위로 끊김, 네트워크를 바꿀 때 끊김입니다. 세 규칙은 원인이 완전히 다르므로, 규칙을 제대로 보면 원인이 거의 나옵니다.

일정 간격으로 끊김

5분마다, 30분마다 끊기고 시각이 거의 일치합니다. 이런 끊김은 보통 라인이 죽은 것이 아니라 세션이 회수된 것입니다.

하트비트와 타임아웃. 클라이언트는 일정 시간 데이터가 오가지 않으면 스스로 끊고 다시 연결합니다. 가만히 두면 끊기고 트래픽이 있으면 정상이라면 이 원인입니다. 클라이언트에서 “연결 유지”, “주기적 하트비트” 같은 옵션을 켜면 됩니다.

세션 타임아웃. 공유기나 통신사 쪽에서 오래 유휴 상태인 세션을 회수합니다. 증상은 하트비트 문제와 같고, 대처는 공유기의 세션 타임아웃을 늘리거나 클라이언트가 주기적으로 탐색 패킷을 보내게 하는 것입니다.

무작위로 끊김

정해진 시간이 없고, 끊긴 뒤 자동으로 복구되기도 하고 수동으로 다시 연결해야 하기도 합니다. 흔한 원인은 세 가지입니다. Wi-Fi 로밍(기기가 여러 액세스 포인트를 오갈 때 터널 재구성), 신호 약화, 절전 정책(8장 참고).

처리 순서: 하나의 Wi-Fi 대역과 하나의 액세스 포인트에 고정해 대조하고, 시스템의 “Wi-Fi 도우미”, “네트워크 자동 전환”을 끄고, 끊길 때의 위치와 동작을 기록하세요. 이동 중에 끊기고 앉으면 복구된다면 로밍이 거의 확실합니다.

네트워크를 바꿀 때 끊김

Wi-Fi에서 모바일 네트워크로, 또는 유심 한 장에서 다른 장으로 바꿀 때 끊기는 것은 그 자체로 정상이며 터널을 다시 만들어야 합니다. 확인할 것은 자동 재연결 여부입니다. 클라이언트에서 “네트워크 변경 시 자동 재연결” 같은 스위치를 찾아 켜세요. 일부 시스템은 네트워크를 바꾼 뒤 연결 권한을 회수하므로 한 번 더 승인해야 합니다.

무엇을 기록해야 쓸모가 있는가

세 번 끊기면 규칙이 보입니다. 단, 기록이 제대로 되어 있어야 합니다. 네 가지를 적으세요. 시각(분 단위), 지속 시간, 그때 무엇을 하고 있었는지(가만히 있었는지 전송 중이었는지), 네트워크를 바꿨는지. 여기에 클라이언트 로그의 해당 시각 몇 줄을 더하면 위의 어느 유형인지 판단하기에 충분합니다.

클라이언트 쪽 스위치 네 가지

대부분의 끊김 문제는 이 네 가지 스위치로 해결됩니다. 부팅 시 자동 연결(재시작 후 연결을 잊는 일 방지), 끊김 시 자동 재연결(수동 개입 방지), 연결 유지와 하트비트(세션 회수 대응), 사용할 때만 연결(모바일 절전, 대신 백그라운드 연속성 희생). 네 가지는 사용 상황에 맞게 선택하세요. 데스크톱은 앞의 세 가지를 모두 켜고, 모바일은 백그라운드 상주가 필요한지에 따라 네 번째를 정하면 됩니다.

언제가 상위 문제인가

같은 라인이 서로 다른 기기, 서로 다른 네트워크에서 비슷한 시각에 끊기고 라인을 바꾸면 괜찮아진다면 그때 상위 문제를 의심합니다. 이때는 라인을 바꾸고 그 시각을 문의에 적는 편이 재연결을 반복하는 것보다 유용합니다.

구독 갱신 실패: 링크 완전성부터 가져오기 네트워크까지

구독 갱신의 본질은 클라이언트가 구독 주소로 요청을 한 번 보내 설정 텍스트를 받아오는 것입니다. 실패 원인은 네 가지뿐입니다. 링크가 틀림, 요청이 나가지 못함, 요청이 중간 페이지에 가로채짐, 클라이언트가 저장하지 못함. 순서대로 배제하면 네 단계 안에 결론이 나옵니다.

1. 링크 전체를 다시 복사

   사용자 패널에서 복사하세요. 손으로 옮겨 적지 말고, 메신저로 한 번 거친 텍스트도 쓰지 마세요. 중간의 줄바꿈과 공백까지 함께 복사됩니다. 링크에는 파라미터가 붙어 있어 한 글자만 빠져도 설정을 받아올 수 없습니다.

2. 브라우저에서 직접 한 번 열어 보기

   정상 응답은 순수 텍스트이거나 다운로드 파일입니다. 로그인 페이지, 오류 페이지, 또는 빈 화면이 열린다면 링크가 만료되었거나 요청이 중간 페이지에 가로채진 것입니다. 이 단계가 이 장에서 가장 효과가 큰 단계입니다.

3. 먼저 연결한 뒤 갱신

   구독 주소 자체가 터널을 통해서만 접근 가능할 수 있습니다. 사용 가능한 라인으로 먼저 연결한 뒤 갱신을 누르세요. 반대로 하면 “연결이 안 되어 갱신을 못 하고, 갱신을 못 해서 연결이 안 되는” 순환에 갇힙니다.

4. 기존 구독을 삭제하고 다시 추가

   갱신을 반복해서 누르는 것보다 확실합니다. 일부 클라이언트는 갱신 실패 후 기존 설정을 그대로 두기 때문에, 갱신에 성공한 것처럼 보이지만 노드가 바뀌지 않습니다.

명령줄을 즐겨 쓰는 경우, 명령 한 줄로 경로가 뚫려 있는지 바로 확인할 수 있습니다:

curl -sS -m 15 "https://example.com/sub?token=YOUR_TOKEN" | head -n 5

예시 주소는 가짜 값이며 명령 형태를 보여 주기 위한 것입니다. 실제 링크는 패널에서 복사하세요. 명령이 텍스트를 반환하면 경로와 내용이 정상, HTML을 반환하면 요청이 중간 페이지에 가로채진 것, 그냥 타임아웃이면 요청이 나가지 못한 것입니다. 세 결과가 세 가지 대응 방향에 대응합니다.

갱신은 성공했는데 노드가 줄거나 비었을 때

줄어든 경우. 라인 풀은 운영 조정에 따라 늘기도 줄기도 하며 정상적인 현상입니다. 자주 쓰는 지역이 남아 있다면 따로 처리할 필요가 없습니다.

비어 버린 경우. 보통 오류 페이지를 받아와서 클라이언트가 노드를 하나도 파싱하지 못한 것입니다. 2단계로 돌아가 브라우저로 링크 자체를 확인하세요.

브라우저에서도 안 열리는 경우. 계정 쪽 문제이므로 패널에 로그인해 요금제 상태와 남은 트래픽을 확인하세요.

여러 기기에서 링크 하나를 공유

이 사이트는 동시 접속 기기 수에 제한이 없어서 같은 구독 링크를 여러 기기에 불러와도 됩니다. 기기마다 따로 신청할 필요가 없습니다. 다만 여러 기기에서 구독을 반복해서 재설정하지 마세요. 일부 클라이언트의 재설정은 기존 설정을 무효화해 다른 기기까지 함께 끊길 수 있습니다. 설정을 바꿔야 할 때는 새 링크를 먼저 불러와 사용 가능한 것을 확인한 뒤 기존 것을 삭제하세요.

시간 불일치도 갱신 실패를 일으킵니다

HTTPS 요청은 인증서 유효 기간을 검증합니다. 시스템 시간 오차가 크면 인증서 검증이 바로 실패하는데, 클라이언트는 세부 정보 없이 갱신 실패 한 줄만 보고합니다. 시스템 시간을 자동 동기화로 설정하고 클라이언트를 다시 시작해 보는 것이 이 문제의 유일한 처리 방법입니다.

특정 앱만 프록시를 타지 않을 때: 시스템 프록시를 따르는지부터

브라우저는 정상이고 특정 앱만 안 된다면 터널 자체는 뚫려 있고, 그 앱이 요청을 보내는 방식에 문제가 있습니다. 앱의 네트워크 동작은 세 부류입니다. 시스템 프록시를 따름, 자체적으로 직접 연결, UDP 사용. 어느 부류인지 먼저 판단한 뒤 어떤 방식으로 잡아들일지 정하세요.

세 부류의 앱

시스템 프록시를 따름. 대부분의 브라우저와 일부 데스크톱 앱이 여기에 속합니다. 시스템 프록시를 켜면 함께 따라갑니다.

자체 직접 연결. 많은 게임 런처, 소프트웨어 업데이터, 명령줄 도구는 시스템 프록시 설정을 읽지 않으므로, 가상 네트워크 인터페이스(TUN) 모드로 전역 트래픽을 인계해야 적용됩니다.

UDP 또는 QUIC 사용. 일부 브라우저와 영상 앱은 기본으로 QUIC을 씁니다. 터널의 UDP 지원이 좋지 않으면 오류 대신 그냥 멈춘 것처럼 보여서, 이 앱을 쓸 수 없다고 오해하기 쉽습니다.

플랫폼별 차이

처리 순서

1. TUN 모드로 전환

   가장 넓은 범위를 덮는 방식으로, 시스템 프록시를 읽지 않는 앱까지 커버합니다. 전환한 뒤 대상 앱을 다시 시작해 보세요.

2. 앱의 QUIC과 HTTP3 끄기

   브라우저에는 보통 끄는 항목이 있습니다. 끄면 트래픽이 TCP로 돌아가 터널이 훨씬 안정적으로 처리합니다.

3. 앱이 자체 DNS를 쓰는지 확인

   일부 앱은 자체 암호화 DNS를 내장해 시스템 설정을 우회합니다. 앱의 “보안 DNS” 옵션을 끄고 시스템을 따르게 하세요.

4. 명령줄 도구에 프록시 직접 지정

   클라이언트 화면에서 로컬 포트를 찾아 환경 변수에 넣거나 명령에 파라미터로 붙입니다. 백그라운드 서비스는 사용자 환경 변수를 상속하지 않으므로 따로 설정해야 합니다.

5. 앱별 프록시 목록 확인

   안드로이드처럼 앱별 프록시를 지원하는 플랫폼에서는 대상 앱이 프록시 목록에 체크되어 있어야 합니다. 그렇지 않으면 직접 연결로 나갑니다.

명령줄 도구가 실제로 터널을 타는지 확인하려면 상태 코드만 출력하는 명령이 가장 직접적입니다:

curl -sS -m 10 -o /dev/null -w "%{http_code}\n" https://example.com

200이 반환되면 이 명령의 트래픽이 통한 것이고, 000이면 통하지 않은 것입니다. 프록시를 켜기 전과 후에 각각 한 번씩 실행해 결과를 비교하면 됩니다. 같은 방법으로 특정 스크립트나 빌드 도구가 터널을 타는지도 판단할 수 있습니다.

그래도 안 되는 몇 가지 경우

앱이 IP를 하드코딩했거나 사설 프로토콜을 쓰는 경우. 이런 트래픽은 분할 터널링 규칙을 우회하므로 TUN 모드로 전체를 인계하는 방법밖에 없습니다.

앱에 별도 네트워크 권한이 있는 경우. 모바일에서는 일부 앱이 시스템에서 네트워크 권한을 따로 제한받습니다. 시스템 설정에서 허용하세요.

앱 자체의 지역 제한. 출구는 바꿨지만 계정 지역이 그대로면 앱은 여전히 서비스를 거부합니다. 터널과는 무관합니다.

개발 환경의 상시 연결 요구(자동 완성 요청, 패키지 관리자, 모델 API)는 안정성 요구가 더 높습니다. 라인 선택과 분할 터널링의 세부 내용은 AI 코딩 도구의 네트워크와 라인 안내를 보세요.

모바일 백그라운드 끊김: 절전 정책이 라인보다 흔함

화면을 잠그고 몇 분 지나면 연결이 사라지고, 잠금을 풀면 다시 연결해야 합니다. 이런 문제는 90%가 라인이 아니라 시스템의 백그라운드 관리 때문입니다. 절전을 위해 모바일 OS는 백그라운드 프로세스를 동결하고, 네트워크 설정을 회수하고, 백그라운드 데이터를 제한합니다. 먼저 플랫폼별 시스템 설정을 처리하고 그다음 라인을 보세요.

iOS

저전력 모드. 켜면 백그라운드 새로 고침과 네트워크 활동이 제한되고 터널이 가장 먼저 영향을 받습니다. 끄고 한 번 더 테스트하세요. 가장 놓치기 쉬운 항목입니다.

백그라운드 앱 새로 고침. 꺼 두면 앱이 백그라운드에서 연결을 유지할 수 없습니다. 시스템 설정에서 이 클라이언트만 따로 켜 주세요.

필요 시 연결. 켜 두면 네트워크가 필요할 때 시스템이 터널을 자동으로 올립니다. 직접 연결 버튼을 누를 필요가 없어 모바일에서 가장 편한 스위치입니다.

네트워크 전환. Wi-Fi 신호가 약하면 시스템이 모바일 네트워크로 넘어가고, 전환 과정에서 터널이 재구성됩니다. 특정 방에 들어갈 때마다 끊긴다면 이 증상입니다. 한쪽 네트워크만 고정해 대조하면 확인됩니다.

Android

배터리 최적화. 시스템은 자주 쓰지 않는 앱을 제한 상태로 넣고 백그라운드 네트워크를 끊습니다. 클라이언트를 배터리 최적화 예외 목록에 넣고 백그라운드 활동을 허용하세요.

자동 시작 권한. 일부 커스텀 시스템은 기본적으로 앱 자동 시작을 막아서, 재부팅 후 연결이 자동 복구되지 않습니다. 앱 관리에서 따로 허용하세요.

최근 작업 목록에서 밀어 지우기. 많은 시스템이 그 앱의 터널까지 함께 종료합니다. 백그라운드 상주가 필요하면 멀티태스킹 화면에서 해당 앱을 고정하세요.

공통 점검 목록

1. 시스템의 해당 앱 절전 최적화 끄기

   스마트 절전, 딥 슬립, 백그라운드 제한 같은 항목을 하나씩 확인하세요.

2. 백그라운드 데이터와 백그라운드 활동 허용

   시스템의 데이터 절약 모드도 백그라운드 연결을 끊으므로 따로 허용해야 합니다.

3. 듀얼 SIM 기기는 데이터 유심 고정

   유심 두 장을 오가면 터널이 반복 재구성됩니다. 하나를 데이터 유심으로 고정하면 신호도 더 안정적입니다.

4. 다른 기기로 대조

   같은 네트워크에서 다른 기기는 끊기지 않는다면, 라인이 아니라 이 기기의 시스템 정책일 가능성이 큽니다.

절전 문제가 아닌 경우

잠금을 풀어 둔 상태에서도 자주 끊긴다면 5장으로 돌아가 시간 규칙을 보세요. Wi-Fi를 바꿀 때만 끊긴다면 로밍입니다. 특정 앱이 전면으로 올라올 때만 끊긴다면 그 앱이 네트워크를 선점하거나 DNS를 바꾼 것입니다. 연결 아이콘은 계속 있는데 백그라운드 다운로드가 멈춘다면 터널이 끊긴 것이 아니라 시스템이 백그라운드 데이터를 제한한 것입니다.

이 네 가지를 구분하면 시스템 설정을 반복해서 만지면서도 효과를 못 보는 일을 피할 수 있습니다. 모바일 절전 정책은 버전마다 바뀌므로, 시스템 메이저 업데이트 후 새로운 끊김 규칙이 나타나면 이 장으로 돌아와 목록을 다시 훑는 것이 우선입니다.

DNS 이상: ping은 통하는데 도메인 확인이 안 될 때

DNS는 도메인을 IP 주소로 바꾸는 역할을 합니다. 여기에 문제가 생기면 증상이 인터넷 단절과 비슷합니다. 브라우저는 서버를 찾을 수 없다고 하고, IP를 직접 ping하면 통합니다. 판단은 간단합니다. IP를 먼저 ping하고 도메인을 ping해 두 결과를 비교하면 됩니다.

ping -c 4 1.1.1.1
nslookup example.com
nslookup example.com 8.8.8.8

첫 번째는 통하고 두 번째가 실패하면 로컬 DNS 문제, 둘 다 통하는데 세 번째가 실패하면 로컬 DNS가 바뀌었거나 잘못된 결과가 캐시된 것입니다. 셋 다 실패하면 네트워크 자체가 없을 수 있으니 2장으로 돌아가세요. Windows에서는 ping -c 4를 ping -n 4로 바꾸면 됩니다.

흔한 증상 대응표

캐시 한 번 비우기

설정을 바꾼 뒤에는 먼저 캐시를 비우세요. 그렇지 않으면 오래된 확인 결과가 한동안 계속 적용됩니다. 플랫폼별 명령은 다음과 같습니다:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux(systemd-resolved)
sudo resolvectl flush-caches

모바일에는 명령줄이 없으므로 비행기 모드를 한 번 껐다 켜면 시스템이 확인을 다시 시작합니다.

왜 새는가

여러 네트워크 서비스. 시스템에 유선, Wi-Fi, 가상 네트워크 인터페이스 등 여러 네트워크 서비스가 동시에 존재할 수 있고, 프록시는 그중 하나만 바꿨는데 확인 요청은 다른 쪽으로 나갑니다.

브라우저 자체 암호화 DNS. 브라우저가 자체적으로 암호화 확인 서버를 지정해 시스템 설정을 완전히 우회할 수 있습니다. 점검할 때는 먼저 이것을 끄세요.

분할 터널링 규칙이 DNS를 직접 연결로 판정. 규칙에 도메인 매칭만 쓰고 확인 요청 자체를 덮지 않으면 확인이 로컬로 나갑니다.

점검 순서 요약

터널 내부 확인이 켜져 있는지 먼저 확인하고, 캐시를 비우고, 브라우저와 시스템의 암호화 DNS를 끄고, 마지막으로 분할 터널링 규칙을 확인하세요. 네 단계를 마쳐도 확인이 실패한다면 nslookup 출력 두 개를 문의에 붙이는 편이 혼자 계속 추측하는 것보다 훨씬 빠릅니다.

C6VPN의 개인정보 보호 정책은 익명·무로그입니다. 열람 내용과 방문 대상을 기록하지 않습니다. DNS를 터널 안에서 확인하는 것도 이 정책의 일부이므로, 점검할 때도 요청을 로컬 통신사에 넘기기보다 터널로 보내는 쪽을 우선합니다.

다중 기기, 동시 접속, 문의 시점

이 장에서는 두 가지를 다룹니다. 여러 기기를 동시에 쓸 때의 양상, 그리고 언제 자가 점검을 멈추고 문의로 넘어가야 하는지입니다.

기기 수 제한 없음이 뜻하는 것

동시 접속 기기 수에 제한이 없어서 같은 계정으로 Windows, macOS, iOS, Android, Linux에서 동시에 로그인할 수 있고, 기기마다 따로 구매할 필요가 없습니다. 이 내용은 요금제 페이지에도 설명되어 있습니다.

다만 기기 수 제한이 없다고 해서 기기마다 대역폭을 독점하는 것은 아닙니다. 출구 대역폭은 공유되므로 여러 기기가 동시에 4K를 보거나 대용량 파일을 내려받으면 서로 자리를 뺏습니다. 판단은 간단합니다. 다른 기기를 끄고 다시 측정해 속도가 돌아오면 라인이 나빠진 것이 아니라 동시 사용 때문입니다.

공유기 단위 프록시는 또 다른 사용법입니다. 구독을 공유기에 넣으면 집 안 모든 기기가 하나의 출구를 공유합니다. 편하다는 장점이 있지만, 모든 기기가 같은 출구 IP를 쓰기 때문에 사이트의 위험 관리에 걸리면 함께 영향을 받고, 점검할 때 어느 기기 문제인지 가리기도 어렵습니다. 먼저 단일 기기 방식으로 라인이 쓸 만한지 확인한 뒤 공유기 도입을 결정하세요.

기기 수가 상한에 도달했다는 안내에 대하여

이 사이트의 계정에는 기기 수 제한이 없습니다. 클라이언트에 그런 안내가 뜬다면 어디서 나온 것인지 먼저 보세요. 대부분은 같은 기기에 클라이언트 두 개가 설치되어 같은 로컬 포트를 다투거나, 공유기 플러그인이 동시 연결 수를 제한한 경우입니다. 처리 방법은 남는 클라이언트를 종료하고, 공유기 플러그인의 동시 연결 설정을 확인하고, 패널에 다시 로그인해 구독을 복사하는 것입니다.

언제 문의해야 하는가

아래 다섯 가지 중 두 가지 이상 해당하면 계속 시도하기보다 문의로 넘어갈 만합니다:

• 서로 다른 지역·서로 다른 라인 유형의 라인 세 개가 모두 연결되지 않음
• 서로 다른 네트워크 두 곳(가정용 회선과 모바일 네트워크)에서 똑같이 실패
• 시스템 시간이 맞춰져 있고 다른 프록시류 프로그램이 모두 종료됨
• 구독 링크가 브라우저에서는 열리는데 클라이언트에서 갱신 실패
• 같은 라인이 다른 기기에서는 정상인데 이 기기에서는 계속 실패

문의에 붙일 것

붙이지 말 것

계정 비밀번호, 전체 구독 링크, 결제 증빙 스크린샷, 신분증. 이런 정보는 문제 파악에 도움이 되지 않고 노출 위험만 키웁니다. 구독 링크를 보여야 할 때는 토큰 부분을 지우세요.

접수 경로와 이후

문의는 사용자 패널 안에서 접수합니다. 로그인 후 문의 페이지로 들어가면 됩니다. 접수 전에 사용 안내를 한 번 보세요. 일부 문제는 안내에 이미 답이 있습니다. 문의 및 지원 페이지에서 현재 사용 가능한 연락 방법을 확인할 수도 있습니다.

점검 끝에 서비스가 기대에 맞지 않는다고 판단되면 30일 무조건 환불을 패널 안에서 신청할 수 있습니다. 가입 자체에 이메일 주소가 필요 없고 아이디와 비밀번호만으로 완료되며, 이 점은 환불 절차에서도 같습니다. 이메일을 찾지 못해 막히는 일은 없습니다.