구독 링크는 클라이언트 설치 파일도, 특정 단일 회선도 아닙니다. 취소할 수 있는 설정 키에 가깝습니다. 클라이언트가 링크에 접속하면 서버가 현재 제공하는 노드, 프로토콜 매개변수와 그룹 정보를 가져온 뒤 선택 가능한 회선으로 변환합니다. 이 원리를 이해하면 가져오기 실패, 업데이트 미반영, 링크 유출을 같은 흐름으로 점검할 수 있습니다.
많은 사용 문제는 개념이 뒤섞여서 발생합니다. 구독 링크를 계정과 비밀번호로 생각하거나, 노드 주소를 구독 링크로 착각하는 경우가 있습니다. 가져오기에 성공하면 모든 트래픽이 예상대로 전달된다고 여기는 경우도 있습니다. 실제로는 설정 가져오기, 설정 파싱, 노드 선택, 연결 수립, 분할 라우팅, DNS 조회가 연속해서 진행되지만 서로 독립적인 단계입니다.
구독 링크에는 무엇이 들어 있을까
서버가 반환하는 내용은 클라이언트 형식에 따라 달라집니다. 인코딩된 텍스트인 경우도 있고 구조화된 설정인 경우도 있으며, 클라이언트 유형에 맞는 형식을 동적으로 생성하는 서비스도 있습니다. 인코딩은 내용의 표현 방식만 바꿀 뿐 암호화를 의미하지 않으며, 링크 자체의 접근 권한을 자동으로 없애지도 않습니다.
사용 가능한 구독에는 보통 노드 이름, 서버 주소, 포트, 프로토콜, 인증 매개변수, 전송 방식, TLS 관련 설정이 포함됩니다. 클라이언트는 이를 읽어 노드 목록이나 정책 그룹으로 표시합니다. 링크 자체에 구독 권한을 식별하는 토큰이 들어 있을 수도 있습니다. 이 토큰이 폐기되면 기존 링크로는 새 설정을 계속 가져올 수 없습니다.
| 대상 | 역할 | 흔한 오해 | 올바른 처리 |
|---|---|---|---|
| 구독 링크 | 서버에서 설정 묶음을 가져옴 | 일반 웹 주소로 생각함 | 자격 증명으로 관리하고 공개 전달하지 않음 |
| 단일 노드 링크 | 하나의 연결 진입점을 설명함 | 모든 회선을 자동으로 동기화한다고 생각함 | 전체 목록이 필요하면 구독을 가져옴 |
| 클라이언트 설정 | 노드, 정책 및 로컬 옵션을 저장함 | 구독을 삭제하면 원격 권한도 함께 취소된다고 생각함 | 유출 시 서버에서도 재설정함 |
| 프로토콜 | 클라이언트와 진입점의 통신 방식을 정함 | 프로토콜 이름을 회선 품질의 판단 기준으로 삼음 | 네트워크 환경과 회선 경로를 함께 확인함 |
| 분할 라우팅 규칙 | 각 요청이 어느 경로로 갈지 결정함 | 규칙 매칭 문제를 노드 연결 끊김으로 생각함 | 모드, 규칙 및 최종 출구를 확인함 |
Shadowsocks, VMess, Trojan, VLESS, Hysteria2 및 TUIC는 클라이언트가 인식할 수 있는 프로토콜 또는 전송 방식이지만, 구독 링크 자체가 이 프로토콜인 것은 아닙니다. 링크는 설정을 전달하고 프로토콜은 실제 연결을 수립합니다. 어떤 클라이언트가 구독을 열 수 있다고 해서 구독에 포함된 모든 프로토콜 필드를 지원한다는 뜻은 아닙니다. 호환되지 않으면 노드가 사라지거나 유효하지 않은 것으로 표시되거나, 연결 단계에서 오류가 발생할 수 있습니다.
어디서 가져오고 출처를 확인하는 방법
신뢰할 수 있는 경로는 서비스 패널의 구독 또는 클라이언트 다운로드 영역이어야 합니다. 로그인한 뒤 시스템이 생성한 링크를 복사하거나 패널에서 제공하는 클라이언트 가져오기 기능을 사용하세요. 검색 결과, 전달받은 메시지 또는 이른바 설정 모음에서 같은 이름의 링크를 찾지 마세요. 노드 이름이 같아 보여도 해당 설정이 원래 서비스에서 제공된 것인지는 확인할 수 없습니다.
복사할 때는 전체 주소를 유지해야 합니다. 메신저가 긴 텍스트를 접거나, 브라우저가 매개변수를 자동으로 정리하거나, 복사한 내용 앞뒤에 공백이 붙으면 토큰이 누락될 수 있습니다. 패널에서 일반 구독과 특정 클라이언트 형식을 모두 제공한다면 현재 클라이언트에 맞는 형식을 우선 선택해 타사 변환 사이트 의존을 피하세요.
- ✅ 로그인된 서비스 패널에서 구독 또는 클라이언트 다운로드 영역으로 이동하세요.
- ✅ 도메인이 현재 서비스와 일치하는지 확인한 뒤 전체 링크를 복사하세요.
- ✅ 클라이언트가 직접 인식할 수 있는 구독 형식을 우선 사용하세요.
- ✅ 가져온 뒤 노드 이름, 프로토콜 및 그룹이 모두 표시되는지 확인하세요.
- ❌ 링크를 온라인 디코딩, 변환 또는 속도 측정 페이지에 붙여 넣지 마세요.
- ❌ 전체 링크나 QR 코드가 포함된 페이지를 스크린샷으로 저장하지 마세요.
플랫폼별 클라이언트 가져오기 방법
클라이언트마다 화면은 다르지만 가져오기 과정은 같은 확인 단계로 나눌 수 있습니다. 호환 형식을 확인하고, 구독 항목을 만든 뒤 수동 업데이트를 실행하고, 노드를 선택하고, 시스템 프록시 또는 터널을 활성화한 다음 출구를 확인하세요. 첫 업데이트를 건너뛰지 마세요. 일부 클라이언트는 새 구독을 만들 때 주소만 저장하고 내용을 즉시 가져오지 않습니다.
Windows 및 macOS
- 클라이언트의 구독, 설정 또는 설정 파일 관리 페이지를 여세요.
- URL에서 추가를 선택하고 패널에서 복사한 전체 링크를 입력란에 붙여 넣으세요.
- 구독을 쉽게 구분할 수 있는 로컬 이름을 지정하되 토큰을 이름에 넣지 마세요.
- 저장한 뒤 업데이트를 실행하고 목록에 예상한 회선과 프로토콜이 표시되는지 확인하세요.
- 노드와 실행 모드를 선택한 다음 시스템 프록시 또는 시스템 터널을 활성화하세요.
- IP 조회 페이지를 열고 DNS 결과를 확인해 트래픽 경로가 분할 라우팅 예상과 일치하는지 점검하세요.
데스크톱 클라이언트는 보통 시스템 프록시와 가상 네트워크 어댑터 모드를 함께 제공합니다. 시스템 프록시는 시스템 프록시 설정을 따르는 앱의 트래픽을 주로 가로채고, 가상 네트워크 어댑터 모드는 더 많은 트래픽을 처리할 수 있지만 보안 소프트웨어, 다른 네트워크 도구 또는 기존 라우팅과 충돌하기 쉽습니다. 구독을 가져온 뒤에도 접속할 수 없다면 먼저 클라이언트가 어떤 트래픽 처리 방식을 사용하는지 확인하세요.
Android 및 iOS
- 서비스 패널에서 구독 링크를 복사하거나 신뢰할 수 있는 기기 사이에서 직접 전달하세요.
- 클라이언트의 설정 관리 페이지로 들어가 클립보드, URL 또는 QR 코드에서 가져오기를 선택하세요.
- 클라이언트가 시스템 VPN 설정을 만들도록 허용하고 현재 활성화된 설정이 새로 가져온 것인지 확인하세요.
- 구독을 수동으로 업데이트하고 현재 버전이 해당 프로토콜을 지원하는지 확인하세요.
- 연결한 뒤 프록시가 필요한 대상과 직접 연결되어야 하는 대상을 각각 테스트해 분할 라우팅 결과를 확인하세요.
모바일 플랫폼은 보통 시스템이 제공하는 VPN 인터페이스를 통해 트래픽을 처리합니다. 절전, 네트워크 전환 또는 백그라운드 제한으로 클라이언트 활동이 중단될 수 있으므로 “노드는 있지만 잠시 후 끊김”이 반드시 구독 만료를 뜻하지는 않습니다. 먼저 클라이언트에서 터널 상태와 오류 기록을 확인한 뒤 구독 업데이트 여부를 결정하세요.
Linux 및 라우터 장치
Linux 클라이언트는 그래픽 인터페이스를 제공할 수도 있고 설정 파일을 직접 읽을 수도 있습니다. 가져오기 전에 핵심 프로그램이 구독에 포함된 프로토콜과 전송 필드를 지원하는지 확인해야 합니다. 라우터 장치에서는 저장 공간, 커널 기능, DNS 전달과 로컬 네트워크 분할 라우팅도 추가로 고려해야 합니다. 데스크톱에서 사용할 수 있는 완전한 설정이 라우터 환경에 그대로 들어간다고 보장할 수는 없습니다.
라우터 장치에서 구독을 업데이트한 뒤에는 새 파일을 다운로드하기만 한 것이 아니라 규칙이 다시 로드되었는지 확인해야 합니다. 이전 프로세스가 계속 실행 중이면 화면에는 새 노드가 표시되어도 실제 연결은 기존 설정을 사용할 수 있습니다. 이때는 장치 관리 화면의 정상적인 절차에 따라 설정을 적용하거나 서비스를 다시 로드하세요. 같은 링크를 계속 반복해서 가져오지는 마세요.
얼마나 자주 업데이트해야 할까
구독에는 모두에게 적용되는 고정 업데이트 주기가 없습니다. 노드 이름, 진입점, 인증 매개변수 또는 그룹이 변경되면 서버가 새 설정을 게시하며, 클라이언트가 다시 가져와야 변경 사항이 표시됩니다. 반대로 연결이 안정적이고 서버에 변경이 없다면 자주 새로 고쳐도 회선이 자동으로 빨라지지는 않습니다.
더 실용적인 방법은 이벤트가 있을 때 업데이트하는 것입니다. 처음 가져온 후 업데이트하고, 서비스 패널에서 회선 변경이 공지된 후 업데이트하세요. 여러 노드에서 동시에 인증 또는 조회 오류가 발생할 때도 업데이트하고, 기기를 바꾸거나 클라이언트를 다시 설치한 뒤에는 다시 가져와 업데이트하세요. 단일 노드에 일시적으로 연결할 수 없다면 먼저 같은 구독의 다른 회선으로 전환해 전체 구독이 만료된 것으로 오해하지 않도록 하세요.
클라이언트의 “자동 업데이트”는 보통 정해진 시간에 원격 링크에 접속하는 기능일 뿐입니다. 호환되지 않는 프로토콜을 자동으로 수정하거나 분할 라우팅 규칙을 대신 결정하지는 않습니다. 클라이언트가 장시간 절전 상태이거나 백그라운드 제한을 받거나 시스템 시간이 잘못되어 있으면 자동 업데이트가 실행되지 않을 수 있습니다. 이때는 연결을 반복해서 껐다 켜기보다 수동으로 새로 고치고 업데이트 시각을 확인하는 편이 효과적입니다.
업데이트 실패 원인 찾기
업데이트 실패는 “구독을 가져오지 못함”과 “가져왔지만 파싱에 실패함”으로 나눠야 합니다. 전자는 불완전한 링크, 만료된 토큰, 도메인 조회 오류 또는 현재 네트워크에서 구독 진입점에 접속할 수 없는 경우에 흔합니다. 후자는 클라이언트 형식, 프로토콜 필드, 설정 문법 또는 클라이언트 버전과 관련된 경우가 많습니다.
- 원본 링크를 확인하세요. 서비스 패널로 돌아가 다시 복사하고 문자를 직접 덧붙이지 마세요. 메신저 기록에 남은 이전 링크도 사용하지 마세요.
- 구독 진입점을 확인하세요. 클라이언트 오류가 네트워크 요청 실패인지, 인증 실패인지, 아니면 콘텐츠 형식을 인식하지 못한 것인지 살펴보세요.
- 클라이언트 호환성을 확인하세요. 현재 핵심 프로그램이 구독에 포함된 Shadowsocks, VMess, Trojan, VLESS, Hysteria2 또는 TUIC 설정을 지원하는지 확인하세요.
- 캐시를 지운 뒤 다시 시도하세요. 먼저 로컬에서 만료된 구독 항목을 삭제한 다음 패널에서 다시 추가하세요. 구독 이름만 바꿔서는 권한이 새로 고쳐지지 않습니다.
- 네트워크 변수를 줄이세요. 다른 프록시 설정을 일시 중지해 기존 시스템 프록시, 가상 네트워크 어댑터 또는 DNS 도구가 경로를 선점하지 않도록 하세요.
- 사용 가능한 설정을 보존하세요. 점검 중에는 정상 노드를 모두 먼저 삭제하지 마세요. 패널에 접속하는 데 필요한 연결까지 잃을 수 있습니다.
구독은 업데이트되지만 일부 노드가 표시되지 않는다면 형식과 프로토콜 지원을 중점적으로 확인하세요. 오래된 클라이언트는 낯선 필드를 무시할 수 있으며, 클라이언트마다 정책 그룹, 전송 계층과 인증서 설정의 이름이 다를 수 있습니다. 노드 이름이 보이는지만으로 판단하지 말고 로그에 파싱 건너뛰기나 필드 미지원 메시지가 있는지도 확인하세요.
모든 노드가 표시되지만 연결할 수 없다면 문제는 구독 다운로드 단계를 벗어난 것입니다. 시스템 시간, 프로토콜 핸드셰이크, 현재 네트워크의 UDP 조건, TLS 도메인, 프록시 모드와 로컬 방화벽을 확인해야 합니다. Hysteria2와 TUIC는 UDP 경로의 영향을 크게 받으며, Trojan과 일부 VLESS 설정은 올바른 TLS 매개변수에 의존할 수 있습니다. 오류를 피하려고 구독 필드를 함부로 삭제하지 마세요. 설정을 가져오는 것처럼 보여도 실제 연결이 수립되지 않을 수 있습니다.
회선 유형, 프로토콜과 구독의 관계
IEPL 전용 회선, 중계 및 직접 연결은 네트워크 경로를 설명하는 말이지 구독 형식이나 프로토콜 이름이 아닙니다. 직접 연결은 보통 로컬 네트워크가 원격 진입점에 직접 접속하고, 중계는 먼저 중간 진입점에 들어간 뒤 목적 지역으로 전달합니다. IEPL 전용 회선은 특정 국제 전송 경로를 강조합니다. 클라이언트가 이 회선을 사용하려면 먼저 구독을 통해 진입점과 프로토콜 매개변수를 가져와야 합니다.
따라서 구독 형식을 바꾼다고 직접 연결이 전용 회선으로 바뀌지는 않으며, 프로토콜을 바꾼다고 서버의 물리적 경로가 자동으로 달라지지도 않습니다. 프로토콜은 연결의 캡슐화, 인증과 전송 방식을 정하고 회선 유형은 데이터가 통과하는 네트워크 구간을 결정합니다. 야간에 속도가 흔들릴 때는 경로 품질과 클라이언트 프로토콜을 분리해서 관찰해야 합니다.
분할 라우팅 규칙은 또 다른 계층에 있습니다. 규칙에 따라 로컬 서비스는 직접 연결하고 국제 웹사이트는 지정 노드를 사용하게 하거나, 도메인·IP·앱별로 출구를 정할 수 있습니다. 규칙이 잘못 매칭되면 노드가 정상이어도 접속 결과가 예상과 다를 수 있습니다. 점검할 때는 대상 요청이 어떤 규칙에 매칭되었는지 확인해야 하며, 대상이 노드를 거치지 않았다는 이유만으로 구독을 업데이트해서는 안 됩니다.
DNS 유출 및 분할 라우팅 점검
구독 가져오기가 끝나도 DNS는 여전히 로컬 네트워크가 처리할 수 있습니다. 이 경우 연결은 이미 수립되었지만 도메인 조회는 다른 경로로 나갈 수 있습니다. DNS 유출 점검은 웹페이지에 표시된 출구 IP뿐 아니라 조회 요청을 누가 처리하고 어디에서 전송하는지 확인합니다.
클라이언트가 시스템 프록시를 사용하면 일부 앱이 계속 시스템 DNS를 사용할 수 있습니다. 가상 네트워크 어댑터 모드에서는 보통 클라이언트가 조회를 더 완전히 처리할 수 있지만, DNS 설정과 라우팅 규칙이 올바르다는 전제가 필요합니다. 브라우저 자체의 암호화 DNS, 시스템 캐시와 로컬 네트워크 게이트웨이도 결과에 영향을 줍니다.
- ✅ 연결 전후에 출구 IP와 DNS 조회 출처를 각각 확인하세요.
- ✅ 클라이언트가 현재 모드에 맞는 DNS 설정을 활성화했는지 확인하세요.
- ✅ 대상 도메인이 프록시 규칙과 직접 연결 규칙 중 어디에 매칭되었는지 확인하세요.
- ✅ 규칙을 수정한 뒤 로컬 DNS 캐시를 지우고 다시 테스트하세요.
- ❌ 출구 IP가 바뀌었다고 모든 DNS 요청이 처리되고 있다고 단정하지 마세요.
- ❌ 서로 충돌하는 여러 시스템 프록시와 터널 설정을 동시에 활성화하지 마세요.
특정 웹사이트가 잘못된 회선을 사용한다면 먼저 전체 프록시 모드로 임시 전환해 비교해 볼 수 있습니다. 전체 모드에서는 정상이고 규칙 모드에서만 문제가 발생한다면 보통 노드와 프로토콜은 작동하며, 문제는 규칙 매칭이나 DNS 조회에 집중되어 있습니다. 비교가 끝나면 필요한 모드로 돌아가 규칙을 수정하고, 전체 모드로 설정 오류를 장기간 가리지 마세요.
링크 유출 후 즉시 해야 할 일
링크가 공개된 뒤에는 로컬 클라이언트에서 삭제하는 것만으로 충분하지 않습니다. 삭제는 현재 기기의 기록만 지울 뿐, 이미 링크를 복사한 사람이 계속 설정을 요청하는 것을 막지 못합니다. 올바른 조치는 서비스 패널에서 기존 구독을 폐기하고 구독 링크를 재설정하거나 접근 토큰을 새로 생성해 기존 주소를 무효화하는 것입니다.
- 더 이상 전달하지 마세요. 공개 메시지, 공유 문서와 스크린샷에서 링크를 삭제하되, 도움을 요청한다며 다른 플랫폼에 다시 붙여 넣지는 마세요.
- 원격 권한을 폐기하세요. 서비스 패널에서 구독 재설정 또는 토큰 업데이트를 실행하고 기존 링크가 더 이상 유효한 설정을 반환하지 않는지 확인하세요.
- 로컬의 기존 기록을 삭제하세요. 각 클라이언트에서 기존 구독을 삭제해 자동 업데이트가 이전 주소로 계속 요청하지 않도록 하세요.
- 새 링크를 가져오세요. 패널에서 다시 복사해 설정을 업데이트하고 노드와 프로토콜이 완전하게 표시되는지 확인하세요.
- 다른 기기도 확인하세요. 기존 구독을 사용하는 모든 기기를 교체해야 하며 현재 기기만 처리해서는 안 됩니다.
- 분할 라우팅과 DNS를 다시 확인하세요. 다시 가져오면 클라이언트 기본 설정이 복원될 수 있으므로 규칙, 시스템 프록시와 조회 경로를 다시 점검하세요.
유출된 내용이 단일 노드 설정뿐이더라도 서비스 패널에서 제공하는 방식에 따라 관련 인증 정보를 업데이트해야 합니다. 아무도 링크를 사용하지 않을 것이라고 가정하지 말고, 노드 이름이 바뀌었는지만으로 권한 폐기 여부를 판단하지 마세요. 노드 이름 변경은 표시만 바꿀 뿐이며, 기존 설정으로 계속 연결할 수 있는지는 인증 매개변수가 업데이트되었는지에 달려 있습니다.