구독, 노드, 프로토콜이 무엇인지 이해하는 것은 많은 초보자가 클라이언트를 처음 설정한 뒤 마주하는 질문입니다. 간단히 말하면 구독은 클라이언트에 설정을 전달하고, 노드는 선택 가능한 연결 진입점이며, 프로토콜은 클라이언트와 서버가 통신하는 방식을 정합니다. 회선, 분할 라우팅과 실행 모드는 데이터가 어디를 거치고 어떤 앱이 연결을 사용할지를 결정합니다. 모두 하나의 연결 흐름에 속하지만 서로 바꿔 부를 수 있는 명칭은 아닙니다.
이 용어들은 정의를 외우기보다 실제 사용 순서대로 살펴보는 것이 가장 쉽습니다. 먼저 구독 링크를 받아 호환 클라이언트에 가져옵니다. 클라이언트가 노드를 해석하면 노드를 선택하고 해당 프로토콜로 연결을 수립합니다. 연결 후에는 전체 모드나 분할 라우팅 규칙이 어떤 요청을 연결로 보낼지 판단합니다. 마지막으로 DNS 설정은 도메인을 주소로 변환하므로 분할 라우팅 정책과 일치해야 합니다.
구독 링크에는 무엇이 들어 있을까
구독 링크는 보통 서버에서 생성되어 클라이언트가 읽는 주소입니다. 클라이언트가 해당 주소에 접속하면 인코딩되었거나 구조화된 설정 묶음을 가져옵니다. 설정에는 서버 주소, 포트, 프로토콜 유형, 인증 정보, 노드 이름과 업데이트 정보가 포함될 수 있습니다. 사용자가 보는 것은 하나의 링크지만 클라이언트는 이를 노드 목록으로 변환할 수 있는 데이터로 인식합니다.
따라서 ‘구독 구매’와 ‘구독 가져오기’는 서로 다른 작업입니다. 전자는 서비스 이용 권한을 얻는 것이고, 후자는 이미 가진 설정을 클라이언트에 추가하는 일입니다. 가져오기에 성공했다고 해서 회선 연결까지 완료된 것은 아닙니다. 이는 클라이언트가 설정을 읽고 해석할 수 있다는 뜻일 뿐입니다. 노드를 선택하고 연결을 시작한 뒤 대상 앱이 예상대로 프록시나 터널을 사용하는지 확인해야 합니다.
구독 링크는 민감한 인증 정보처럼 취급해야 합니다. 링크를 가진 사람은 대개 그 안의 노드 설정을 읽을 수 있으므로 공개 게시물, 스크린샷 또는 공유 문서에 올리지 않는 것이 좋습니다. 문제를 확인할 때는 클라이언트 오류 문구를 공유하되 전체 링크, 인증 필드와 서버 설정은 가려야 합니다. 링크 유출이 의심되면 로컬 클라이언트에서 기록만 삭제하지 말고 서비스 관리 화면에서 인증 정보를 갱신해야 합니다.
가져오기, 업데이트와 로컬 설정의 차이
‘가져오기’는 구독을 처음 읽는 작업이고, ‘업데이트’는 원래 주소에서 최신 설정을 다시 가져오는 작업입니다. ‘로컬 설정’은 현재 기기에만 저장됩니다. 구독을 업데이트하면 노드가 추가·삭제되거나 조정될 수 있으며, 같은 이름의 항목 일부 필드가 덮어써질 수도 있습니다. 구독에서 생성된 노드를 직접 수정하면 다음 업데이트 때 변경 내용이 사라지는 경우가 많습니다. 오래 유지할 사용자 지정 규칙은 클라이언트가 지원하는 오버라이드, 규칙 세트 또는 별도 설정 영역에 저장하는 편이 좋습니다.
- 서비스 관리 화면에서 전체 구독 링크를 복사하고, 링크의 문자를 직접 삭제하거나 수정하지 마세요.
- 호환 클라이언트에서 ‘URL에서 가져오기’ 또는 이와 비슷한 메뉴를 선택하세요.
- 가져오기가 끝나면 먼저 한 번 업데이트해 클라이언트가 설정을 정상적으로 가져오는지 확인하세요.
- 노드를 하나 선택해 연결을 시작한 다음 실제 앱으로 접속 결과를 확인하세요.
- 이후 노드 목록이 바뀌면 먼저 구독을 업데이트한 뒤 연결 장애인지 판단하세요.
노드, 서버와 회선은 어떻게 다를까
노드는 클라이언트에서 선택할 수 있는 설정 항목입니다. 보통 특정 서버 진입점을 가리키며 프로토콜, 포트, 인증 정보와 표시 이름이 함께 포함됩니다. 같은 서버가 여러 프로토콜이나 진입점을 제공할 수 있으므로 클라이언트에 표시되는 여러 노드가 같은 수의 물리적 장비를 의미하는 것은 아닙니다. 반대로 같은 지역의 노드가 서로 다른 서버에서 운영될 수도 있습니다.
서버는 네트워크 서비스를 실행하는 컴퓨팅 자원이고, 노드는 사용자가 연결할 수 있는 설정 진입점입니다. 회선은 로컬 네트워크에서 대상 네트워크까지 데이터가 이동하는 경로를 뜻합니다. 노드 이름에 특정 지역이 포함되어 있다면 일반적으로 출구나 주요 진입점이 해당 지역과 관련 있다는 의미지만, 이름만으로 전체 경로를 판단할 수는 없습니다. 실제 경로는 현지 통신사, 진입점 위치, 백본 전송과 대상 웹사이트의 네트워크 정책에 영향을 받습니다.
| 용어 | 주요 의미 | 사용자가 직접 확인할 수 있는 항목 | 흔한 오해 |
|---|---|---|---|
| 구독 | 클라이언트에 설정을 배포하고 업데이트 | 구독 이름, 업데이트 시간, 노드 목록 | 가져오기 성공을 연결 성공으로 착각 |
| 노드 | 선택 가능한 서버 진입점 설정 | 지역, 프로토콜, 이름과 상태 | 모든 노드가 서로 다른 물리 서버에 대응한다고 생각 |
| 서버 | 실제로 연결 서비스를 실행하는 컴퓨팅 자원 | 전체 하위 인프라 정보는 보통 표시되지 않음 | 서버가 있는 지역만으로 전체 경로를 판단 |
| 회선 | 로컬, 진입점, 백본과 출구 사이의 전송 경로 | 직접 연결, 중계 또는 전용 회선과 같은 서비스 측 태그 | 회선 태그를 고정된 속도와 동일시 |
직접 연결, 중계와 IEPL 전용 회선
직접 연결은 보통 로컬 네트워크가 해외 서버 진입점에 바로 연결되는 방식입니다. 구조가 단순하지만 사용 환경은 현지 통신사와 국제 출구 상태에 더 크게 좌우됩니다. 중계 방식은 먼저 가까우면서 현지 네트워크에 더 적합한 진입점에 연결한 뒤 대상 출구로 전달합니다. 일부 네트워크 환경에서는 경로 선택을 개선할 수 있지만, 전달 단계가 추가되는 만큼 서비스 측에서 진입점, 중계와 출구 사이를 조율하고 관리해야 합니다.
IEPL 전용 회선은 일반적으로 기업용 국제 이더넷 전용 회선 계열의 전송 방식을 뜻합니다. 개인 사용자 대상 서비스에서 이 태그는 대개 관리되는 특정 전송 경로 구간을 설명하기 위한 것이며, 사용자 기기에서 대상 웹사이트까지 모든 구간이 같은 전용 회선이라는 뜻은 아닙니다. 사용자 로컬 네트워크에서 접속 지점까지, 출구에서 대상 사이트까지는 일반 네트워크를 거칠 수 있으므로 ‘전용 회선’을 어느 장소와 시간대에도 동일한 성능을 보장하는 의미로 이해해서는 안 됩니다.
회선을 선택할 때 지역은 여러 조건 중 하나일 뿐입니다. 대상 서비스의 위치, 앱이 지연 시간과 지속 처리량 중 무엇을 더 중시하는지, 로컬 네트워크에서 UDP를 제한하는지, 현재 진입점이 혼잡한지에 따라 결과가 달라집니다. 안정적으로 선택하려면 먼저 대상 지역으로 범위를 좁힌 뒤 같은 사용 환경에서 이용 가능성을 비교하세요. 노드 이름의 수식어만 바라보는 방식은 피하는 것이 좋습니다.
프록시 프로토콜은 무엇을 결정할까
프로토콜은 클라이언트와 서버가 세션을 수립하고, 신원을 인증하고, 데이터를 캡슐화해 네트워크로 전송하는 방식을 정합니다. 노드 설정은 서버가 지원하는 프로토콜 및 매개변수와 일치해야 하므로 Trojan 노드를 수동으로 VLESS로 바꾼다고 해서 계속 작동하지는 않습니다. 프로토콜만으로 속도가 결정되는 것도 아닙니다. 회선 품질, 혼잡도, 기기 성능, 전송 계층 설정과 대상 사이트가 함께 사용 환경에 영향을 줍니다.
Shadowsocks, VMess, Trojan과 VLESS
Shadowsocks는 널리 사용되는 암호화 프록시 프로토콜로, 설정은 보통 서버, 포트, 비밀번호와 암호화 방식으로 구성됩니다. 구현이 성숙하고 지원 클라이언트도 많지만, 실제 보안성과 호환성은 선택한 암호화 방식과 클라이언트 구현에 따라 달라집니다. 자체적으로는 프록시 전송을 주로 담당하며 복잡한 분할 라우팅 관리 화면을 자동으로 제공하지는 않습니다.
VMess는 V2Ray 생태계에서 비교적 오래전부터 널리 사용된 프로토콜입니다. 인증과 전송 설정에는 사용자 식별자, 전송 방식과 시간 동기화 등이 영향을 줍니다. 기기 시간이 크게 어긋나면 일부 설정에서 인증 문제가 발생할 수 있습니다. VLESS는 더 가벼운 인증 구조를 사용하며 자체적으로 암호화를 담당하지 않습니다. 보통 TLS, REALITY 또는 다른 보안 전송 방식과 함께 사용합니다. VLESS라는 이름만 보지 말고 어떤 전송 계층과 보안 계층을 조합했는지 확인해야 합니다.
Trojan은 보통 TLS로 보호되는 연결 위에서 작동하며, 서버 이름, 인증서 검증, 비밀번호와 전송 설정이 주요 확인 항목입니다. 클라이언트에서 인증서 검증을 끄면 일부 설정 오류를 피할 수 있지만 서버 신원 확인이 약해지므로 일반적인 문제 해결 방법으로 사용해서는 안 됩니다. 시스템 시간, 서버 이름, 인증서 상태와 설정의 일치 여부를 확인하는 것이 올바른 접근입니다.
Hysteria2와 TUIC
Hysteria2와 TUIC는 모두 QUIC 및 UDP 전송을 중요한 기반으로 하며, 혼잡 제어, 다중화와 연결 마이그레이션 같은 기능을 함께 활용하도록 설계되었습니다. 패킷 손실이 많거나 변동이 큰 네트워크에서는 일부 TCP 기반 방식보다 적응력이 좋을 수 있지만, 로컬 네트워크에서 UDP를 안정적으로 사용할 수 있어야 합니다. 사내 네트워크, 공용 네트워크 또는 라우터 장비가 UDP를 엄격히 제한하면 연결이 실패하거나 성능이 저하될 수 있습니다. 이때는 관련 없는 매개변수를 반복해서 조정하기보다 서버에서 제공하는 다른 프로토콜로 전환하세요.
| 프로토콜 | 전송 특성 | 설정 시 중점 확인 항목 |
|---|---|---|
| Shadowsocks | 암호화 프록시, 폭넓은 클라이언트 지원 | 암호화 방식, 비밀번호와 포트가 일치하는지 |
| VMess | 다양한 하위 전송 조합 지원 | 사용자 식별자, 전송 매개변수와 시스템 시간 |
| Trojan | 보통 TLS와 함께 연결 수립 | 서버 이름, 인증서 검증과 비밀번호 |
| VLESS | 가벼운 인증, 보안 전송 계층과 함께 사용 | TLS 또는 REALITY 등 관련 매개변수 |
| Hysteria2 | QUIC 기반, 변동이 큰 네트워크에 대한 적응성 중시 | UDP 사용 가능 여부, 인증과 대역폭 매개변수 |
| TUIC | QUIC 기반, 다중화 지원 | UDP 사용 가능 여부, 혼잡 제어와 인증 설정 |
전체 모드, 규칙 모드와 분할 라우팅
연결이 수립된 뒤에도 클라이언트는 어떤 트래픽을 노드로 보낼지 결정해야 합니다. 전체 모드는 일반적으로 클라이언트가 제어할 수 있는 요청을 선택한 노드를 통해 최대한 일괄 처리합니다. 규칙 모드는 도메인, IP, 앱 또는 규칙 세트에 따라 프록시, 직접 연결 또는 차단을 선택합니다. 분할 라우팅은 바로 이 판단 과정입니다. 모든 트래픽을 먼 경로로 보내는 것이 아니라 요청마다 더 적합한 출구를 선택하는 것이 목적입니다.
규칙 모드에서는 요청이 먼저 로컬 네트워크 직접 연결 규칙과 일치한 다음 특정 도메인 규칙을 확인하고 마지막으로 기본 규칙에 도달할 수 있습니다. 규칙 순서는 중요합니다. 더 구체적인 규칙은 보통 더 넓은 규칙보다 앞에 배치해야 합니다. 넓은 직접 연결 규칙이 먼저 적용되면 뒤의 프록시 규칙은 실행되지 않습니다. 반대로 지나치게 넓은 프록시 규칙은 로컬 서비스, 프린터 또는 내부 시스템까지 불필요한 원격 경로로 보낼 수 있습니다.
시스템 프록시, TUN과 앱 내 프록시
시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 HTTP 또는 SOCKS 진입점을 제공합니다. 일부 앱은 이를 읽지만 다른 앱은 자체적으로 연결을 만들어 무시할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 IP 트래픽을 인계하므로 시스템 프록시를 읽지 않는 프로그램도 포함할 수 있습니다. 다만 방화벽, 가상 머신, 기업용 네트워크 소프트웨어 또는 다른 터널 도구와 라우팅 충돌이 발생하기도 쉽습니다.
앱 내 프록시는 특정 소프트웨어에만 프록시 주소와 포트를 입력하는 방식으로, 영향 범위가 가장 작고 문제를 확인하기도 쉽습니다. 초보자가 ‘브라우저는 접속되는데 다른 소프트웨어는 안 된다’는 상황을 겪는다면 노드가 고장 난 것이 아니라 브라우저만 시스템 프록시를 따르고 다른 소프트웨어는 따르지 않는 경우가 많습니다. 이때는 구독을 바로 삭제하지 말고 클라이언트 실행 모드를 확인해야 합니다.
- ✅ 브라우저만 국제 회선을 사용하면 된다면 시스템 프록시 또는 브라우저가 지원하는 프록시 설정을 우선 사용하세요.
- ✅ 시스템 프록시를 읽지 않는 데스크톱 프로그램까지 적용해야 할 때 TUN 모드 사용을 검토하세요.
- ✅ 규칙 모드를 사용할 때 로컬 네트워크, 자주 쓰는 중국 본토 서비스와 대상 국제 서비스가 각각 예상한 규칙과 일치하는지 확인하세요.
- ✅ 모드를 변경한 뒤 대상 앱을 다시 열어 이전 경로를 계속 사용하는 기존 연결을 피하세요.
- ❌ 시스템 트래픽을 동시에 인계하는 클라이언트를 여러 개 실행하지 마세요. 라우팅과 DNS 설정이 서로 덮어쓸 수 있습니다.
- ❌ ‘연결됨’ 아이콘만으로 모든 앱이 노드를 사용한다고 판단하지 마세요.
DNS 누수와 도메인 해석
앱이 도메인에 접속하려면 보통 먼저 DNS 조회로 해당 주소를 확인해야 합니다. DNS 누수란 원래 터널 내부나 지정한 리졸버가 처리해야 할 조회가 예상 경로를 벗어나 로컬 네트워크의 DNS로 전달되는 현상입니다. 이로 인해 조회 출처와 접속 출구가 일치하지 않거나, 로컬 해석 결과의 차이로 웹사이트 접속 실패, 지역 콘텐츠 판정 오류 또는 규칙 오적용이 발생할 수 있습니다.
DNS 문제는 분할 라우팅과 밀접하게 연결됩니다. 클라이언트가 도메인으로 경로를 결정하려면 연결 초기에 도메인 정보를 얻어야 합니다. 앱이 먼저 도메인을 IP로 변환하면 클라이언트는 IP 규칙으로만 판단할 수 있습니다. 일부 클라이언트는 Fake IP, 원격 해석 또는 암호화 DNS를 사용해 도메인과 연결의 대응 관계를 유지하지만 플랫폼과 코어에 따라 구현 방식은 완전히 같지 않습니다.
DNS를 확인할 때 ‘웹페이지가 열리는지’만 보지 마세요. 클라이언트가 DNS를 인계하는지, 규칙 모드에서 어떤 리졸버를 사용하는지, 시스템에 이전 수동 DNS가 남아 있는지, 브라우저가 별도의 보안 DNS를 활성화했는지, TUN 모드와 시스템 프록시 모드가 서로 다른 설정을 사용하는지 함께 확인해야 합니다. 브라우저의 독립적인 해석이 반드시 오류는 아니지만, 클라이언트가 설계한 도메인 분할 라우팅 흐름을 우회할 수 있습니다.
플랫폼별 클라이언트는 왜 설정이 다를까
Windows, macOS, Android, iOS와 Linux는 시스템 프록시, 가상 네트워크 인터페이스, 백그라운드 실행과 권한을 처리하는 방식이 서로 다릅니다. 따라서 같은 구독을 다른 클라이언트에 가져와도 화면과 사용 가능한 기능이 완전히 같지는 않습니다. 구독은 서버 설정을 제공하지만 규칙, DNS, TUN과 자동 업데이트를 구현하는 방식은 로컬 코어와 운영체제의 기능에 따라 달라집니다.
Windows 클라이언트는 시스템 프록시와 TUN을 함께 제공하는 경우가 많습니다. 전자는 설정이 간단하고 후자는 적용 범위가 넓지만, TUN을 활성화하려면 가상 네트워크 구성 요소를 설치하고 필요한 권한을 얻어야 할 수 있습니다. macOS도 시스템 프록시와 터널 방식을 지원하지만 네트워크 확장 권한, 시스템 방화벽과 다른 네트워크 확장이 인계 결과에 영향을 줄 수 있습니다.
Android 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 인계하며 앱별 분할 라우팅을 지원하기도 합니다. 시스템의 배터리 관리가 클라이언트의 백그라운드 활동을 제한하면 장시간 대기 후 연결이 일시 중지될 수 있습니다. iOS 클라이언트는 시스템 네트워크 확장 방식의 제약을 받으므로 기능 이름이 데스크톱과 다를 수 있고, 구독 업데이트와 백그라운드 연결 동작도 시스템 스케줄링의 영향을 더 많이 받습니다.
Linux의 차이는 데스크톱 환경, 네트워크 관리 도구와 실행 방식에서 더 많이 발생합니다. 명령줄 코어는 로컬 프록시 포트만 열어 주고, 시스템이 해당 포트를 자동으로 사용할지는 환경 변수, 데스크톱 프록시 또는 투명 전달을 별도로 설정해야 할 수 있습니다. 코어에 ‘실행 중’이라고 표시되어도 프로세스가 시작되었다는 뜻일 뿐 모든 프로그램의 트래픽이 이를 통과한다는 의미는 아닙니다.
초보자는 어떤 설정부터 확인해야 할까
- ✅ 클라이언트가 구독에 사용된 프로토콜과 전송 방식을 지원하는지 확인하세요.
- ✅ 구독 업데이트 시간이 정상인지, 노드 목록이 완전히 표시되는지 확인하세요.
- ✅ 현재 시스템 프록시, TUN과 앱 내 프록시 중 어떤 방식이 활성화되어 있는지 확인하세요.
- ✅ 규칙 모드의 기본 출구가 현재 사용 목적에 맞는지 확인하세요.
- ✅ DNS 설정이 분할 라우팅 모드와 맞는지, 브라우저에 별도의 해석 설정이 있는지 확인하세요.
- ✅ 시스템 시간이 정확한지 확인하세요. 인증서 검증과 시간 동기화가 필요한 인증은 모두 시스템 시간에 의존합니다.
- ❌ 출처가 불분명한 ‘최적화 매개변수’를 함부로 복사하지 마세요. 매개변수는 서버와 로컬 네트워크 환경에 맞아야 합니다.
연결 장애를 용어별로 단계적으로 확인하는 방법
용어를 실제로 이해하는 가치는 문제가 생겼을 때 어느 계층을 확인해야 하는지 아는 데 있습니다. 구독이 업데이트되지 않으면 링크 상태, 네트워크 접속과 클라이언트 해석 기능을 확인하세요. 구독은 업데이트되지만 모든 노드가 연결되지 않으면 프로토콜 지원, 인증 매개변수, 시스템 시간과 로컬 네트워크 제한을 확인해야 합니다. 일부 노드만 문제가 있다면 특정 진입점, 회선 또는 프로토콜 설정과 관련되었을 가능성이 큽니다.
클라이언트에는 연결됨으로 표시되지만 특정 앱이 여전히 로컬 네트워크를 사용한다면 해당 앱이 시스템 프록시나 TUN의 인계를 받는지 확인하세요. 전체 모드는 되지만 규칙 모드는 안 된다면 규칙 적용 결과와 DNS를 살펴보세요. 도메인은 열리지 않지만 알고 있는 주소로는 연결된다면 해석 경로 문제일 가능성이 높습니다. 도메인이 해석되는데 연결 시간이 초과된다면 라우팅, 노드와 대상 서비스의 응답을 계속 확인해야 합니다.
문제를 해결할 때는 한 번에 하나의 변수만 바꾸세요. 예를 들어 같은 프로토콜과 모드를 유지한 채 노드만 바꾸거나, 같은 노드를 유지한 채 규칙 모드에서 전체 모드로 전환합니다. 구독 업데이트, 프로토콜 변경, TUN 활성화와 DNS 수정까지 동시에 하면 문제가 사라져도 무엇이 효과가 있었는지 알기 어렵고, 같은 문제가 다시 발생했을 때 재현하기도 어렵습니다.