멀티 서비스 구독 그룹 관리 실전: 서버 필터 규칙과 노드 선별 방법

먼저 구독 소스와 서버 목록을 두 계층으로 나누기

노드가 많을수록 모든 서버를 하나의 긴 목록에 넣는 방식은 적합하지 않습니다. 구독 소스는 ‘설정이 어디에서 업데이트되는가’를, 서버 항목은 ‘현재 어느 회선을 연결할 것인가’를 의미하므로 서로 다른 계층입니다. 하나의 구독 소스에는 수십 개의 VMess, VLESS 또는 기타 호환 설정이 포함될 수 있고, 구독을 업데이트하면 항목이 추가·이름 변경·삭제될 수도 있습니다. 서버 이름만으로 출처를 기억하면 몇 차례 업데이트 후 쉽게 뒤섞입니다.

가장 안정적인 구조는 출처별로 구독 그룹을 만든 뒤 각 그룹 안에서 노드를 선별하는 방식입니다. v2rayN 데스크톱 버전에서는 「구독 그룹」→「구독 그룹 설정」에서 이름, 주소와 업데이트 옵션을 확인할 수 있습니다. v2rayNG에서는 사이드 메뉴의 구독 그룹 설정에서 출처를 관리합니다. 버전에 따라 메뉴 문구가 조금 다를 수 있지만 기준은 같습니다. 각 구독 주소에는 독립적이고 식별하기 쉬우며 장기간 유지할 수 있는 메모가 있어야 합니다.

구독 제공자가 임시로 생성한 제목을 그룹 이름에 그대로 사용하지 마세요. 요금제나 이벤트에 따라 제목이 바뀔 수 있기 때문입니다. 더 실용적인 형식은 ‘출처 약칭＋용도＋주기’입니다. 예를 들어 ‘북부 회선-일상-월정액’ 또는 ‘백업 회선-모바일 네트워크’처럼 지정할 수 있습니다. 출처 약칭은 구독을 구분하고, 용도는 빠른 판단을 돕습니다. 갱신 관리에 꼭 필요할 때만 주기 정보를 추가해 이름이 지나치게 길어지지 않게 하세요.

같은 구독을 기기마다 완전히 다른 메모로 바꾸지 마세요. 데스크톱과 Android에서 이름을 통일하면 문제를 확인할 때 목록의 몇 번째 항목인지가 아니라 ‘주 회선 그룹의 홍콩 02’처럼 명확하게 말할 수 있습니다. 업데이트 후 서버 순서는 바뀌지만, 안정적인 그룹 이름과 노드 키워드는 위치를 찾는 기준으로 더 적합합니다.

장기간 재사용할 수 있는 메모 이름 규칙 만들기

노드 이름에는 보통 지역, 배율, 회선 또는 번호가 포함되지만 구독 소스마다 표기 방식이 다릅니다. 예를 들어 홍콩은 ‘홍콩’, ‘HK’ 또는 ‘Hong Kong’, 싱가포르는 ‘싱가포르’, ‘SG’ 또는 ‘Singapore’로 표시될 수 있습니다. 그룹을 넘나들며 검색할 때 단일 키워드만 사용하면 동의어 표기를 놓칠 수 있습니다. 따라서 먼저 각 출처의 실제 이름 지정 방식을 확인한 뒤 필터 단어를 정하는 편이 고정 템플릿을 적용하는 것보다 안정적입니다.

필터 기준은 세 가지로 제한하는 것을 권장합니다. 지역은 출구 위치를 정하고, 회선 또는 용도는 일상·백업·저배율 회선을 구분하며, 상태 단어는 ‘점검 중’, ‘만료’, ‘잔여 트래픽’ 같은 정보 항목을 제외하는 데 사용합니다. VMess, VLESS 같은 프로토콜 이름은 호환성 문제를 확인할 때 유용하지만 속도를 판단하는 단독 기준으로 사용해서는 안 됩니다. 프로토콜, 전송 계층, 서버 부하와 로컬 네트워크가 함께 연결 성능에 영향을 줍니다.

번호는 같은 지역 안에서 식별을 보조하는 용도로만 적합합니다. 예를 들어 ‘HK-01’과 ‘HK-02’처럼 사용할 수 있습니다. ‘노드 1’, ‘노드 2’를 여러 구독에서 공통으로 사용하지 마세요. 업데이트 후 기존 번호가 다른 서버를 가리킬 수 있습니다. 클라이언트에서 로컬 메모를 수정할 수 있다면 원래 이름의 지역과 회선 표시는 유지하고 앞에 짧은 접두사만 추가하세요. 예: ‘주-HK-02’.

구독을 업데이트하기 전에 모든 이름을 하나씩 수동으로 바꿀 필요는 없습니다. 먼저 그룹 설정이 로컬 메모를 덮어쓰는지 확인한 다음, 자주 사용하는 소수의 노드에만 로컬 식별 정보를 추가하세요. 자주 바뀌는 구독은 수십 개의 사용자 지정 이름을 관리하는 것보다 필터 규칙을 유지하는 편이 효율적입니다. 장기간 고정된 자체 구성은 지역·진입점·용도를 포함한 자세한 이름을 사용해도 좋습니다.

포함 및 제외 규칙으로 서버 목록 줄이기

필터는 임시 검색과 지속 규칙으로 나눌 수 있습니다. 임시 검색은 현재 항목을 찾을 때 적합합니다. 예를 들어 v2rayN의 서버 필터 입력란에 ‘HK’를 입력하거나 v2rayNG 구성 목록의 검색 기능을 사용할 수 있습니다. 입력을 지우면 전체 목록은 그대로 남습니다. 지속 규칙은 구독 그룹의 필터 설정에 저장해 조건에 맞는 항목만 해당 그룹에 들어오게 합니다. 사용하기 전에 현재 필드가 일반 키워드와 정규식 중 무엇을 지원하는지 확인하세요. 일반 키워드 필드에는 정규식 문법을 그대로 입력할 수 없습니다.

가장 안전한 시작점은 포함 단어 하나입니다. 홍콩 항목만 필요하다면 먼저 ‘홍콩’과 ‘HK’를 각각 입력해 대상 노드가 모두 포함되는지 확인하세요. 이름 규칙을 파악한 뒤 ‘홍콩|HK|Hong Kong’으로 동의어를 합칠 수 있습니다. 정규식에서 세로줄은 여러 항목 중 하나를 뜻하고, 괄호는 조합 범위를 제한합니다. 영문 대소문자 구분 여부는 클라이언트 필드 구현에 따라 다르므로 알고 있는 노드 하나로 검증해야 합니다.

지역 포함:
(홍콩|HK|Hong Kong|싱가포르|SG|Singapore)

상태 제외:
^(?!.*(만료|기간 만료|잔여|트래픽|점검|테스트)).*$

지정 지역을 유지하고 상태 단어 제외:
^(?!.*(만료|기간 만료|잔여|트래픽|점검|테스트)).*(홍콩|HK|Hong Kong|싱가포르|SG|Singapore).*$

제외 규칙의 부정 전방 탐색은 ‘한 줄 전체에 해당 단어가 포함되지 않아야 한다’는 뜻입니다. 요금제 만료 알림, 트래픽 정보와 점검 공지를 정리하는 데 적합하지만, 정상 회선 이름에 포함될 수도 있는 ‘테스트’ 같은 단어를 무작정 추가하지 마세요. 정식 저장 전에 임시 검색으로 결과를 확인하고, 유지되는 항목과 제외되는 항목을 각각 최소 5개씩 점검해야 합니다.

규칙이 길수록 유지 관리 비용이 커집니다. 지역, 배율, 프로토콜, 전송 방식과 번호를 하나의 표현식에 모두 넣는 것이 흔한 실수입니다. 그러면 구독 제공자가 이름을 조금만 바꿔도 일치하지 않습니다. 먼저 지역 기준으로 넓게 필터링한 뒤 클라이언트 목록에서 지연 시간이나 키워드로 두 번째 임시 필터를 적용하는 편이 합리적입니다.

정렬할 때 지연 시간, 변동 폭과 실제 접속을 함께 확인하기

지연 시간 테스트는 테스트 대상이 당시 빠르게 응답했는지만 보여 줄 뿐, 지속 다운로드·웹 페이지 최초 로딩·장시간 연결 성능을 완전히 나타내지는 않습니다. 노드를 정렬한 뒤에는 최저값 하나만 남기지 말고 여러 후보를 유지하세요. 실용적인 방법은 약 30초 간격으로 3회 연속 테스트하고 결과가 안정적인지 기록하는 것입니다. 어떤 노드가 72, 76, 74ms를 기록했다면 48, 260, 시간 초과처럼 결과 편차가 큰 노드보다 일상용으로 적합한 경우가 많습니다.

테스트할 때는 변수를 통제해야 합니다. 데스크톱에서는 먼저 대용량 파일 전송과 시스템 업데이트를 중지하고, v2rayN의 현재 코어가 실행 중인지 확인한 뒤 같은 그룹에서 지연 시간 테스트를 수행하세요. 시스템 프록시를 사용하면 일반적인 로컬 수신 포트가 10808로 표시될 수 있지만, 실제 설정은 「설정」→「매개변수 설정」에서 확인해야 합니다. 포트를 다른 프로세스가 사용 중이면 노드 목록의 지연 시간 결과와 웹 페이지 접속이 모두 비정상일 수 있습니다.

1. 대상 구독 그룹을 업데이트하고, 한 번에 모든 출처를 섞어 테스트하지 마세요.
2. 지역 키워드로 후보 범위를 12~24개 노드로 좁히세요.
3. 1차 지연 시간 테스트를 실행하고, 계속 시간 초과가 발생하거나 명백히 사용할 수 없는 항목을 먼저 제거하세요.
4. 약 30초 간격으로 두 차례 더 테스트해 최저값이 아니라 수치 변동을 확인하세요.
5. 결과가 안정적인 노드 중 3~5개를 골라 웹 페이지 최초 로딩, 동영상 로딩 또는 실제 업무를 각각 테스트하세요.
6. 주 사용 노드 하나와 서로 다른 회선의 백업 노드 두 개를 유지해 모든 후보가 같은 경로에 의존하지 않게 하세요.

Android에서는 모바일 네트워크 전환과 시스템 백그라운드 정책의 영향을 더 쉽게 받습니다. v2rayNG로 테스트할 때는 먼저 네트워크 유형을 유지하고 Wi-Fi와 모바일 네트워크 사이를 오가지 마세요. 앱이 백그라운드에서 막 복귀했다면 연결 상태가 안정될 때까지 기다린 뒤 테스트하세요. 그렇지 않으면 첫 결과에 네트워크 재연결에 걸린 추가 시간이 포함될 수 있습니다.

정렬의 최종 결과물은 영구 순위표가 아니라 짧은 후보 목록입니다. 자주 사용하는 각 지역에 4~6개 노드를 유지하고, 그중 절반은 주 구독에서, 절반은 백업 구독에서 선택하는 것을 권장합니다. 빠르게 전환할 수 있으면서도 목록이 다시 판단하기 어려울 정도로 늘어나는 것을 막을 수 있습니다.

v2rayN과 v2rayNG에서 동일한 그룹 논리 유지하기

데스크톱과 Android에서 목록 순서를 완전히 같게 만들 필요는 없습니다. 두 클라이언트의 가져오기, 정렬과 로컬 테스트 결과가 다를 수 있기 때문입니다. 실제로 동기화해야 하는 것은 그룹 이름, 지역 키워드와 보관 기준입니다. 양쪽에서 ‘주 회선-일상’과 ‘백업 회선-비상’의 의미만 같다면 현재 어떤 유형의 출처를 사용하는지 빠르게 판단할 수 있습니다.

v2rayN은 서버 열을 일괄 확인하고 테스트 결과로 정렬하며 많은 항목을 처리하는 데 적합합니다. v2rayNG는 정리된 자주 사용하는 구성을 유지하는 데 더 적합합니다. 먼저 데스크톱에서 구독의 이름 규칙을 확인한 뒤 동일한 포함 단어와 제외 단어를 Android에서 사용할 수 있습니다. Android 쪽 필드가 일반 텍스트 검색만 지원한다면 복잡한 표현식을 억지로 입력하지 말고 짧은 키워드 여러 개로 나누어 검색하세요.

• 주간 유지 관리: 주 그룹을 업데이트하고 3회 연속 테스트한 뒤 짧은 후보 목록에서 사용할 수 없는 노드를 교체합니다.
• 사용 전 확인: 백업 그룹은 평소에 자주 정렬할 필요가 없습니다. 전환해야 할 때 업데이트하고 테스트하세요.
• 프로토콜 점검: 연결에 문제가 생기면 VMess 또는 VLESS로 임시 필터링해 같은 프로토콜 항목의 성능을 비교합니다.
• 라우팅 확인: 라우팅 분할 규칙을 변경한 뒤 다시 연결해 이전 세션이 기존 아웃바운드를 계속 사용하지 않게 하세요.
• 업데이트 기록: 그룹에서 갑자기 많은 노드가 사라지면 먼저 필터 조건을 확인한 뒤 구독 내용이 바뀌었는지 판단하세요.

라우팅 분할과 구독 그룹도 구분해야 합니다. 그룹 관리는 어떤 서버를 목록에 넣을지 결정하고, 라우팅 규칙은 연결이 수립된 뒤 어떤 요청을 직접 연결·프록시·차단할지 결정합니다. 노드를 바꾼다고 잘못된 라우팅 규칙이 자동으로 수정되지는 않으며, 라우팅을 수정해도 구독의 노드 수는 바뀌지 않습니다. 문제를 확인할 때는 먼저 목록이 올바른지 살펴본 다음 코어 로그와 라우팅 규칙 적중 여부를 확인하면 순서가 더 명확합니다.

v2rayN과 v2rayNG에서 같은 그룹에 동시에 노드가 부족해졌다면 먼저 구독 내용이나 양쪽에서 공통으로 사용하는 필터 키워드를 확인하세요. 한쪽에서만 문제가 발생하면 해당 클라이언트의 그룹 선택, 업데이트 시간과 로컬 필터 상태를 점검합니다. 이렇게 비교하면 문제가 구독 소스, 규칙 또는 특정 클라이언트 중 어디에 있는지 빠르게 판단할 수 있습니다.

자주 발생하는 문제와 수정 방법

구독 관리에서 가장 흔한 문제는 설정이 완전히 작동하지 않는 것이 아니라 목록 수, 필터 결과와 예상이 서로 다른 것입니다. 이런 문제를 처리할 때 여러 조건을 연속으로 수정하지 마세요. 임시 검색을 먼저 지우고, 지속 필터를 비활성화한 다음 대상 그룹을 다시 업데이트하는 식으로 한 번에 변수 하나만 바꿔야 어떤 단계가 결과에 영향을 주었는지 알 수 있습니다.

장기간 유지 관리의 목표는 ‘각 그룹에서 1분 안에 사용할 수 있는 노드를 선택할 수 있는 상태’로 정할 수 있습니다. 이 목표에는 복잡한 규칙보다 안정적인 그룹 이름, 명확한 소수의 키워드와 고정된 테스트 순서가 중요합니다. 노드 수가 바뀌면 먼저 필터를 확인하고, 연결 성능이 달라지면 지연 시간과 실제 접속을 테스트하세요. 두 문제 확인 절차를 섞지 않는 것이 좋습니다.

구독 소스가 세 개를 넘더라도 용도에 따라 활성 그룹 수를 관리하는 것이 좋습니다. 평소에는 주 그룹과 백업 그룹만 펼쳐 두고, 자주 사용하지 않는 출처는 알아보기 쉬운 메모만 남겨 두세요. 모든 항목을 저장하는 것보다 읽기 쉬운 목록을 유지하는 편이 더 유용한 경우가 많습니다.