구독 링크란 구독 서비스가 생성해 호환 클라이언트에서 읽을 수 있도록 제공하는 설정 주소입니다. 클라이언트가 이 주소에 접속하면 회선 이름, 서버 주소, 포트, 프로토콜 매개변수, 그룹 정보 등을 받아 선택하고 연결할 수 있는 회선 목록으로 정리합니다. 노드를 하나씩 복사할 필요는 없지만, 이 주소는 일반 웹 링크가 아닌 계정 인증 정보로 보관해야 합니다.
구독 링크 자체가 네트워크 연결을 직접 수립하는 것은 아닙니다. 실제 핸드셰이크, 암호화, 라우팅과 DNS 처리는 클라이언트 및 구독 내용에 지정된 Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC 등의 프로토콜이 담당합니다. 이 차이를 이해하면 브라우저에서 구독 주소가 열려도 클라이언트 호환이 보장되지 않고, 클라이언트에 가져오기가 완료되어도 시스템 트래픽이 예상한 회선으로 흐른다고 단정할 수 없는 이유를 알 수 있습니다.
구독 링크에는 무엇이 들어 있을까
겉으로 보면 구독 링크는 HTTPS로 시작하는 주소 문자열에 불과하지만, 클라이언트 관점에서는 업데이트 가능한 설정 진입점입니다. 클라이언트가 이 주소에 콘텐츠를 요청하면 서버는 구독 상태에 따라 회선 목록을 반환합니다. 반환 형식은 인코딩된 노드 목록일 수도 있고 YAML, JSON 또는 특정 클라이언트 전용 설정일 수도 있습니다. 형식은 자동으로 호환되지 않으므로 하나의 서비스가 클라이언트별로 서로 다른 진입점을 제공할 수 있습니다.
단일 노드 링크와 구독 링크는 서로 다릅니다. ss://, vmess://, trojan://, vless://, hysteria2:// 또는 tuic://로 시작하는 내용은 보통 특정 회선 하나를 설명합니다. 반면 구독 주소는 한 번에 여러 회선을 반환하고, 서버에서 조정된 내용을 클라이언트가 다시 가져오도록 합니다. 일부 구독 콘텐츠는 여러 단일 노드 링크를 함께 인코딩하고, 다른 콘텐츠는 완전한 정책 설정을 직접 제공합니다.
| 콘텐츠 유형 | 주요 용도 | 업데이트 방식 | 주의할 점 |
|---|---|---|---|
| 단일 노드 링크 | 지정한 회선 하나 가져오기 | 보통 다시 가져와 가져와야 함 | 전체 회선 목록은 포함하지 않음 |
| 범용 구독 | 호환 클라이언트에 회선 목록 제공 | 클라이언트에서 구독을 다시 가져옴 | 분할 라우팅 규칙은 클라이언트에서 별도로 관리할 수 있음 |
| 클라이언트 전용 구독 | 회선·그룹·정책 설정 제공 | 해당 클라이언트에서 업데이트 | 다른 클라이언트로 가져오면 형식이 호환되지 않을 수 있음 |
| 로컬 설정 파일 | 가져온 설정 또는 수동 규칙 저장 | 사용자가 로컬에서 관리 | 서버 변경 사항을 자동으로 가져오지 않음 |
프로토콜과 회선 유형도 구분해서 이해해야 합니다. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC은 통신 방식과 매개변수를 설명하고, IEPL 전용 회선, 중계, 직접 연결은 트래픽이 해외 출구까지 도달하는 방식을 주로 설명합니다. IEPL 전용 회선은 일반적으로 통신사 전용 회선 자원으로 국제 구간을 전달하고, 중계 회선은 중간 진입점을 거친 뒤 출구로 이동하며, 직접 연결은 로컬 네트워크에서 해외 서버에 직접 접속합니다. 구독 링크에는 이런 여러 유형의 회선을 함께 담을 수 있지만, 라우팅, 혼잡 상황과 사용 목적의 차이까지 없애지는 않습니다.
패널에서 가져오기 및 안전하게 보관하기
구독 링크는 로그인 후 서비스 패널의 다운로드 또는 구독 영역에서 받아야 합니다. 현재 클라이언트에 맞는 형식을 선택한 뒤 복사 버튼을 사용하세요. 검색 결과, 채팅으로 전달받은 주소 또는 다른 사람이 제공한 단축 주소에 의존하지 마세요. VPNGP는 사용자 이름과 비밀번호만으로 시작할 수 있으며 이메일 주소가 필요하지 않습니다. 본인 패널에서 받은 링크라야 현재 구독과 연결됩니다.
패널에 ‘범용 구독’과 특정 클라이언트 전용 설정이 함께 표시된다면, 클라이언트 안내에서 명확히 지원하는 형식을 우선 사용하세요. 전용 설정에는 정책 그룹, DNS 설정과 규칙 제공자가 포함될 수 있고, 범용 구독은 이전이 편리하지만 노드만 포함할 수 있습니다. 전용 형식의 파일 확장자만 다른 이름으로 바꾼다고 형식이 변환되지는 않습니다.
- ✅ 주소가 본인의 VPNGP 패널에서 제공된 것인지 확인하고 현재 선택한 클라이언트 형식도 점검하세요.
- ✅ 클라이언트의 ‘URL에서 가져오기’ 또는 ‘구독 추가’를 우선 사용하고 매개변수를 수동으로 분해하지 마세요.
- ✅ 출처를 알아보기 쉬운 로컬 이름을 구독에 지정하면 이후 업데이트 때 잘못 선택할 가능성이 줄어듭니다.
- ✅ 가져오기가 끝나면 임시 텍스트, 공유 클립보드와 전체 링크가 포함된 스크린샷을 삭제하세요.
- ❌ 구독 주소를 일반 다운로드 링크처럼 다른 사람에게 전달하지 마세요.
- ❌ 출처가 불분명한 온라인 변환 도구에 전체 구독 주소를 입력하지 마세요.
HTTPS는 전송 과정에서 일반적인 평문 열람을 막아 주지만, 주소를 공개해도 된다는 뜻은 아닙니다. 전체 토큰이 유효한 동안에는 링크를 얻은 사람이 설정 내용을 읽을 수 있습니다. 브라우저 기록, 클라우드 클립보드, 터미널 명령 기록과 자동 동기화되는 메모가 노출 범위를 넓힐 수 있습니다. 패널에서 신뢰할 수 있는 클라이언트로 직접 복사하고 완료 후 중간 사본을 삭제하는 편이 안전합니다.
다섯 플랫폼에 어떻게 가져올까
플랫폼마다 버튼 이름은 다를 수 있지만 핵심 과정은 같습니다. 호환 클라이언트를 선택하고 원격 구독을 추가한 다음 링크를 붙여넣어 저장하고 업데이트한 뒤 회선을 선택해 연결합니다. 가져온 후에는 시스템 프록시, 가상 네트워크 인터페이스와 분할 라우팅 모드도 확인해야 합니다. 노드 이름이 보인다는 사실만으로 네트워크가 정상적으로 인계되었다고 볼 수는 없습니다.
Windows
Windows 클라이언트에서 구독 관리 또는 설정 관리 메뉴를 찾아 URL로 추가하는 항목을 선택하고 링크를 붙여넣어 업데이트하세요. 그런 다음 방금 가져온 설정이 활성화되어 있는지 확인하고 필요에 따라 시스템 프록시 또는 TUN 모드를 켭니다. 시스템 프록시는 프록시 설정을 따르는 앱을 주로 처리합니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 처리하지만 높은 권한이 필요할 수 있고 다른 네트워크 필터링 소프트웨어와 라우팅 충돌이 발생하기 쉽습니다.
브라우저는 접속되지만 특정 데스크톱 프로그램이 연결되지 않는다면 먼저 해당 프로그램이 시스템 프록시를 무시하는지 확인하세요. 구독을 반복해서 삭제하지 말고 클라이언트의 현재 모드, 우회 목록과 시스템 라우팅을 점검해야 합니다. 모드를 바꾼 뒤 다시 테스트해야 노드 문제와 로컬 인계 문제를 구분할 수 있습니다.
macOS
macOS의 가져오기 방식은 Windows와 비슷하며 원격 설정 또는 구독 메뉴에서 URL을 추가합니다. 저장 후에는 클라이언트가 필요한 네트워크 설정을 생성하도록 허용하고 메뉴 막대 상태와 클라이언트에서 선택한 정책이 일치하는지 확인하세요. 일부 앱은 시스템 프록시를 따르고, 일부 연결은 가상 네트워크 인터페이스가 있어야 처리됩니다. 따라서 ‘클라이언트가 연결됨’과 ‘모든 앱의 트래픽이 회선을 통과함’은 여전히 별개의 판단입니다.
시스템 업데이트 또는 클라이언트 업그레이드 후 네트워크 확장 권한이 취소되면 기존 구독은 남아 있어도 연결이 되지 않을 수 있습니다. 이때는 먼저 시스템 권한과 확장 상태를 확인하고 구독 링크를 바로 재설정하지 마세요.
Android
Android 클라이언트는 일반적으로 클립보드에서 가져오기, URL로 추가하기 또는 QR 코드 스캔을 제공합니다. 추가한 뒤 먼저 구독을 업데이트하고 노드를 선택한 다음 VPN 연결 생성을 허용하세요. 앱별 프록시가 필요하다면 어떤 앱을 회선으로 보낼지, 어떤 앱을 직접 연결할지 명확히 선택해야 합니다. 앱 목록을 조정한 후에는 규칙이 실제 요구와 여전히 일치하는지 다시 확인하세요.
백그라운드 절전 정책이 클라이언트 프로세스를 일시 중지하면 앱 전환 후 연결이 끊기거나 시스템이 네트워크를 다시 설정하는 현상이 나타날 수 있습니다. 이 경우 구독 업데이트를 백그라운드 유지 수단으로 사용하지 말고 클라이언트의 백그라운드 실행 권한과 시스템 배터리 관리 설정을 확인하세요. 구독은 설정을 담당하고 백그라운드 정책은 클라이언트의 지속 실행 여부를 담당합니다.
iOS
iOS 클라이언트는 보통 구독 주소를 붙여넣거나 지원되는 URL을 열거나 QR 코드를 스캔해 가져옵니다. 처음 연결할 때 시스템에서 네트워크 설정 추가를 허용할지 묻습니다. 구독 QR 코드가 같은 기기에 표시되어 있다면 스캔보다 주소를 직접 복사하는 편이 편리할 수 있습니다. 복사한 뒤에는 전체 링크가 여러 기기의 클립보드에 오래 남지 않도록 주의하세요.
가져온 후 노드만 표시되고 예상한 정책 그룹이 없다면 범용 노드 구독을 사용했는데 클라이언트에는 전용 설정이 필요한 경우가 흔합니다. 이때는 패널로 돌아가 맞는 형식을 선택하고 클라이언트에서 익숙하지 않은 규칙을 하나씩 직접 추가하지 마세요.
Linux
Linux에는 그래픽 클라이언트와 명령줄 코어가 모두 있습니다. 그래픽 클라이언트는 보통 원격 구독을 직접 추가할 수 있지만, 명령줄 환경에서는 먼저 설정을 다운로드한 뒤 코어가 로컬 파일을 읽도록 해야 할 수 있습니다. 다운로드 명령을 실행할 때 셸 기록에 전체 매개변수가 저장될 수 있으므로 구독 주소를 공유 가능한 스크립트, 로그 또는 공개 설정 저장소에 직접 작성하지 않는 것이 좋습니다.
시스템 서비스로 실행할 때는 서비스 계정이 설정 파일을 읽을 수 있는지, DNS와 라우팅 명령에 필요한 권한이 있는지, 데스크톱 세션의 프록시 변수가 시스템 서비스 설정과 일치하는지 확인해야 합니다. Linux에서 가장 흔한 오판은 코어는 실행 중이지만 앱이 여전히 기존 환경 변수나 DNS 경로를 사용하는 경우입니다.
가져온 후 점검 순서
구독이 정상적으로 업데이트되었는가
현재 설정이 활성화되었는가
대상 회선으로 연결할 수 있는가
시스템 프록시 또는 가상 인터페이스가 활성화되었는가
분할 라우팅과 DNS가 예상대로 작동하는가얼마나 자주 업데이트하며, 무엇이 바뀌는가
모든 클라이언트에 적용되는 고정된 구독 업데이트 주기는 없습니다. 자동 업데이트 빈도는 클라이언트 설정, 설정 형식과 실행 상태에 따라 달라집니다. 일부 클라이언트는 시작할 때만 확인하고, 일부는 백그라운드 가져오기를 지원하며, 완전히 수동 작업에 의존하는 경우도 있습니다. 패널에서 회선이 조정되었다고 안내하거나 노드 목록이 오래되었거나 현재 회선이 작동하지 않거나 서비스 측에서 새로고침을 요청할 때 직접 구독을 업데이트하는 것이 더 확실합니다.
업데이트할 때 클라이언트는 기존 구독 주소에 다시 접속해 새로운 원격 콘텐츠로 회선 목록을 갱신합니다. 노드 이름, 서버 주소, 프로토콜 매개변수, 그룹과 원격 규칙이 바뀔 수 있습니다. 적용 범위는 형식에 따라 다릅니다. 노드 목록만 포함한 범용 구독은 보통 로컬 분할 라우팅을 관리하지 않지만, 완전한 설정 구독은 같은 설정의 정책 그룹, DNS와 규칙을 덮어쓸 수 있습니다.
이 때문에 수동 수정 내용이 사라지기 쉽습니다. 원격 구독에서 생성된 노드를 직접 편집하면 다음 새로고침 때 클라이언트가 서버 내용에 따라 설정을 다시 만들 수 있습니다. 오래 유지할 로컬 규칙은 클라이언트가 명시적으로 제공하는 재정의, 병합 또는 로컬 설정 계층에 넣어야 합니다. 이런 기능이 없다면 구독 인증 정보가 포함되지 않은 규칙 백업을 보관하는 편이 안전합니다.
- ✅ 업데이트 전에 올바른 구독을 조작하고 있는지 확인해 이름이 같은 설정끼리 덮어쓰지 않도록 하세요.
- ✅ 업데이트 후 새로 추가되거나 삭제되거나 이름이 바뀐 회선을 확인하고 정책을 다시 선택하세요.
- ✅ 로컬 분할 라우팅은 클라이언트가 지원하는 재정의 계층에 배치하고 규칙의 용도를 기록하세요.
- ✅ 노드 목록이 이상하면 먼저 수동으로 새로고침한 뒤 다시 가져올 필요가 있는지 판단하세요.
- ❌ 시스템 권한, 라우팅 충돌 또는 백그라운드 일시 중지 문제를 반복 새로고침으로 해결하려 하지 마세요.
가져오기 성공 후 분할 라우팅과 DNS 검증
클라이언트에 지연 시간이나 ‘연결됨’이 표시되는 것은 테스트 요청 하나가 성공했다는 뜻일 뿐, 실제 앱이 모두 예상한 경로를 사용한다는 의미는 아닙니다. 검증할 때는 먼저 전체 인계, 도메인별 분할 라우팅, 특정 앱만 회선을 사용하게 하는 설정 중 목표를 정해야 합니다. 목표마다 확인 방법이 다르므로 출구 주소만 보고 끝내서는 안 됩니다.
분할 라우팅 규칙은 일반적으로 도메인, IP, 앱 또는 규칙 집합에 따라 직접 연결과 프록시를 결정합니다. 규칙을 위에서 아래로 매칭할 때 더 포괄적인 규칙이 요청을 먼저 가로채면 뒤의 규칙이 적용되지 않을 수 있습니다. 도메인 규칙은 DNS 확인 방식의 영향도 받습니다. 클라이언트가 확인된 IP만 볼 수 있는데 규칙에는 도메인만 적혀 있다면 매칭 결과가 예상과 달라질 수 있습니다.
DNS 누출은 일반적으로 제어된 경로에서 처리되어야 할 조회 요청이 다른 DNS 확인 서버로 전송되는 현상을 뜻합니다. 이는 ‘일부 트래픽을 규칙에 따라 직접 연결하는 것’과 같은 개념이 아닙니다. 의도적으로 설정한 직접 연결 DNS는 구성 선택이고, 예상과 달리 터널 밖으로 나간 조회가 점검 대상입니다. 확인할 때는 클라이언트가 시스템 DNS, 프록시 DNS, 암호화 DNS 또는 가상 DNS 중 무엇을 사용하는지 살펴보고 조회 경로가 분할 라우팅 목표와 일치하는지 확인해야 합니다.
| 증상 | 우선 확인할 항목 | 먼저 하면 안 되는 작업 |
|---|---|---|
| 노드는 표시되지만 연결되지 않음 | 프로토콜 호환성, 시스템 시간, 네트워크 권한과 회선 상태 | 같은 구독을 계속 반복해서 가져오기 |
| 브라우저는 되지만 다른 앱은 되지 않음 | 시스템 프록시, TUN 모드와 앱 자체 프록시 설정 | 구독 내용이 잘못되었다고 바로 판단하기 |
| 일부 도메인이 규칙대로 분할 라우팅되지 않음 | 규칙 순서, 도메인 확인과 캐시 | 규칙을 확인하지 않고 노드만 전환하기 |
| 업데이트 후 로컬 수정 내용이 사라짐 | 원격 설정의 적용 범위와 재정의 방식 | 새로고침으로 덮어써질 원격 노드를 계속 편집하기 |
| 업데이트 시 형식을 해석할 수 없다는 메시지가 표시됨 | 구독 유형과 클라이언트 지원 형식 | 파일 확장자만 변경하기 |
회선 선택도 사용 목적에 따라야 합니다. 직접 연결은 구조가 비교적 단순하지만 국제 구간이 공용 인터넷 라우팅의 영향을 더 크게 받습니다. 중계는 진입 경로를 개선할 수 있지만 중간 단계가 늘어나고, IEPL 전용 회선은 국제 구간의 전달 방식에 중점을 둡니다. 실제 사용에서는 먼저 분할 라우팅과 DNS 설정을 올바르게 구성한 뒤 회선별 차이를 비교해야 합니다. 한 번의 테스트에서 노드, 프로토콜, 인계 모드와 DNS를 동시에 바꾸면 무엇이 영향을 주었는지 판단하기 어렵습니다.
유출 후 재설정 및 복구 방법
구독 링크가 공개된 곳에 게시되었거나 관계없는 사람에게 전달되었거나 신뢰할 수 없는 변환 페이지에 입력되었거나 회수할 수 없는 로그에 남았다면 인증 정보 유출로 처리해야 합니다. 공개된 내용을 삭제하는 것만으로는 충분하지 않습니다. 링크가 이미 복사되거나 캐시되었을 수 있기 때문입니다. 로컬 클라이언트에서 설정을 삭제하는 것만으로도 기존 주소가 무효화되지는 않습니다.
- VPNGP 패널에 로그인해 구독 재설정 또는 재생성 메뉴를 사용하면 기존 주소를 무효화할 수 있습니다.
- 본인의 클라이언트에서 기존 원격 구독을 삭제해 백그라운드에서 폐기된 주소에 계속 요청하지 않도록 하세요.
- 새로 발급된 호환 형식의 링크를 받아 다시 가져온 뒤 설정이 정상적으로 업데이트되는지 확인하세요.
- 다른 개인 기기도 확인하고 기존 주소를 참조하는 설정을 모두 교체하세요.
- 브라우저 기록, 클립보드 동기화, 터미널 기록, 메모와 스크린샷에 남은 전체 기존 주소를 삭제하세요.
- 새 설정을 가져온 뒤 잘못된 설정을 그대로 사용하지 않도록 분할 라우팅, DNS와 로컬 재정의를 다시 확인하세요.
구독 재설정은 보통 설정에 접근하는 인증 정보만 바꾸며 클라이언트의 로컬 규칙을 자동으로 복구하지는 않습니다. 이전에 문제를 확인하려고 DNS, 시스템 프록시 또는 라우팅을 변경했다면 다시 가져온 후에도 항목별로 확인해야 합니다. 여러 기기에서 사용하는 경우 어느 한 기기를 빠뜨리면 업데이트 실패가 계속 표시될 수 있지만, 그렇다고 기존 링크를 복구해서는 안 됩니다.
로컬 구독을 실수로 삭제했을 뿐 링크가 외부에 노출되지 않았다면 보통 재설정할 필요 없이 패널에서 다시 복사해 가져오면 됩니다. 재설정의 기준은 ‘클라이언트에 남아 있는가’가 아니라 ‘전체 주소를 신뢰할 수 없는 제3자가 얻었을 가능성이 있는가’입니다. 이 기준을 적용하면 불필요한 설정 이전을 피하면서 실제 유출 시에는 기존 인증 정보를 신속히 차단할 수 있습니다.
자주 묻는 질문과 최종 점검
브라우저에서 구독 주소를 열면 문자만 잔뜩 표시되는데 정상인가요?
대체로 정상입니다. 구독 응답은 클라이언트를 대상으로 하므로 인코딩되어 있거나 YAML, JSON 또는 노드 링크 모음으로 직접 반환될 수 있어 브라우저에서 읽기 좋지 않을 수 있습니다. 중요한 것은 클라이언트가 해당 형식을 지원하는지, 가져온 후 정확히 해석하는지입니다. 내용을 ‘이해하기 위해’ 전체 응답을 온라인 디코딩 페이지에 입력하지 마세요.
구독 링크를 여러 클라이언트에 동시에 가져올 수 있나요?
사용 가능 여부는 서비스 규칙과 클라이언트 형식 호환성에 따라 달라집니다. 같은 주소를 여러 클라이언트에서 읽을 수 있더라도 정책 그룹, DNS, 규칙 제공자와 프로토콜 기능의 구현이 서로 다를 수 있습니다. 플랫폼을 이전할 때는 기존 주소가 모든 클라이언트에서 동일하게 작동한다고 가정하지 말고 패널에서 해당 형식을 다시 선택하는 것이 좋습니다.
업데이트 후 회선 수가 줄거나 이름이 바뀌는 이유는 무엇인가요?
원격 구독은 서버에서 현재 제공하는 설정을 반영합니다. 회선 유지보수, 진입점 조정, 이름 정리 또는 형식 변경으로 목록이 바뀔 수 있습니다. 먼저 업데이트 시간과 구독 출처를 확인한 뒤 패널 안내를 살펴보세요. 노드 수만으로 구독이 완전한지 판단하지 말고 오래된 캐시를 유효한 설정처럼 계속 사용하지도 마세요.
QR 코드와 텍스트 링크 중 어느 쪽이 더 안전한가요?
두 방식 모두 보통 같은 인증 정보를 담으며 위험도는 표시와 보관 방식에 따라 달라집니다. QR 코드는 화면에 포착되기 쉽고 텍스트는 클립보드, 기록과 동기화 도구에 남기 쉽습니다. 매체 자체를 단순 비교하기보다 중간 사본을 줄이는 방식을 선택하고 가져온 후 임시 데이터를 삭제하는 것이 중요합니다.
구독을 업데이트하면 현재 회선이 바뀌나요?
현재 회선이 새 설정에서 삭제되거나 이름이 바뀌거나 다른 정책 그룹에 포함되면 클라이언트가 기본 선택으로 돌아갈 수 있습니다. 회선이 계속 존재한다면 동작은 클라이언트가 업데이트를 병합하는 방식에 따라 달라집니다. 새로고침 후 현재 정책을 확인하고 업데이트 전 선택이 반드시 유지된다고 가정하지 마세요.
- ✅ 구독 출처와 형식이 클라이언트와 서로 일치합니다.
- ✅ 현재 설정이 활성화되어 있고 시스템 인계 방식이 앱 요구에 맞습니다.
- ✅ 분할 라우팅 규칙으로 어떤 요청이 직접 연결되고 어떤 요청이 회선을 통과하는지 설명할 수 있습니다.
- ✅ DNS 조회 경로가 분할 라우팅 목표와 일치합니다.
- ✅ 로컬 재정의와 원격 구독을 따로 저장해 업데이트 후 서로 덮어쓰지 않습니다.
- ✅ 전체 링크는 관리되는 위치에만 보관하고 노출되면 즉시 재설정합니다.