여러 서비스 구독 관리 실전: v2rayN 구독 그룹과 서버 키워드 필터링

여러 구독을 한꺼번에 가져온 뒤 실제 사용 효율을 좌우하는 것은 노드 수보다 노드 출처, 지역, 배율, 용도가 한 서버 목록에 뒤섞여 있는지 여부입니다. 한 구독에는 홍콩·싱가포르·일본 등 자주 쓰는 회선이 포함되고, 다른 구독에는 주로 예비 회선이 들어 있을 수 있습니다. 전체 항목을 그대로 펼쳐 두면 한 번 업데이트할 때마다 이름이 비슷한 서버가 수백 개씩 생겨 수동으로 찾거나 속도를 측정하기가 어려워집니다.

먼저 구독 출처별로 고정 그룹 만들기

구독 그룹의 가장 중요한 역할은 출처를 분리해 보존하는 것입니다. 노드 이름은 바뀌고 지역 수는 업데이트에 따라 늘거나 줄 수 있지만, “이 기록이 어느 구독에서 왔는가”는 항상 분명해야 합니다. “서비스 제공업체 약칭 + 용도” 형식을 권장합니다. 예를 들어 “클라우드A-일상”, “클라우드B-예비”, “클라우드C-저배율”처럼 지정하고 “구독1”, “구독2”만 쓰는 방식은 피하세요. 반년 뒤 끊어진 링크를 점검할 때 이름이 명확하면 설정 페이지를 반복해서 열어 주소를 확인하는 일을 크게 줄일 수 있습니다.

v2rayN 7.15 계열 화면을 예로 들면 「구독 그룹」→「구독 그룹 설정」으로 이동해 각 출처의 별칭, 구독 주소, 활성화 상태, 자동 업데이트 간격을 따로 입력할 수 있습니다. 세 개의 구독을 하나의 주소 필드에 합쳐 붙여 넣거나, 같은 주소로 중복 그룹을 여러 개 만드는 것은 좋지 않습니다. 저장한 뒤 그룹별로 업데이트를 실행하고, 각 그룹에서 독립적으로 서버가 생성되는지 확인한 다음 전체 업데이트 일정을 정하세요.

그룹 필드 권장값

포함·제외 키워드로 노드 목록 좁히기

키워드 필터는 확인 가능한 노드 명명 규칙을 기준으로 설정해야 합니다. 일반적인 이름에는 지역, 회선 번호, 배율, 프로토콜 표시, 상태 문구가 함께 들어갑니다. 예를 들면 “홍콩 03｜전용 회선｜0.5x”와 같습니다. 평소 홍콩·싱가포르·일본만 사용한다면 먼저 포함 조건을 만들고, 목록에 “잔여 트래픽”, “요금제 만료”, “공식 사이트 주소” 같은 정보 항목이 섞여 있다면 제외 조건으로 정리하세요.

필터 입력란을 제공하는 v2rayN 버전에서는 「구독 그룹」→「구독 그룹 설정」을 열고 대상 그룹을 선택한 뒤 필터 조건을 편집합니다. 먼저 일반 키워드 하나를 저장하고 해당 그룹만 업데이트해 필터 적용 범위를 확인하세요. 여러 지역을 동시에 매칭해야 할 때 정규 표현식을 사용하면 됩니다. 필터는 구독을 해석하는 단계에서 적용되며 서버 목록 상단의 임시 검색과는 다릅니다. 검색은 현재 화면에서 일치하지 않는 항목을 숨길 뿐이지만, 구독 필터는 업데이트 후 어떤 서버가 저장될지를 결정합니다.

포함 조건: 홍콩|싱가포르|일본
제외 조건: 잔여 트래픽|요금제 만료|공식 사이트|점검|배율2
저배율 조건: 0\.5x|0\.5배|저배율

정규 표현식에서 세로줄은 “조건 중 하나”를 뜻하며, 마침표는 이스케이프 형식으로 작성해야 합니다. 예를 들어 “0.5x”를 매칭하려면 “0\.5x”가 “0.5x”를 그대로 쓰는 것보다 정확합니다. 서버 이름에 실제로 없는 약칭을 조건에 임의로 추가하지 마세요. “싱가포르”와 “사자성”이 모두 존재하는지는 먼저 해당 구독이 실제로 반환하는 이름을 확인해야 합니다.

필터링 후 속도 측정하기: 지연 시간만으로 판단하지 않기

목록을 줄인 뒤 지연 시간 테스트를 실행하면 결과를 비교하기가 더 쉽습니다. 세 구독에서 총 126개 기록이 반환되고 지역과 상태 필터로 34개까지 줄었다고 하면 테스트 작업 수는 약 73% 감소합니다. Windows 11과 기가비트 LAN 환경에서 정리한 한 기록에서는 서버 126개의 지연 시간 테스트에 약 52초, 34개에는 약 16초가 걸렸습니다. 네트워크, 코어 상태, 시간 초과 설정에 따라 수치는 달라지지만 테스트 대상을 줄이는 효과는 분명합니다.

v2rayN 서버 목록에서 먼저 구독 그룹으로 필터링한 다음 「서버」→「서버 실제 연결 지연 시간 테스트」를 실행할 수 있습니다. 실제 연결 지연 시간 테스트는 노드를 통해 실제로 연결을 시도하므로 전송 계층 응답만 보는 것보다 사용 상태에 가깝습니다. 테스트 중에는 구독을 동시에 업데이트하지 말고, 여러 일괄 테스트 명령을 연속으로 클릭하지도 마세요. 이전 결과와 새 결과, 시간 초과 작업이 뒤섞여 표시될 수 있습니다.

1. 대역폭을 많이 사용하는 다운로드나 동기화 작업을 먼저 종료해 로컬 네트워크 부하를 안정적으로 유지하세요.
2. 구독 그룹 하나를 선택해 실제 연결 지연 시간 테스트를 실행하고 성공률과 응답 시간을 기록합니다.
3. 후보 노드는 약 30초 간격으로 세 번 반복 테스트하고, 한 번 측정된 최저값만으로 결정하지 않습니다.
4. 평균 지연 시간이 비슷한 노드 중 오류율이 낮고 반복 테스트의 변동 폭이 작은 노드를 선택합니다.
5. 선택을 마친 뒤 시스템 프록시를 켜고 실제 웹 페이지나 애플리케이션 요청으로 연결을 확인합니다.

예를 들어 노드 A의 세 번 측정값이 88, 94, 91ms이고 노드 B가 61, 248, 시간 초과라고 해 보겠습니다. 노드 B에 더 낮은 값이 한 번 나왔더라도 연속성이 더 좋은 노드 A가 일상용으로 적합합니다. 노드 C의 지연 시간이 130ms이지만 대용량 파일 전송이 안정적이라면 지연 시간이 100ms를 넘는다는 이유만으로 삭제하지 말고 “대용량 트래픽” 그룹에 넣을 수 있습니다.

v2rayNG에서 모바일 그룹을 명확하게 유지하기

v2rayNG에서는 각 구독을 독립적인 설정 출처로 유지하는 방식이 좋습니다. 왼쪽 상단 메뉴의 「구독 그룹 설정」으로 들어가 항목별로 메모와 구독 주소를 추가하고, 저장한 뒤 해당 그룹을 선택해 업데이트하세요. 버전에 따라 버튼 위치는 조금 다를 수 있지만 핵심 원칙은 같습니다. 서비스 제공업체 하나당 구독 항목 하나를 두고, 메모는 데스크톱과 같은 이름을 사용해 같은 출처가 두 기기에서 서로 다른 이름으로 표시되지 않게 하세요.

안드로이드는 화면 공간이 제한되어 데스크톱보다 표시되는 노드 수를 더 적극적으로 관리해야 합니다. 먼저 지정한 구독 그룹으로 전환한 뒤 구성 목록의 필터나 검색 기능으로 원하는 지역을 확인하세요. 현재 버전에 저장되는 포함·제외 필드가 없다면 검색 조건은 현재 목록에만 적용되는 필터일 뿐 구독 내용이 영구적으로 수정된 것은 아닙니다. 다음 업데이트 후 정보 노드가 다시 나타나는지도 확인해야 합니다.

• 메모 통일: 데스크톱에서 “클라우드A-일상”을 사용한다면 안드로이드에서도 같은 이름을 사용하고 “A”로 줄이지 않습니다.
• 그룹별 업데이트: 예비 회선이 필요할 때만 예비 그룹을 업데이트해 매번 모든 구독을 새로 고치지 않도록 합니다.
• 코어 역할: v2rayNG는 Xray 코어를 사용합니다. v2fly 코어를 선택하는 안드로이드 클라이언트에서는 v2flyNG를 사용하며, 두 클라이언트의 구독 출처도 각각 구분해 이름을 지정해야 합니다.
• 로컬 포트: 일반적인 로컬 SOCKS 포트는 10808이지만 실제 값은 「설정」→「매개변수 설정」의 구성을 따릅니다.
• 업데이트 확인: 업데이트가 끝나면 “업데이트 성공” 메시지만 보지 말고 추가·삭제된 수량과 현재 활성 구성을 확인합니다.

자동 업데이트와 장애 전환 운영 방법

여러 구독을 관리할 때 모든 그룹을 동시에 새로 고칠 필요는 없습니다. 주 구독은 6시간마다, 예비 구독은 12시간마다, 저배율 구독은 8시간마다 업데이트하고 임시 테스트 구독은 자동 업데이트를 끄는 식으로 주기를 분산하는 편이 안정적입니다. 자주 쓰는 목록은 최신 상태로 유지하면서 여러 주소에 동시에 요청을 보내고 서버 목록을 해석·재작성하는 상황도 피할 수 있습니다.

업데이트 전후에는 노드 수 변화를 확인해야 합니다. 평소 30~40개가 있던 그룹이 어느 날 갑자기 2개로 줄었다면 기존 목록을 바로 비우고 설정을 처음부터 다시 만들지 마세요. 먼저 「구독 그룹 설정」에서 주소가 완전한지, 필터 표현식이 너무 좁지 않은지 확인한 다음 시스템 시간과 현재 네트워크 출구를 점검합니다. 필터 조건에 전각 기호 하나가 들어가거나 이스케이프를 잘못 작성해도 매칭 결과가 크게 줄 수 있습니다.

장애 전환 순서

1. 먼저 현재 그룹에서 최근 테스트 결과가 안정적이었던 두 번째 후보 노드로 전환합니다.
2. 같은 그룹의 여러 노드가 모두 실패하면 현재 구독을 한 번 업데이트한 뒤 다시 테스트합니다.
3. 구독 업데이트도 실패하면 예비 그룹에 저장해 둔 사용 가능한 노드로 전환합니다.
4. 예비 연결이 복구되면 주 구독 주소, 필터 필드, 자동 업데이트 설정을 다시 확인합니다.
5. 주 구독이 안정적으로 복구된 것을 확인한 뒤 돌아가며, 장애 중에 반복해서 삭제하고 가져오지 않습니다.

여러 구독을 정리할 때 자주 묻는 질문

정리가 끝난 서버 목록은 세 가지 질문에 답할 수 있어야 합니다. 현재 노드는 어느 구독에서 왔는가, 어떤 용도를 맡고 있는가, 사용할 수 없게 되면 어디로 먼저 전환할 것인가. 그룹 이름을 일관되게 유지하고, 필터 규칙을 다시 확인할 수 있으며, 업데이트 주기를 지나치게 촘촘하게 설정하지 않는다면 여러 서비스 구독은 계속 불어나는 노드 목록에서 출처와 용도별로 관리되는 연결 모음으로 바뀝니다.