처음 가속 서비스를 사용할 때 진짜 헷갈리는 부분은 “연결” 버튼의 위치보다 멀티 디바이스, 트래픽 계산, 회선 선택, 프로토콜과 분할 라우팅 규칙의 관계입니다. 계정 권한, 클라이언트 설정, 네트워크 경로를 처음부터 구분하지 않으면 웹페이지가 열리지 않거나 속도가 흔들릴 때 소프트웨어를 반복 설치하고 구독을 다시 가져오게 되어 오히려 문제 해결이 어려워집니다.
아래에서는 실제 사용 순서에 따라 초보자가 가장 많이 묻는 10가지 질문에 답합니다. 먼저 기억할 점은 가속 서비스가 모든 네트워크 요청을 일괄적으로 빠르게 만드는 스위치가 아니라, 출구와 전송 프로토콜, 전달 경로를 선택하는 네트워크 도구라는 것입니다. 연결 결과는 서비스 회선뿐 아니라 현지 네트워크, 대상 웹사이트, 클라이언트 규칙과 기기 운영체제에도 좌우됩니다.
멀티 디바이스, 트래픽과 속도 제한 이해하기
질문 1: 여러 기기에서 동시에 사용할 수 있나요?
여러 기기에 설치할 수 있는지와 여러 기기를 동시에 연결할 수 있는지는 별개의 문제입니다. 대부분의 클라이언트는 컴퓨터, 태블릿 등 지원되는 플랫폼에 각각 설치할 수 있지만, 동시 연결 기준은 현재 요금제와 서비스 안내를 따라야 합니다. 온라인 연결 수를 제한하는 경우도 있고 계정 동시 접속 수를 제한하는 경우도 있으며, 라우터 연결을 별도 세션으로 계산하기도 합니다.
같은 계정을 여러 기기에서 사용한다면 먼저 주 기기에서 연결을 테스트한 뒤 기기별로 가져오는 것이 좋습니다. 문제가 생겼을 때 특정 기기의 시스템 설정 때문인지 계정 동시 접속 규칙 때문인지 구분하기 쉽습니다. 하나의 구독 링크를 다른 사람에게 함부로 전달하지 마세요. 구독에는 보통 접속 설정에 필요한 정보가 포함되므로 계정 비밀번호가 보이지 않더라도 민감한 인증 정보로 다뤄야 합니다.
질문 2: 트래픽은 어떤 기준으로 계산되나요?
트래픽은 일반적으로 프록시 터널을 통과한 데이터와 관련되며, 업로드와 다운로드를 모두 포함하는 경우가 많습니다. 최종 기준은 서비스 관리 화면의 트래픽 안내를 따라야 합니다. 동영상 시청, 클라우드 드라이브 동기화, 시스템 이미지 다운로드, 클라우드 백업은 일반적인 텍스트 웹페이지보다 트래픽을 훨씬 많이 사용할 수 있습니다. 영상 화질, 자동 재생, 백그라운드 동기화도 사용량을 크게 바꿉니다.
브라우저에 표시되는 파일 크기가 관리 화면에 기록되는 최종 데이터량과 항상 같은 것은 아닙니다. 전송 프로토콜에는 캡슐화 오버헤드가 있고, 웹페이지는 이미지, 스크립트, 글꼴과 미디어 조각을 함께 불러올 수 있습니다. 연결 실패 후 재시도, 앱의 백그라운드 새로고침, 속도 측정도 트래픽을 만들 수 있습니다. 사용량이 비정상적으로 보인다면 현재 보고 있는 페이지만 확인하지 말고 어떤 앱의 요청이 프록시를 통과하는지 먼저 살펴보세요.
질문 3: 연결 후 속도 제한이 걸리나요?
속도 저하가 반드시 서버 측 속도 제한을 뜻하는 것은 아닙니다. 현지 무선 네트워크, 통신사 출구, 지역 간 회선, 노드 부하, 대상 웹사이트의 접속 지점, 기기 성능 등 네트워크 경로의 어느 구간이든 병목이 될 수 있습니다. 프로토콜 암호화와 데이터 전달에도 추가 처리가 필요하므로 연결 후 속도를 현지 속도 측정의 최고치와 단순 비교해서는 안 됩니다.
| 관찰된 현상 | 가능성이 높은 원인 | 우선 확인할 방법 |
|---|---|---|
| 모든 회선이 느림 | 현지 네트워크, 기기 성능 또는 클라이언트 모드 | 백그라운드 다운로드를 끄고 현지 네트워크를 바꾼 뒤 전체 프록시가 잘못 켜져 있지 않은지 확인 |
| 특정 지역만 느림 | 해당 지역까지의 경로 품질 또는 대상 서비스의 접속 지점 | 같은 지역의 다른 회선으로 바꾼 뒤 시간대별 결과를 비교 |
| 웹페이지는 정상인데 동영상이 버퍼링됨 | 미디어에 더 높은 대역폭이 필요하거나 플랫폼이 다른 도메인을 사용함 | 미디어 도메인이 프록시 규칙에 포함되는지 확인하고 플랫폼과 가까운 출구로 변경 |
| 처음에는 정상 연결되다가 불안정해짐 | 무선 간섭, 네트워크 전환 또는 세션 재연결 | 현재 네트워크를 고정하고 자동 전환을 끈 뒤 연결을 다시 설정 |
문제를 확인할 때 프로토콜, 회선, 클라이언트와 현지 네트워크를 동시에 바꾸지 마세요. 한 번에 하나의 변수만 바꾸고 웹페이지 로딩, 동영상 재생 시작, 지속 전송 상태를 기록해야 어떤 조정이 실제로 효과가 있었는지 알 수 있습니다.
상시 연결과 기기 변경 처리 방법
질문 4: 가속 서비스를 계속 켜 두어야 하나요?
반드시 그럴 필요는 없습니다. 상시 연결 여부는 사용 목적과 분할 라우팅 방식에 따라 달라집니다. 특정 국제 서비스에 접속할 때만 가속이 필요하다면 규칙 모드를 사용해 해당 도메인이나 앱만 프록시로 보내고 나머지는 현지 네트워크로 직접 연결할 수 있습니다. 일반적인 사용 방식에 더 잘 맞고, 현지 서비스가 원격 출구로 우회하는 것도 피할 수 있습니다.
전체 모드에서는 더 많은 네트워크 요청이 프록시를 통과하므로 규칙 누락 여부를 임시로 진단하거나 도메인 규칙으로 특정 앱을 정확히 식별하기 어려울 때 유용합니다. 하지만 모든 문제의 기본 해결책으로 전체 모드를 사용하는 것은 권장하지 않습니다. 은행, 공공 서비스, 로컬 네트워크 기기와 현지 콘텐츠 서비스는 직접 연결이 더 적합할 수 있습니다. 모든 요청을 우회하면 로그인 위치가 바뀌거나 페이지 로딩이 느려지고 로컬 네트워크 기기가 검색되지 않을 수 있습니다.
모바일 기기에서는 운영체제의 백그라운드 정책도 고려해야 합니다. 화면 잠금, 절전 모드, Wi-Fi와 모바일 네트워크 전환으로 연결이 일시 중지되거나 다시 만들어질 수 있습니다. 클라이언트가 계속 실행 중으로 보여도 기존 세션이 계속 유지된다는 뜻은 아닙니다. 백그라운드에서 앱을 다시 열었을 때 네트워크가 되지 않는다면 모든 설정을 바로 삭제하기보다 먼저 연결을 끊었다가 다시 연결해 보세요.
질문 5: 기기를 바꾸면 다시 구매해야 하나요?
기기를 바꿀 때는 보통 새 클라이언트를 설치하고 계정 설정을 가져오는 것이 먼저이며, 곧바로 다시 구매해야 한다고 결론 내릴 필요는 없습니다. 서비스 권한은 일반적으로 계정이나 요금제 상태와 연결되고, 기기는 접속 수단에 해당합니다. 기존 기기를 동시에 계속 사용할 수 있는지는 요금제의 동시 접속 규칙을 확인해야 합니다.
이전할 때 클라이언트 내부 데이터베이스나 출처가 불분명한 설정 폴더를 복사하지 마세요. 공식 경로에서 새 시스템에 맞는 클라이언트를 받고 새 기기에서 구독을 다시 가져온 뒤 회선 목록과 연결 상태를 확인하는 편이 안전합니다. 기존 기기를 더 이상 사용하지 않는다면 구독과 로컬 설정을 삭제하세요. 관리 화면에서 세션을 관리할 수 있다면 필요하지 않은 연결을 확인하고 종료할 수도 있습니다.
- 새 기기에 시스템에 맞는 클라이언트를 설치합니다.
- 채팅 기록에 남은 예전 사본에 의존하지 말고 계정 관리 화면에서 구독을 다시 가져옵니다.
- 가져온 뒤 자주 사용하는 지역의 회선 하나를 선택해 기본 연결을 먼저 테스트합니다.
- 웹페이지, 대상 앱과 DNS 확인이 정상인지 확인한 뒤 자동 업데이트와 분할 라우팅을 설정합니다.
- 기존 기기에 남은 구독 정보를 정리하고 현재 연결 권한을 확인합니다.
프로토콜 선택과 구독 가져오기
질문 6: Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC 중 무엇을 선택해야 하나요?
이 이름들은 서로 다른 프록시 프로토콜이나 전송 방식을 뜻하며, 단순한 속도 순위가 아닙니다. Shadowsocks는 구조가 비교적 단순하고 호환되는 클라이언트가 많습니다. VMess와 VLESS는 유연한 전송 설정을 지원하는 클라이언트에서 흔히 사용되며, VLESS 자체는 간결한 인증에 중점을 둡니다. 보안성은 함께 사용하는 전송 및 암호화 계층에도 달려 있습니다. Trojan은 보통 TLS와 함께 사용해 표준 암호화 세션과 유사한 형태의 전송을 구성합니다.
Hysteria2와 TUIC는 QUIC 계열의 전송 설계를 기반으로 하며 지연 시간이 길거나 패킷 손실이 있을 때의 연결 성능을 중시합니다. 다만 UDP 사용 가능 여부에 영향을 받습니다. 현재 네트워크가 UDP를 제한하거나 라우터와 보안 정책이 QUIC을 제대로 처리하지 못하면 핸드셰이크 실패, 속도 불안정 또는 연결 불가가 발생할 수 있습니다. 이때는 매개변수를 계속 조정하기보다 TCP와 TLS 기반의 사용 가능한 방식으로 바꾸는 편이 효과적입니다.
초보자가 가장 최신의 프로토콜 이름을 좇을 필요는 없습니다. 서비스에서 명확히 제공하고 클라이언트가 완전히 지원하는 설정을 우선 사용한 뒤 현재 네트워크에서의 안정성을 확인하세요. 프로토콜은 양쪽이 호환되어야 하며, 클라이언트에서 이름 하나만 수동으로 바꾼다고 변환이 완료되지 않습니다. 포트, 인증, 전송 계층, TLS와 서버 설정도 서로 일치해야 합니다.
질문 7: 구독 링크란 무엇이며 어떻게 가져오나요?
구독 링크는 클라이언트가 노드 목록과 관련 설정을 가져오는 경로입니다. 일반 브라우저로 읽는 보통의 웹페이지가 아니며 단일 노드와도 다릅니다. 호환되는 클라이언트에 구독 링크를 가져오면 회선 이름, 서버 주소, 포트, 프로토콜과 기타 필요한 매개변수를 해석합니다. 이후 구독을 업데이트해야 클라이언트가 서버에서 변경된 설정을 동기화할 수 있습니다.
클라이언트에 따라 메뉴 이름이 “구독 추가”, “URL에서 가져오기”, “원격 설정” 또는 “구독 관리”로 표시될 수 있습니다. 기본 흐름은 같습니다. 전체 링크를 복사해 구독 입력란에 붙여넣고 저장한 다음 업데이트한 뒤 노드 목록에서 회선을 선택합니다. 구독 텍스트를 단일 노드 링크로 가져오거나 단일 노드 링크를 구독 업데이트 메뉴에 넣으면 형식 오류가 표시될 수 있습니다.
계정 관리 화면에서 구독 가져오기
→ 클라이언트에서 원격 구독 추가
→ 회선 목록 업데이트
→ 대상 지역 선택
→ 연결 설정
→ 분할 라우팅 및 DNS 확인- ✅ 서비스 계정 관리 화면에서 구독을 복사하고 링크 앞뒤에 불필요한 공백이 없는지 확인합니다.
- ✅ 해당 프로토콜을 명확히 지원하는 클라이언트를 사용하고 이름만으로 호환성을 추측하지 않습니다.
- ✅ 가져온 뒤 한 번 수동으로 업데이트하고 회선 목록이 완전한지 확인합니다.
- ✅ 네트워크 환경이 바뀔 때 전환할 수 있도록 검증된 예비 프로토콜을 하나 남겨 둡니다.
- ❌ 구독 링크를 공개 속도 측정 사이트, 포럼 또는 공유 문서에 붙여 넣지 않습니다.
- ❌ 동일한 구독을 여러 개 중복으로 가져오지 않습니다. 회선이 중복되어 문제를 확인하기 어려워질 수 있습니다.
회선 유형과 지역 선택 방법
질문 8: 직접 연결, 중계와 IEPL 전용 회선은 어떻게 다른가요?
직접 연결은 기기가 기존 인터넷 경로를 통해 원격 노드에 바로 연결하는 방식입니다. 경로가 단순하지만 현지 통신사에서 대상 지역까지의 공용 인터넷 라우팅에 영향을 많이 받습니다. 중계는 더 가깝거나 도달하기 쉬운 진입점에 먼저 연결한 다음 중간 경로를 거쳐 최종 출구로 전달합니다. 일부 지역 간 경로의 불안정성을 개선하는 데 사용할 수 있지만, 진입점과 중계 경로, 출구 모두 최종 결과에 영향을 주므로 중계가 항상 더 빠른 것은 아닙니다.
IEPL은 일반적으로 국제 이더넷 전용 회선 계열의 연결을 가리키며, 특정 네트워크 종단점 사이에 더 제어 가능한 전송 경로를 제공하는 데 사용됩니다. 일반 공용 인터넷 직접 연결과의 핵심 차이는 노드 이름에 “전용 회선”이라는 표현이 있는지가 아니라 전송 방식과 경로 관리에 있습니다. 특정 장소나 시간대에 항상 더 빠르다고 보장할 수는 없습니다. 진입점까지의 현지 네트워크, 진입점 위치와 대상 서비스의 상태도 이용 경험에 영향을 줍니다.
| 회선 유형 | 경로 특성 | 우선 시도하기 좋은 상황 | 주의할 점 |
|---|---|---|---|
| 직접 연결 | 공용 인터넷을 통해 원격 노드로 직접 연결 | 현지에서 대상 지역까지의 라우팅이 안정적이고 요구 사항이 단순한 경우 | 저녁 시간대 혼잡과 지역 간 라우팅 변화가 더 뚜렷할 수 있음 |
| 중계 | 진입점에 먼저 연결한 뒤 출구로 전달 | 직접 연결 경로의 우회가 많거나 변동이 큰 경우 | 진입점 품질과 중계 경로도 똑같이 중요함 |
| IEPL 전용 회선 | 종단점 사이에 더 제어 가능한 전용 회선으로 전달 | 지속적인 전송과 경로 안정성을 중시하는 작업 | 현지 접속 구간과 대상 플랫폼이 여전히 병목이 될 수 있음 |
지역은 지리적으로 가장 가까운 노드를 기계적으로 고르기보다 대상 서비스를 기준으로 선택해야 합니다. 특정 지역의 콘텐츠 플랫폼에 접속할 때는 기기에서 노드까지의 직선거리보다 출구 지역이 플랫폼 요구 사항에 맞는지가 더 중요합니다. 일반적인 웹 검색이라면 가까우면서 안정적인 진입점을 먼저 시도할 수 있습니다. 대상 앱이 여러 지역의 API를 동시에 호출한다면 규칙 모드에서도 관련 도메인이 같은 출구를 사용하도록 해야 로그인 상태나 지역 판정이 달라지는 문제를 피할 수 있습니다.
DNS 누출, 분할 라우팅과 플랫폼 차이
질문 9: DNS 누출이란 무엇이며 분할 라우팅 규칙은 왜 작동하지 않나요?
DNS는 도메인 이름을 연결 가능한 주소로 변환합니다. DNS 누출은 일반적으로 프록시 측에서 처리하기를 기대한 요청이 여전히 현지 네트워크의 리졸버를 통해 처리되는 상황을 말합니다. 이 경우 DNS 결과의 지역과 프록시 출구 지역이 일치하지 않을 수 있고 일부 도메인이 현지 DNS 경로에 직접 노출될 수도 있습니다. 모든 트래픽이 프록시를 우회한다는 뜻은 아니지만 지역 판정, 접속 결과와 개인정보 보호 범위에 영향을 줄 수 있습니다.
흔한 원인으로는 운영체제에 별도의 암호화 DNS가 켜져 있거나, 브라우저가 자체 보안 DNS를 사용하거나, 클라이언트가 연결만 인계하고 DNS는 처리하지 않거나, 분할 라우팅 규칙이 경로를 결정하기 전에 DNS를 조회하는 경우가 있습니다. 일부 앱은 이전 주소를 캐시하므로 회선을 바꾼 뒤에도 기존 대상에 연결할 수 있습니다. 먼저 클라이언트의 DNS 모드를 확인하고 시스템과 브라우저에 중복 설정이 있는지 점검한 다음 캐시를 삭제하고 연결을 다시 설정하세요.
분할 라우팅 규칙이 작동하지 않는다고 해서 규칙 파일 자체가 잘못된 것은 아닙니다. 앱이 IP로 직접 연결하거나 QUIC, 내장 DNS 또는 계속 바뀌는 콘텐츠 전송 도메인을 사용할 수 있습니다. 메인 사이트 도메인만 추가하면 로그인 API, 이미지 도메인, 동영상 조각과 인증 서비스를 모두 포함하지 못할 수 있습니다. 전체 모드에서는 접속되지만 규칙 모드에서 실패한다면 규칙 적용 범위, DNS 경로 또는 앱 식별 방식을 확인해야 한다는 뜻일 가능성이 큽니다.
질문 10: Windows, Apple, Android, Linux 클라이언트는 어떻게 다른가요?
데스크톱과 모바일 운영체제는 프록시를 인계받는 방식이 다릅니다. Windows 클라이언트는 시스템 프록시나 가상 네트워크 어댑터를 통해 트래픽을 처리할 수 있습니다. 시스템 프록시만 설정하면 이를 따르지 않는 앱은 가속 회선을 사용하지 않을 수 있습니다. 가상 네트워크 어댑터 모드는 더 많은 프로그램을 적용할 수 있지만 라우팅, DNS와 현지 네트워크 접근도 올바르게 설정해야 합니다.
Apple 플랫폼은 보통 운영체제가 제공하는 네트워크 확장을 통해 연결하며, 관련 네트워크 상태를 시스템에 명확히 표시합니다. 백그라운드 유지, 필요 시 연결과 로컬 네트워크 권한이 실제 사용 경험에 영향을 줍니다. Android 기기는 시스템 VPN 인터페이스로 앱 트래픽을 처리하고 앱별 분할 라우팅을 제공하는 경우가 많습니다. 운영체제의 절전 정책이 클라이언트를 종료하면 연결이 다시 만들어집니다. Linux 클라이언트는 그래픽 인터페이스를 제공할 수도 있고 명령줄, 시스템 프록시 또는 투명 프록시 방식으로 실행될 수도 있어 차이가 더 큽니다. 특히 권한과 라우팅 설정이 중요합니다.
“같은 회선이 다른 기기에서는 정상 작동한다”는 사실은 서버와 회선에 연결할 가능성이 높다는 뜻일 뿐, 현재 기기의 설정이 올바르다는 증거는 아닙니다. 두 기기가 같은 프로토콜, 같은 출구, 같은 DNS 모드와 같은 분할 라우팅 정책을 사용하는지 비교해야 합니다.
- 현지 네트워크 자체에서 자주 이용하는 웹사이트에 정상적으로 접속할 수 있는지 확인합니다.
- 구독을 업데이트하고 이전에 검증한 회선을 선택합니다.
- 복잡한 분할 라우팅을 일시적으로 끄고 더 단순한 연결 모드로 기본 연결 가능 여부를 확인합니다.
- 시스템 시간, DNS 설정, 프록시 권한과 백그라운드 제한을 확인합니다.
- 같은 지역의 다른 회선이나 호환되는 프로토콜로 바꾸되, 매번 한 가지 항목만 변경합니다.
- 해결되지 않으면 운영체제, 클라이언트, 회선과 오류 메시지를 정리한 뒤 지원팀에 문의합니다.
문제 정보를 보낼 때 “연결할 수 없음”이라고만 쓰지 마세요. 사용 플랫폼, 클라이언트 이름, 프로토콜 유형, 회선 지역, 연결 단계와 접속 단계 중 언제 문제가 발생했는지, 현지 네트워크를 바꾼 뒤 달라졌는지가 더 유용합니다. 일부를 가린 오류 메시지는 제공할 수 있지만 전체 구독 링크, 비밀번호와 기타 계정 인증 정보는 보내지 마세요.
서비스 시작 전후에 지켜야 할 사용 습관
첫 연결을 완료한 뒤 현재 이용 가능한 클라이언트 출처, 구독을 가져오는 경로와 자주 사용하는 회선 유형을 안전한 개인 기록에 남겨 두는 것이 좋습니다. 단, 공개적으로 접근할 수 있는 공유 링크는 저장하지 마세요. 이메일 주소 없이 시작할 수 있더라도 사용자 이름과 비밀번호는 안전하게 보관해야 합니다. 계정 인증 정보를 잃어버리면 이후 기기 이전과 구독 관리에 영향을 줍니다.
네트워크 유지보수에 따라 회선 이름, 프로토콜 설정과 구독 내용이 바뀔 수 있으므로 수동으로 복사한 단일 노드에 장기간 의존하지 말고 클라이언트의 구독 업데이트 기능을 사용하세요. 중요한 작업이 있다면 업데이트 전에 현재 사용 가능한 연결을 유지해 전송 중 설정이 바뀌는 일을 피하는 것이 좋습니다. 업데이트 후 노드가 중복되면 회선을 하나씩 삭제하기보다 같은 구독을 여러 번 추가했는지 확인하세요.
마지막으로 가속 서비스를 선택할 때는 대상 지역에 적합한 회선이 있는지, 현재 사용하는 플랫폼을 지원하는 클라이언트인지, 요금제의 트래픽 기준이 명확한지, 문제가 생겼을 때 구체적인 설정 지원을 받을 수 있는지를 중점적으로 확인하세요. 프로토콜 수가 많고 노드 이름이 복잡하다고 해서 실제 경로가 반드시 더 적합한 것은 아닙니다. 자신의 접속, 학습, 협업이나 미디어 이용을 안정적으로 완료할 수 있는지가 설정이 올바른지 판단하는 핵심 기준입니다.