여러 구독을 관리할 때는 먼저 제공처별로 그룹을 나누고, 그룹 안에서 지역과 용도를 검색한 다음, 후보 서버만 속도 테스트하세요. 이 글에서는 목록 검색, 구독 가져오기 필터, 라우팅 규칙의 차이를 짚고 두 구독을 정리하는 단계, 업데이트 전후 점검법, 서버가 사라지거나 중복되거나 테스트 시간 초과가 발생했을 때의 대처 순서를 안내합니다. 구독 가져오기는 할 수 있지만 서버 목록 관리가 어려운 v2rayN 사용자에게 적합합니다.
구독 그룹, 서버 필터링, 라우팅 규칙의 차이
v2rayN의 구독 그룹은 서버의 출처를 관리하는 기능입니다. 그룹마다 구독 주소와 업데이트 설정을 저장하고, 업데이트할 때 해당 주소에서 받은 서버 정보를 클라이언트로 가져옵니다. 여러 VPN 업체의 구독은 각각 별도로 저장하세요. 모든 공유 링크를 하나의 수동 목록에 붙여 넣으면 서버 출처와 업데이트 대상 구독을 나중에 파악하기 어렵습니다.
그룹을 나눈다고 특정 웹사이트의 프록시 사용 여부가 정해지는 것은 아닙니다. 서버 목록 검색은 현재 표시되는 항목만 바꾸고, 구독 설정의 필터 옵션은 이번 가져오기 결과에 영향을 줄 수 있습니다. 라우팅 규칙은 앱의 요청을 프록시, 직접 연결, 차단 중 어떤 방식으로 처리할지 결정합니다. 각 기능은 서로 다른 단계에서 작동하므로 ‘업무용 그룹’을 만드는 것으로 도메인별 라우팅 설정을 대신할 수 없습니다.
| 작업 | 영향을 받는 대상 | 사용 사례 |
|---|---|---|
| 구독 그룹 전환 | 현재 확인할 구독 출처 | 주 구독과 예비 구독을 각각 관리 |
| 서버 목록 검색 | 현재 표시되는 서버 | 이름에 JP가 포함된 서버를 잠시 검색 |
| 구독 가져오기 필터 | 업데이트 후 유지할 항목 | 조건을 확인한 뒤 가져오는 항목 수 줄이기 |
| 라우팅 규칙 | 실제 요청에 사용할 아웃바운드 선택 | 특정 도메인을 직접 연결하거나 프록시로 연결 |
먼저 구독 출처별 그룹 두 개를 만들고 각각 업데이트
먼저 출처를 명확히 구분할 수 있는 두 그룹부터 정리하세요. 예를 들어 자주 쓰는 구독은 ‘주-A’, 다른 구독은 ‘예비-B’로 지정합니다. 이 이름은 관리 용도일 뿐, 클라이언트가 자동으로 장애 조치한다는 뜻은 아닙니다. 같은 업체의 서로 다른 요금제 구독도 실제 구독 주소에 따라 나눠 두면 잘못 업데이트하는 일을 막을 수 있습니다.
- ‘구독 그룹’ → ‘구독 그룹 설정’을 열고 그룹을 추가한 뒤 ‘주-A’와 해당 구독 주소를 입력합니다. 저장하기 전에 주소가 계정 로그인 페이지가 아니라 서비스 제공업체의 클라이언트 구독 메뉴에서 받은 것인지 확인하세요.
- 같은 방법으로 ‘예비-B’를 추가합니다. 처음 설정할 때는 기본 가져오기 방식을 그대로 두고 필터 조건은 설정하지 마세요. 그래야 서비스 제공업체가 지정한 원래 서버 이름을 확인할 수 있습니다.
- 저장한 뒤 ‘주-A’로 전환하고 구독 그룹 메뉴에서 현재 구독 업데이트를 선택합니다. ‘모두 업데이트’도 제공된다면, 첫 업데이트는 현재 그룹만 대상으로 해야 실패한 출처를 쉽게 찾을 수 있습니다.
- 목록에 서버가 표시되는지 확인한 다음 ‘예비-B’로 전환해 같은 작업을 반복합니다. 실패하더라도 그룹을 계속 추가하지 말고 먼저 업데이트 로그를 확인하세요.
- 각 그룹에서 대표 서버의 이름, 지역 표시, 프로토콜 종류를 기록해 주소를 서로 바꿔 입력했거나 같은 구독을 중복 등록하지 않았는지 확인합니다.
주-A
- 출처
- 일상적으로 사용하는 구독 주소
- 이름
- ‘주’ 접두어 고정
- 첫 업데이트
- 현재 그룹만 업데이트
- 초기 필터 설정
- 가져오기 필터는 일단 설정하지 않음
먼저 전체 서버를 문제없이 가져왔는지 확인한 뒤 범위를 좁히세요.
예비-B
- 출처
- 별도의 구독 주소
- 이름
- ‘예비’ 접두어 고정
- 첫 업데이트
- 업데이트 로그를 따로 확인
- 사용 방법
- 필요할 때 서버를 수동으로 전환
그룹 이름만으로는 부하 분산이나 예비 서버 전환이 자동 설정되지 않습니다.
구독 주소에는 계정 관련 토큰이 포함되는 경우가 많으므로 계정 자격 증명처럼 다뤄야 합니다. 스크린샷을 공유할 때는 전체 주소와 QR 코드, 계정 정보가 담긴 매개변수를 가리세요. 문제를 확인하는 데는 오류 유형, 메뉴 위치, 민감한 정보를 가린 서버 이름만 있으면 됩니다. 실제로 사용할 수 있는 구독 주소를 공개할 필요는 없습니다. 설정을 옮기기 전에는 내보내기 파일에 이런 정보가 포함되는지도 확인하세요.
키워드로 서버 필터링하기: 먼저 검색하고 가져오기 필터는 나중에 설정
서버 이름에는 정해진 표준이 없습니다. 같은 지역도 ‘일본’, ‘JP’, ‘Tokyo’ 등으로 표시될 수 있고, 서비스 제공업체가 이름에 배율, 회선 종류, 만료 알림을 덧붙이기도 합니다. 먼저 대상 그룹으로 전환한 뒤 서버 목록의 검색 또는 필터 입력란에 키워드를 하나씩 넣어 보세요. 복잡한 규칙을 바로 작성하는 것보다 실제로 적용되는지 확인하기 쉽습니다.
- 지역 키워드: 먼저 ‘일본’을 검색하고 결과가 없으면 입력란을 비운 뒤
JP또는Tokyo를 검색하세요. 결과가 없다는 것은 현재 검색 조건에 일치하는 항목이 없다는 뜻이지, 구독에 해당 지역 서버가 없다는 뜻은 아닙니다. - 용도 키워드: 서비스 제공업체가 서버 이름에 실제로 표시한 경우에만 ‘전용 회선’, ‘스트리밍’ 등의 키워드를 검색하세요. 서버 이름에 붙은 표시는 해당 용도의 연결이 실제로 작동하는지 확인하는 절차를 대신할 수 없습니다.
- 배율 키워드: 이름에
0.5x또는2x가 있다면 요금 계산에 어떤 의미인지 서비스 제공업체에 먼저 확인한 뒤 유지할 항목을 정하세요. 숫자만으로 속도를 보장하지는 않습니다. - 알림 항목: 이름에 ‘잔여 트래픽’이나 ‘만료일’이 포함된 항목은 구독 정보를 표시하는 용도일 수 있습니다. 일반 서버와 함께 속도 테스트하거나 사용 중인 서버로 지정하지 마세요.
검색창이 정규식을 지원한다고 가정하거나 공백이 ‘모두 일치’를 뜻한다고 단정하지 마세요. 일반 키워드 검색과 구독 설정의 정규식 필터는 구현 방식이 다를 수 있습니다. JP|일본을 입력해도 결과가 없다면 인터페이스가 세로 막대를 일반 문자로 처리했을 수 있습니다. 먼저 키워드 하나로 검색이 되는지 확인한 뒤 현재 버전의 해당 입력란 설명을 살펴보세요.
| 원하는 결과 | 먼저 할 일 | 피해야 할 잘못된 조작 |
|---|---|---|
| 일본 서버만 잠시 보기 | 대상 그룹에서 실제 지역 이름 검색 | 다른 지역 서버를 바로 삭제 |
| 업데이트 후에도 특정 이름의 서버만 가져오기 | 구독 필터의 일치 규칙 확인 | 검색 표현식을 필터 입력란에 그대로 복사 |
| 전체 목록 복원 | 검색어를 지우고, 필요하면 가져오기 필터를 제거한 뒤 다시 업데이트 | 필터 조건을 확인하지 않고 클라이언트만 다시 시작 |
| 프로토콜별 서버 선택 | 목록의 프로토콜 열과 설정 세부 정보 확인 | 비고에 VMess 또는 VLESS라고 적힌 것만 보고 판단 |
현재 버전에서 구독 필터 입력란을 제공한다면, 먼저 ‘일치하는 항목 유지’인지 ‘일치하는 항목 제외’인지 확인하세요. 기존 조건을 따로 기록한 다음 수정해야 합니다. 가져오기 필터는 목록에 반영하려면 구독을 다시 업데이트해야 하는 경우가 많습니다. 목록에서 구독 서버를 직접 삭제해도 다음 업데이트 때 다시 나타날 수 있습니다. 항목을 장기간 줄이려면 직접 지우기를 반복하지 말고 조건을 명확하게 설정하고 다시 확인할 수 있는 필터를 사용하세요.
그룹별 속도 테스트: 후보 범위를 좁힌 뒤 비교
구독을 가져오자마자 모든 서버를 한꺼번에 테스트하지 마세요. 대량 동시 테스트는 로컬 대역폭을 차지하고 서비스 측 연결 제한을 유발할 수 있어 결과를 비교하기 어려워집니다. 먼저 후보를 소수로 좁힌 뒤 목록에서 테스트할 행을 직접 선택하고 서버 메뉴나 마우스 오른쪽 버튼 메뉴에서 해당 테스트를 실행하세요. 화면에 보이는 서버가 모두 테스트 대상으로 선택된 것은 아닙니다.
아래 수치는 정리 절차를 위한 권장 규모이지 성능 테스트 결과가 아닙니다. 매번 같은 네트워크와 테스트 대상을 사용하고, 가능하면 파일 다운로드를 동시에 하지 마세요. 서로 다른 시간대의 결과를 비교하려면 지연 시간 숫자만 적지 말고 테스트 시각도 기록하세요.
- 먼저 포트 연결 확인: TCP 지연 시간은 서버 포트에 연결되는 상태를 주로 나타냅니다. 서버 포트가
443이고 연결에 성공해도 프로토콜 인증, TLS 설정, 대상 사이트 접속이 정상이라는 뜻은 아닙니다. - 그다음 실제 요청 확인: 클라이언트에서 실제 연결 지연 시간을 테스트할 수 있다면 테스트 대상을 기록하세요. 프록시 핸드셰이크, 원격 서버 접속, 대상 사이트 응답에 영향을 받으므로 TCP 지연 시간과 같은 지표로 직접 비교하면 안 됩니다.
- 필요할 때만 다운로드 속도 테스트: 속도 테스트는 트래픽을 사용합니다. 후보를 소수로 고르고 서비스 제공업체의 요금 규칙을 확인한 뒤 실행하세요. 순위를 매기려고 그룹 전체를 반복 테스트하지 마세요.
- 마지막으로 실제 사용 확인: 서버를 사용 중으로 직접 지정하고 실제로 접속할 사이트나 앱을 열어 로그인, 로딩, 지속적인 사용이 가능한지 살펴보세요.
결론: 요청이 안정적으로 완료되는 서버를 우선 선택
실제 요청이 여러 차례 연속으로 성공한 서버가 지연 시간이 한 번 낮게 나온 서버보다 우선입니다. 사용할 서버를 확인한 다음 필터를 해제하세요. 목록에서 첫 번째로 정렬된 서버가 현재 사용 중인 서버라고 착각하지 않도록 주의하세요.
구독 업데이트 방법: 출처와 점검 기록을 유지
구독 업데이트는 서비스 제공업체가 현재 제공하는 데이터를 가져오는 기능이지, 로컬에서 수정한 내용을 모두 보존하는 기능은 아닙니다. 서버 메모, 주소, 포트 및 기타 매개변수가 업데이트로 바뀔 수 있습니다. 직접 수정한 설정을 장기간 유지하려면 별도의 수동 관리 그룹을 만들고, 이 복사본은 원래 구독의 변경 사항을 자동으로 반영하지 않는다는 점을 기억하세요.
- 업데이트 전: 현재 사용 중인 서버의 그룹과 이름을 기록하세요. 중요한 회의나 데이터 전송 중에는 다른 작업을 하다가 여러 그룹을 한꺼번에 업데이트하고 서버까지 전환하지 마세요.
- 업데이트 중: 문제가 발생한 현재 그룹부터 업데이트하세요. 직접 연결 업데이트와 프록시를 통한 업데이트를 모두 제공한다면 구독 주소에 접근할 수 있는 방식으로 선택하세요. 서버 접속이 실패한다고 해서 구독 주소에도 직접 연결할 수 없다고 단정하면 안 됩니다.
- 업데이트 후: 성공 또는 실패 로그를 확인하고 검색어를 지운 뒤 서버가 정상적으로 가져와졌는지 확인하세요. 이어서 현재 사용 중인 서버가 여전히 목록에 있고 작동하는지도 점검하세요.
- 정기 관리: 현재 버전에서 자동 업데이트 간격을 설정할 수 있다면 서비스 제공업체의 변경 주기와 실제 사용량을 고려해 설정하세요. 변경이 잦지 않다면 분 단위로 업데이트할 필요는 없습니다.
이름이 같다고 같은 서버라고 단정할 수 없습니다. 비교할 때는 출처, 서버 주소, 포트, 프로토콜, 전송 매개변수를 확인하세요. 이름이 같은 두 그룹도 서로 다른 계정에 연결될 수 있습니다. 반대로 같은 구독 주소를 두 번 추가했다면 먼저 정리해야 할 중복입니다. 메모만 보고 일괄 삭제하면 설정이 다른 유효한 서버까지 지울 수 있습니다.
자주 묻는 문제: 서버가 사라지거나 업데이트가 반영되지 않거나 그룹 테스트가 실패할 때
업데이트는 성공했는데 목록에 서버가 하나도 없어요. 무엇부터 확인해야 하나요?
먼저 서버 목록의 검색어를 지우고 업데이트한 그룹으로 전환하세요. 그래도 목록이 비어 있다면 구독 필터가 너무 엄격한지, 로그에 파싱 오류가 표시되는지 확인하세요. 웹페이지 내용을 가져왔다고 해서 유효한 구독을 받은 것은 아닙니다. 로그인 페이지나 계정 만료 안내 페이지도 성공 상태를 반환할 수 있습니다. 서비스 제공업체가 안내한 올바른 구독 주소를 다시 확인하세요. ‘다운로드 성공’만으로 가져오기가 완료됐다고 판단하면 안 됩니다.
업데이트 후 목록이 그대로인데, 업데이트에 실패한 건가요?
꼭 그렇지는 않습니다. 서비스 제공업체가 반환한 데이터에 변화가 없으면 목록이 그대로인 것이 정상입니다. 먼저 이번 업데이트 로그와 올바른 그룹을 선택했는지 확인한 뒤 검색 조건이 남아 있는지 살펴보세요. 새 서버가 실제로 추가됐는데 표시되지 않는다면 가져오기 필터를 확인하세요. 목록에 변화가 생기도록 같은 구독을 반복해서 추가하지 마세요.
그룹에 있는 서버가 전부 시간 초과되면 구독을 바로 삭제해야 하나요?
먼저 테스트 종류, 시스템 시간, 로컬 네트워크를 확인한 다음 다른 그룹의 정상 작동이 확인된 서버와 비교하세요. 그룹 전체가 동시에 실패한다면 계정 만료, 서비스 제공업체 장애, 프로토콜 매개변수 또는 테스트 대상이 원인일 수 있습니다. TCP 테스트는 성공하지만 실제 요청이 실패한다면 핵심 로그에서 인증 또는 핸드셰이크 정보를 더 확인하세요. 그룹을 다시 만드는 것만으로는 연결 매개변수 문제가 해결되지 않습니다.
‘예비-B’ 그룹으로 전환하면 트래픽이 자동으로 예비 서버를 사용하나요?
그룹 전환은 보통 목록 보기를 바꾸는 기능입니다. 서버를 사용 중으로 지정하는 작업을 직접 실행하고 클라이언트에 표시된 현재 서버를 확인해야 합니다. 시스템 프록시 활성화 여부, 앱의 프록시 사용 여부, 라우팅 선택도 각각 별도로 작동합니다. 브라우저와 터미널의 동작이 다르면 구독 그룹을 계속 바꾸지 말고 각 환경의 프록시 설정을 따로 확인하세요.
정리가 끝나면 평소에는 출처 확인, 현재 그룹 업데이트, 검색 조건 삭제, 후보 필터링, 사용 중인 서버 확인 순서만 반복하면 됩니다. 도메인별 직접 연결이나 프록시를 추가로 설정하려면 고급 설정에서 라우팅 안내를 확인하세요. 그룹은 서버를 정리하고 라우팅은 요청을 올바른 아웃바운드로 보냅니다.