VPN 클라이언트를 처음 열었을 때 가장 어려운 부분은 보통 연결 버튼을 누르는 일이 아니라 구독, 노드, 프로토콜, 분할 라우팅, 전체 모드와 규칙 모드가 각각 무엇을 제어하는지 이해하는 것입니다. 이들은 같은 계층의 옵션이 아닙니다. 구독은 설정을 전달하고, 노드는 연결 진입점을 나타내며, 프로토콜은 클라이언트와 서버의 통신 방식을 정하고, 회선 유형은 데이터가 실제로 지나가는 네트워크 경로를 설명합니다. 분할 라우팅 모드는 어떤 요청이 이 경로를 사용할지 결정합니다.
전체 과정을 물류 배송에 비유할 수 있습니다. 구독은 계속 업데이트되는 주소록이고, 노드는 선택 가능한 환승 지점이며, 프로토콜은 양측이 합의한 포장 방식입니다. 회선은 화물이 실제로 이동하는 도로이고, 분할 라우팅 규칙은 배차표입니다. 이 용어들을 연결 과정에 맞춰 보면 클라이언트의 빽빽한 버튼도 명확한 데이터 흐름으로 이해할 수 있습니다.
핵심 용어 빠른 정리: 각 옵션이 무엇을 제어하는지 먼저 구분하기
| 용어 | 제어 대상 | 흔한 오해 | 정확한 이해 |
|---|---|---|---|
| 구독 | 설정 가져오기 및 업데이트 | 단일 서버와 같음 | 일반적으로 여러 노드, 매개변수와 규칙을 전달하는 진입점 |
| 노드 | 한 번의 연결에 사용하는 원격 진입점 | 이름에 특정 지역이 있으면 전체 네트워크 경로도 그 지역을 의미함 | 이름은 라벨일 뿐이며 실제 사용 환경은 진입점, 출구, 라우팅과 혼잡의 영향도 받음 |
| 프로토콜 | 클라이언트와 서버 간 통신 형식 | 프로토콜 이름이 곧 속도 순위임 | 프로토콜은 여러 변수 중 하나이며 전송 계층, 회선과 로컬 네트워크도 확인해야 함 |
| 회선 유형 | 데이터가 로컬 환경에서 출구까지 이동하는 경로 | 출구 지역이 같으면 경로도 같음 | 직접 연결, 중계와 IEPL 전용 회선은 서로 다른 도달 방식을 사용할 수 있음 |
| 분할 라우팅 | 각 요청의 목적지 | 활성화하면 모든 트래픽이 노드를 통과함 | 요청별로 프록시, 직접 연결 또는 차단을 선택할 수 있음 |
| 전체 모드 | 클라이언트가 가로채는 범위에서의 기본 목적지 | 기기의 모든 프로그램을 반드시 제어함 | 모든 앱을 포함하는지는 시스템 프록시, TUN과 앱 자체 설정에 따라 달라짐 |
| 규칙 모드 | 도메인, 주소 또는 프로세스에 따라 목적지 매칭 | 규칙이 많을수록 안정적임 | 규칙의 정확성과 최신 상태가 개수보다 중요함 |
여기서 가장 중요한 차이는 “설정”과 “트래픽”입니다. 구독, 노드와 프로토콜은 연결 설정에 속하고, 분할 라우팅, 전체 모드와 규칙 모드는 트래픽을 배분합니다. 연결 성공은 클라이언트와 원격 진입점 사이에 통로가 만들어졌다는 뜻일 뿐, 모든 앱이 그 통로를 사용한다거나 DNS 요청이 반드시 예상한 경로를 따른다는 의미는 아닙니다.
구독과 노드: 주소록과 연결 진입점은 다릅니다
구독 링크로 전달되는 내용
구독 링크는 일반적으로 클라이언트가 읽을 수 있는 설정 내용을 가리킵니다. 클라이언트가 링크에 접속하면 응답 내용을 노드 목록이나 설정 파일로 분석합니다. 클라이언트마다 지원하는 구독 형식은 다를 수 있습니다. 어떤 클라이언트는 범용 공유 링크를 바로 인식하고, 어떤 클라이언트는 특정 설정 구조가 필요하며, 규칙 그룹, 프록시 그룹과 DNS 매개변수를 함께 제공하는 경우도 있습니다.
구독 링크는 일반적인 웹페이지 북마크도, 단순한 다운로드 버튼도 아닙니다. 서버 주소, 포트, 프로토콜 인증 정보, 전송 방식과 노드 이름이 포함될 수 있으므로 접속 자격 정보처럼 안전하게 보관해야 합니다. 링크를 스크린샷, 로그 또는 문의 내용에 공개로 붙여 넣으면 전체 연결 설정이 함께 노출될 수 있습니다.
“구독 업데이트”는 클라이언트가 원격 설정을 다시 읽는다는 뜻입니다. 업데이트가 끝나면 서버에서 추가, 삭제 또는 수정한 노드가 로컬 목록에 반영됩니다. 일부 클라이언트는 구독에 포함된 노드를 수동으로 수정한 내용을 덮어쓸 수 있습니다. 따라서 오래 유지할 로컬 규칙은 구독에서 생성된 노드를 직접 편집하기보다 클라이언트가 지원하는 오버라이드, 설정 조각 또는 별도 규칙 영역에 두는 것이 좋습니다.
- 구독 링크 복사: 서비스 패널에서 클라이언트 형식에 맞는 링크를 가져오고, 채팅 스크린샷을 보고 직접 입력하지 마세요.
- 가져오기 방식 선택: 클라이언트에서 “URL에서 가져오기”, “구독 추가” 또는 의미가 비슷한 메뉴를 사용하세요.
- 업데이트 실행: 클라이언트가 분석을 완료할 때까지 기다리고, 로드되지 않은 구독 이름만 보이는 것이 아니라 노드 목록이 표시되는지 확인하세요.
- 노드 선택: 먼저 목적 지역과 용도에 맞는 출구를 선택한 뒤 회선 유형과 현재 네트워크 상태에 따라 조정하세요.
- 트래픽 제어 활성화: 플랫폼에 맞춰 시스템 프록시 또는 TUN을 선택하고, 실제 요청으로 출구와 DNS를 확인하세요.
노드 이름으로 알 수 있는 정보
노드는 연결을 설정할 수 있는 원격 설정입니다. 이름에는 보통 지역, 도시, 회선 또는 용도가 표시되지만 이름 자체가 네트워크 전송에 참여하는 것은 아닙니다. 사용자가 설정을 선택하도록 돕는 운영 라벨에 가깝습니다. 노드에 “일본”이라고 표시되어 있으면 예상 출구가 일본에 있다는 뜻인 경우가 많지만, 이름만으로 진입점 위치, 전송 경로, 통신사 라우팅 또는 현재 혼잡 상태를 판단할 수는 없습니다.
“노드”와 “서버”도 완전히 같은 개념은 아닙니다. 여러 노드 설정이 하나의 인프라에서 제공될 수도 있고, 서로 다른 진입점, 출구 또는 전송 매개변수에 대응할 수도 있습니다. 반대로 하나의 노드 뒤에 진입점 전달과 출구 서비스가 함께 구성될 수도 있습니다. 사용자 관점에서 노드는 클라이언트에서 선택하는 논리적 연결 항목이고, 서버는 그 연결을 구현하는 인프라 개념입니다.
- ✅ 먼저 출구 지역이 대상 서비스의 지역 조건에 맞는지 확인하세요.
- ✅ 현재 네트워크 환경과 사용 시간대에 회선 유형이 적합한지 확인하세요.
- ✅ 노드를 바꾼 뒤에는 대상 연결을 다시 열어 기존 세션이 이전 출구를 계속 사용하지 않도록 하세요.
- ❌ 노드 이름의 “고속”, “전용” 같은 표현만으로 실제 경로를 판단하지 마세요.
- ❌ 구독 업데이트 실패를 모든 노드의 동시 장애로 오해하지 마세요.
프로토콜: Shadowsocks, VMess, Trojan, VLESS, Hysteria2 및 TUIC
프로토콜은 클라이언트가 요청을 어떻게 캡슐화하고 인증을 완료한 뒤 서버와 데이터를 주고받을지 정합니다. 프로토콜 이름은 전송 계층, TLS, WebSocket, QUIC 같은 매개변수와 함께 표시되는 경우가 많으므로 같은 프로토콜도 배포 방식이 다를 수 있습니다. 프로토콜 이름만으로 속도, 안정성 또는 적합한 지역을 바로 판단할 수는 없습니다. 프로토콜, 전송 방식, 회선과 로컬 네트워크를 함께 살펴보는 편이 정확합니다.
| 프로토콜 | 주요 특징 | 설정 시 확인할 항목 | 네트워크 적용 팁 |
|---|---|---|---|
| Shadowsocks | 가벼운 암호화 프록시 프로토콜로, 설정 구조가 비교적 단순함 | 암호화 방식, 비밀번호, 서버와 포트가 일치해야 함 | 폭넓게 구현되어 있지만 최종 성능은 회선과 클라이언트 구현에 따라 달라짐 |
| VMess | V2Ray 생태계에서 흔히 사용되며 인증과 여러 전송 조합을 포함함 | 사용자 식별자, 전송 방식, TLS와 경로 매개변수가 일치해야 함 | 기존 설정을 이전할 때 클라이언트가 사용 중인 전송 방식을 완전히 지원하는지 확인해야 함 |
| Trojan | 일반적으로 TLS를 사용해 프록시 트래픽을 전달함 | 도메인, 인증서 검증, 비밀번호와 서버 이름 설정 | 시스템 시간이나 인증서 검증에 문제가 있으면 핸드셰이크가 실패할 수 있음 |
| VLESS | 인증 구조가 비교적 단순하며 TLS, REALITY 같은 전송 보안 방식과 함께 구성되는 경우가 많음 | 사용자 식별자, 흐름 제어, 서버 이름과 전송 매개변수 | 클라이언트 코어가 오래되면 최신 조합 매개변수를 인식하지 못할 수 있음 |
| Hysteria2 | QUIC와 UDP를 기반으로 하며 복잡한 네트워크 환경을 고려한 혼잡 제어 설계를 포함함 | TLS, 인증, 대역폭 설정과 UDP 연결 가능 여부 | UDP가 제한된 네트워크에서는 연결을 설정하지 못할 수 있음 |
| TUIC | QUIC와 UDP를 기반으로 하며 동시 전송과 연결 재사용을 지원함 | 인증 정보, 인증서 검증, 혼잡 제어와 UDP 설정 | TCP 기반 방식과 교차 테스트하기에 적합하며 프로토콜 라벨만 보고 결론 내리면 안 됨 |
Shadowsocks는 엄밀히 말하면 기존 네트워크 인터페이스를 만드는 완전한 VPN 프로토콜이 아니라 암호화 프록시입니다. 일상적인 사용 환경에서는 많은 클라이언트가 서로 다른 프록시 프로토콜을 “VPN” 또는 “프록시” 제품 화면에 함께 표시합니다. 이는 제품 계층의 분류일 뿐 프로토콜의 작동 방식이 바뀌는 것은 아닙니다.
VMess와 VLESS는 모두 V2Ray 호환 생태계에서 자주 사용되지만, 단순히 구형과 신형 이름을 바꾼 관계는 아닙니다. 인증과 프로토콜 구조가 다르므로 서버가 제공한 설정에 맞는 형식으로 클라이언트에 가져와야 합니다. Trojan은 일반적으로 올바른 TLS 매개변수에 의존합니다. 클라이언트에서 핵심 필드를 누락하면 인증 전에 핸드셰이크 문제로 연결이 종료될 수 있습니다.
Hysteria2와 TUIC는 QUIC 및 UDP를 사용합니다. 패킷 손실, 지터 또는 대역폭 변화가 있는 네트워크에서는 TCP 방식과 다른 동작을 보일 수 있지만, 현재 네트워크가 UDP 통신을 허용해야 합니다. 회사 네트워크, 공용 네트워크 또는 일부 라우터 장비가 UDP를 제한할 수 있습니다. 이때는 QUIC 매개변수를 계속 수정하기보다 TCP 기반 설정으로 바꾸는 편이 더 직접적입니다.
회선 유형: 직접 연결, 중계와 IEPL 전용 회선의 실제 차이
프로토콜은 “어떻게 전송할지”를 해결하고, 회선은 “어디를 거쳐 갈지”를 결정합니다. 두 노드가 같은 프로토콜을 사용하고 같은 출구 지역을 가리키더라도 경로가 다르면 지연 시간, 지터와 패킷 손실 특성이 크게 달라질 수 있습니다. 노드를 고를 때 회선을 무시하고 프로토콜만 보는 것은 차량 종류만 보고 도로 상태를 확인하지 않는 것과 같습니다.
직접 연결
직접 연결은 클라이언트가 원격 노드의 진입점에 바로 연결되는 방식으로, 서비스 측이 별도로 제공하는 중계 진입점이 중간에 없습니다. 구조가 단순하고 우회 구간이 적지만 국제 구간의 품질은 로컬 통신사와 공용 인터넷 라우팅에 더 크게 좌우됩니다. 한 네트워크 환경에서 원활했던 직접 연결이 다른 통신사에서도 같은 성능을 보인다고 할 수는 없습니다.
중계 회선
중계 방식은 먼저 가깝거나 도달하기 쉬운 진입점에 연결한 뒤, 진입점이 트래픽을 목표 출구로 전달합니다. 중계의 의미는 물리적 거리를 마법처럼 줄이는 것이 아니라 더 제어하기 쉬운 진입점과 후속 라우팅을 통해 품질이 낮은 공용 인터넷 구간을 피하는 데 있습니다. 중계 구간이 추가되므로 진입점 용량, 진입점에서 출구까지의 경로와 분배 정책이 최종 사용 환경에 영향을 줍니다.
IEPL 전용 회선
IEPL은 일반적으로 서로 다른 지점 사이에 보다 제어 가능한 전용 전송 경로를 제공하는 국제 이더넷 전용 회선 계열의 연결을 의미합니다. 구독 서비스에서는 사용자가 먼저 로컬 또는 인접 진입점에 도달한 뒤 전용 회선 구간을 통해 원격 출구로 이동하는 구조가 흔합니다. 사용자의 기기가 전용 회선 전체에 직접 연결된다는 뜻도 아니며, 기기에서 진입점까지의 모든 구간이 공용 인터넷에서 벗어난다는 뜻도 아닙니다.
IEPL의 공학적 가치는 경로 제어 가능성과 국제 구간의 안정성에 있습니다. 특정 프록시 프로토콜에 종속되지 않습니다. 전용 회선은 경로를 전달하고, Shadowsocks, Trojan, VLESS 등은 클라이언트와 진입점 사이의 통신을 담당합니다. “IEPL”을 프로토콜 이름으로 이해하면 설정 문제를 완전히 잘못된 방향으로 점검하게 됩니다.
분할 라우팅, 전체 및 규칙 모드: 각 요청의 경로 결정하기
연결이 설정된 뒤에도 클라이언트는 어떤 트래픽을 노드로 보낼지 결정해야 합니다. 이 판단 과정이 분할 라우팅입니다. 주요 동작에는 프록시, 직접 연결과 차단이 있습니다. 프록시는 요청을 현재 노드 또는 프록시 그룹에 전달하고, 직접 연결은 로컬 네트워크로 접속하며, 차단은 요청을 보내지 않습니다. 광고 도메인, 추적 도메인 또는 연결할 필요가 없는 주소에 주로 사용됩니다.
전체 모드는 말 그대로 “전부”가 아닙니다
전체 모드는 보통 클라이언트가 이미 제어하고 있는 트래픽 범위 안에서 기본적으로 모든 요청을 프록시로 보내는 방식입니다. 핵심은 “이미 제어하고 있는”이라는 조건입니다. 클라이언트가 시스템 프록시만 활성화했다면 시스템 프록시 설정을 따르는 앱이 제어 대상이 되고, 이를 무시하고 자체적으로 연결하는 앱은 클라이언트에 들어오지 않을 수 있습니다. TUN을 활성화하면 클라이언트가 네트워크 계층에서 더 넓은 트래픽을 제어할 수 있지만 플랫폼 권한, 라우팅 제외와 LAN 설정의 영향을 받을 수 있습니다.
따라서 “전체”라는 표시만 보고 기기의 모든 데이터가 노드를 통과한다고 판단해서는 안 됩니다. 대상 앱의 출구, DNS 경로와 클라이언트 연결 로그를 확인하는 것이 올바른 검증 방법입니다. 브라우저의 출구는 바뀌었지만 특정 독립 앱이 여전히 로컬 네트워크를 사용한다면 해당 앱이 시스템 프록시를 우회하는지, TUN이 제대로 활성화되었는지 확인하세요.
규칙 모드는 요청을 어떻게 매칭할까
규칙 모드는 도메인, IP 주소, 지리 데이터베이스, 앱 프로세스 또는 포트 등의 조건에 따라 동작을 선택합니다. 클라이언트는 일반적으로 위에서 아래 순서로 규칙을 매칭하고, 일치하면 해당 정책을 실행합니다. 일치하는 규칙이 없으면 최종 규칙으로 넘어갑니다. 따라서 규칙 순서가 중요합니다. 범위가 넓은 규칙을 앞에 두면 뒤의 정밀한 규칙이 적용될 기회를 잃을 수 있습니다.
도메인이 대상 서비스에 해당 → 프록시
도메인이 로컬에서 자주 사용하는 서비스에 해당 → 직접 연결
주소가 LAN 범위에 해당 → 직접 연결
도메인이 차단 목록에 해당 → 거부
나머지 요청 → 최종 규칙에 따라 처리이 로직은 특정 클라이언트의 고정 문법이 아니라 이해를 돕기 위한 의사결정 모델입니다. 클라이언트마다 규칙 형식은 서로 호환되지 않을 수 있습니다. 규칙을 복사하기 전에 현재 코어가 지원하는 문법, 정책 그룹 이름과 DNS 모드를 확인하세요. 그렇지 않으면 규칙을 가져오는 데 성공해도 실제로 매칭되지 않을 수 있습니다.
- ✅ 국제 서비스를 이용할 때 해당 도메인과 관련 의존 도메인이 프록시 정책을 사용하도록 설정하세요.
- ✅ 로컬 서비스는 우선 직접 연결해 불필요한 우회와 지역 인식 변화를 줄이세요.
- ✅ LAN 장치는 보통 직접 연결로 유지해 프린터, 저장 장치 또는 라우터 관리 페이지와의 연결이 끊기지 않도록 하세요.
- ✅ 규칙을 수정한 뒤 기존 연결을 종료하고 다시 테스트해 연결 재사용의 영향을 피하세요.
- ❌ 의미를 이해하지 못한 상태에서 모든 요청을 하나의 정책에 장기간 고정하지 마세요.
시스템 프록시와 TUN: 연결은 성공했는데 일부 앱에 적용되지 않는 이유
시스템 프록시는 운영체제가 앱에 제공하는 프록시 설정입니다. 브라우저와 시스템 네트워크 설정을 따르는 대부분의 데스크톱 앱이 이를 사용하지만, 게임, 명령줄 도구, 가상 머신과 자체 네트워크 스택을 구현한 프로그램은 무시할 수 있습니다. 시스템 프록시는 설정이 간단해 웹페이지와 일반 앱에 적합하지만, 적용 범위는 앱이 이를 따르는지에 따라 달라집니다.
TUN 모드는 가상 네트워크 인터페이스를 만들고 라우팅을 통해 트래픽을 클라이언트로 전달합니다. 시스템 프록시를 지원하지 않는 앱도 더 많이 포함할 수 있어 UDP가 필요하거나 프로세스별 분할 라우팅을 사용하는 상황에 적합합니다. 그만큼 높은 시스템 권한이 필요하며 다른 네트워크 도구, 방화벽, 가상 머신 네트워크 카드 또는 기업 보안 정책과 라우팅 충돌이 발생할 수 있습니다.
일부 클라이언트는 “강화 모드”, “가상 네트워크 카드 모드” 또는 비슷한 이름의 기능도 제공합니다. 실제로는 서로 다른 TUN 구현일 수 있습니다. 이름은 클라이언트 화면에 따라 달라지므로 버튼 문구만 보지 말고 가상 인터페이스 생성 여부, DNS 제어 여부와 기본 경로 변경 여부를 확인해야 합니다.
DNS 누수와 해석 경로: 출구가 맞아도 설정은 끝나지 않습니다
도메인에 접속하기 전에 기기는 보통 DNS를 통해 도메인을 주소로 변환합니다. DNS 누수란 지정된 해석기나 통신 경로로 처리되어야 할 DNS 요청이 실제로는 예상한 경로를 벗어나는 현상입니다. 예를 들어 웹페이지 연결은 프록시 노드를 통해 이루어지지만 도메인 조회는 로컬 네트워크의 해석기에 직접 전달될 수 있습니다. 이로 인해 지역별 해석이 달라지거나 규칙이 잘못 매칭되고 개인정보 보호 범위가 예상과 어긋날 수 있습니다.
DNS 문제는 “누수”로만 나타나지 않습니다. DNS가 로컬 네트워크에 적합한 주소를 반환했는데 연결은 원격 출구에서 이루어지면 대상 서비스가 느리게 연결되거나 잘못된 지역으로 들어갈 수 있습니다. 규칙이 도메인에 의존하는데 클라이언트가 해석된 주소만 확인할 수 있다면 도메인 기반 분할 라우팅도 작동하지 않을 수 있습니다. 일부 클라이언트는 Fake-IP, 원격 해석 또는 DNS 가로채기를 통해 해석 과정을 규칙 엔진에 포함하지만, 구체적인 기능은 클라이언트 코어와 설정에 따라 다릅니다.
확인할 때는 “어떤 출구를 사용하는가”와 “어떤 해석기를 사용하는가”를 나누어 살펴봐야 합니다. 출구 확인은 웹 연결이 어디에서 시작되는지만 보여줄 뿐 DNS 경로가 올바르다는 것을 단독으로 증명하지는 않습니다. 노드나 DNS 모드를 바꾼 뒤에는 운영체제, 브라우저와 앱 자체의 캐시도 고려해야 합니다. 브라우저에서 독립적인 암호화 DNS를 사용하면 클라이언트가 설정한 해석기를 우회할 수도 있습니다.
- 트래픽 제어 방식 확인: 현재 시스템 프록시를 사용하는지 TUN을 사용하는지, DNS를 클라이언트가 처리하는지 확인하세요.
- 기존 세션 정리: 대상 앱에서 기존 연결을 종료하고 필요하면 DNS 캐시를 삭제하세요.
- 출구 확인: 대상 요청에 예상한 노드 지역이 표시되는지 확인하세요.
- 해석 확인: 출구 주소만 보지 말고 해석기가 현재 설정과 일치하는지 확인하세요.
- 로그 재확인: 도메인이 예상한 규칙에 매칭되었고 앞선 규칙에 가로채이지 않았는지 확인하세요.
플랫폼별 클라이언트 차이: 같은 구독인데 화면이 다른 이유
구독 내용은 같을 수 있지만 Windows, macOS, Linux, Android와 iOS 클라이언트는 권한 모델, 백그라운드 제한과 네트워크 인터페이스가 서로 다릅니다. 한 클라이언트가 특정 프로토콜을 가져올 수 있다고 해서 해당 프로토콜의 모든 전송 조합을 지원하는 것은 아닙니다. 같은 이름의 기능도 서로 다른 코어로 구현될 수 있습니다.
Windows 클라이언트는 시스템 프록시와 TUN을 함께 제공하는 경우가 많습니다. TUN을 활성화했다면 가상 네트워크 카드, 시스템 방화벽과 다른 네트워크 소프트웨어를 우선 확인해야 합니다. macOS도 시스템 프록시 또는 네트워크 확장을 사용할 수 있지만 시스템 권한 승인, 절전 모드 복귀와 네트워크 전환이 연결 상태에 영향을 줄 수 있습니다. Linux는 클라이언트 형태의 차이가 더 큽니다. 그래픽 인터페이스뿐 아니라 설정 파일과 서비스 프로세스로 실행되는 코어도 있으므로 데스크톱 프록시 변수, 시스템 라우팅과 컨테이너 네트워크를 따로 확인해야 합니다.
Android 클라이언트는 보통 시스템 VPN 인터페이스를 이용해 트래픽을 제어하며 앱별 분할 라우팅을 제공하기도 합니다. 시스템의 배터리 절약과 백그라운드 관리가 장시간 연결에 영향을 줄 수 있고, Wi-Fi와 모바일 데이터 사이를 전환할 때 재연결이 발생할 수도 있습니다. iOS 클라이언트는 시스템 네트워크 확장 메커니즘의 관리를 받습니다. 앱마다 프로토콜, 규칙 세트와 스크립트 기능의 지원 범위가 다르므로 가져오기 전에 형식 호환성을 확인해야 합니다.
| 플랫폼 | 일반적인 트래픽 제어 방식 | 우선 확인할 항목 |
|---|---|---|
| Windows | 시스템 프록시, TUN | 가상 네트워크 카드, 라우팅, 방화벽과 다른 프록시 도구 |
| macOS | 시스템 프록시, 네트워크 확장 또는 TUN | 시스템 권한, 네트워크 전환과 절전 모드 복귀 |
| Linux | 프록시 변수, 투명 프록시, TUN | 서비스 권한, 라우팅 테이블, DNS와 데스크톱 환경 설정 |
| Android | 시스템 VPN 인터페이스 | 백그라운드 제한, 앱별 분할 라우팅과 네트워크 전환 |
| iOS | 네트워크 확장 | 클라이언트 형식, 시스템 권한과 주문형 연결 규칙 |
플랫폼 간에 설정을 옮길 때 가장 안전한 방법은 한 플랫폼에서 내보낸 전체 설정을 그대로 복사하는 것이 아니라 대상 클라이언트에 맞는 구독을 다시 가져오는 것입니다. 전체 설정에는 특정 코어의 규칙 문법, 스크립트, 정책 그룹 또는 DNS 필드가 포함될 수 있습니다. 다른 클라이언트가 파일을 받아들여도 인식하지 못하는 부분은 무시할 수 있습니다.
초보자 문제 해결 목록: 구독부터 트래픽까지 계층별 확인
클라이언트 화면에 이상이 생겼을 때 프로토콜, 노드, DNS와 분할 라우팅을 동시에 바꾸지 마세요. 여러 변수를 한 번에 변경하면 문제가 일시적으로 사라져도 실제 원인을 알 수 없습니다. 설정 전달, 연결 설정, 트래픽 제어, 규칙 매칭과 도메인 해석 순서에 따라 계층별로 확인하는 편이 효과적입니다.
- ✅ 구독이 업데이트됨: 링크가 유효하고 클라이언트가 해당 형식을 분석할 수 있습니다.
- ✅ 노드에 연결됨: 인증, 프로토콜, 전송과 TLS 매개변수가 일치합니다.
- ✅ 트래픽이 제어됨: 시스템 프록시 또는 TUN이 활성화되어 대상 앱의 트래픽이 클라이언트로 들어옵니다.
- ✅ 규칙이 매칭됨: 대상 도메인이 예상한 정책으로 들어가고 앞선 규칙에 덮어쓰이지 않습니다.
- ✅ 출구가 예상과 일치함: 새 연결이 선택한 지역에서 시작됩니다.
- ✅ DNS 경로가 올바름: 해석기가 현재 모드와 일치하고 앱이 별도로 우회하지 않습니다.
- ❌ 연결 버튼의 색상만으로 모든 설정이 정상인지 판단하지 마세요.
- ❌ 단일 웹사이트의 캐시, 계정 지역 또는 서비스 제한을 바로 노드 장애로 단정하지 마세요.
구독은 업데이트되지 않지만 이전에 가져온 노드가 계속 연결된다면 문제는 설정 가져오기 계층에 있을 가능성이 큽니다. 모든 노드가 핸드셰이크에 성공했는데도 앱 트래픽이 없다면 트래픽 제어 계층을 확인하세요. 특정 도메인만 잘못된 경로로 연결되면 규칙과 DNS를 살펴봐야 합니다. 한 플랫폼에서만 문제가 발생한다면 클라이언트 코어, 권한과 지원되는 설정 필드를 다른 플랫폼과 먼저 비교하세요.