여러 서비스 구독을 그룹으로 관리하는 방법: v2rayN 서버 필터와 메모 규칙

이 글 한눈에 보기

이 글은 v2rayN에 두 개 이상의 구독을 저장하고 수십~수백 개의 노드를 관리하는 사용자를 위한 내용입니다. 먼저 출처별로 구독 그룹을 만들고, 지역·회선·용도를 일정한 메모 형식으로 표시한 뒤, 키워드 필터와 지연 시간 정렬로 후보를 좁히는 것이 핵심입니다. 업데이트 후에도 재사용할 수 있는 노드 관리 규칙을 구축할 수 있습니다.

먼저 구독 출처, 노드 속성, 실행 설정을 구분하세요

여러 구독이 하나의 서버 목록에 섞이면 가장 흔한 문제는 노드 수가 아니라 세 가지 계층이 뒤섞이는 것입니다. 구독 그룹은 노드를 어디에서 가져왔는지를 나타내고, 노드 이름은 서버가 제공하는 지역이나 회선 정보를 보여 줍니다. 현재 설정은 v2rayN이 이 순간 Xray 또는 v2fly 코어에 전달해 실행하는 기록입니다. 한 계층을 수정해도 다른 두 계층이 자동으로 바뀌지는 않습니다.

먼저 「구독 그룹」→「구독 그룹 설정」에서 구독을 하나씩 저장하고, 출처마다 별도 항목을 만드세요. 여러 주소를 알아보기 어려운 하나의 이름으로 합치지 않는 것이 좋습니다. 그룹 별칭은 “주 사용-A”, “보조-B”, “테스트-C”처럼 출처와 용도를 설명해야 하며 “구독1”, “구독2”처럼만 적지 마세요. 이후 업데이트 실패, 노드 중복, 트래픽 만료가 발생해도 해당 출처를 바로 찾을 수 있습니다.

정상적인 업데이트 과정은 다음과 같습니다. v2rayN이 선택한 그룹의 구독 주소를 읽고, 구독 내용을 다운로드한 다음, VMess·VLESS 등의 노드 기록을 해석해 해당 그룹에 저장합니다. 서버 목록에 표시되는 이름은 대개 구독 내용에서 가져옵니다. 로컬 필터는 표시할 기록만 결정할 뿐 원격 구독을 변경하지 않습니다.

구독 그룹 선택구독 내용 가져오기노드 기록 해석필터 규칙 적용실행 노드 선택

주 사용 그룹

별칭: 주 사용-A
업데이트 방식: 수동 확인 후 업데이트
노드 범위: 자주 사용하는 지역
확인 주기: 주 1회

일상적으로 안정적인 회선을 유지하고 현재 노드를 자주 바꾸지 않습니다.

보조 그룹

별칭: 보조-B
업데이트 방식: 필요할 때 업데이트
노드 범위: 지역 간 보조 회선
확인 주기: 월 2회

주 사용 회선에 문제가 생겼을 때만 열어 목록의 시각적 혼잡을 줄입니다.

전용 그룹

별칭: 업무-C
용도: 고정 업무
라우팅: 독립 규칙 세트
변경 원칙: 테스트 후 전환

고정 출구가 필요한 노드와 일상적인 검색용 노드를 분리합니다.

관찰 그룹

별칭: 테스트-D
용도: 새 회선 검증
보관 기간: 7일
속도 테스트 횟수: 3회

안정성을 확인한 뒤 일상적인 선택 범위로 옮기고, 한 번의 지연 시간만으로 판단하지 않습니다.

필터링 가능한 노드 메모 규칙 만들기

서버 이름은 형식이 일정할 때 장기적인 필터링에 적합합니다. 같은 지역이 “홍콩”, “HK”, “Hong Kong”, “港”처럼 여러 방식으로 표시되면 검색 결과가 구독 이름에 따라 달라집니다. 지역·회선·용도·번호를 고정된 위치에 배치한 자체 식별 형식을 정하는 것이 안전합니다. 예를 들어 “HK-IEPL-Work-01”처럼 작성하면 이름만 보고도 노드 속성을 파악하고 단일 키워드로 빠르게 범위를 좁힐 수 있습니다.

지역은 두세 글자의 대문자 약어를 사용하고, 회선 유형은 구독에 실제로 표시된 정보를 유지하며, 용도에는 확인된 사실만 적으세요. 노드 이름만 보고 일반 회선을 전용 회선으로 바꾸어 기록하거나 “저배율”을 “낮은 지연 시간”으로 해석해서는 안 됩니다. 메모는 분류용이며, 지연 시간·속도·가용성은 테스트로 확인해야 합니다.

권장 형식: 지역-회선-용도-번호

HK-IEPL-Daily-01
JP-BGP-Work-02
SG-Direct-Backup-01
US-Transit-Media-03

지역 필드: HK, JP, SG, US, DE처럼 짧은 표기를 일관되게 사용해 같은 지역에 여러 표기가 생기지 않도록 합니다.
회선 필드: IEPL, BGP, Direct, Transit처럼 구독에 명시된 정보를 사용하고, 알 수 없으면 STD로 적습니다. 임의로 추정하지 마세요.
용도 필드: Daily, Work, Backup, Media를 사용할 수 있지만, 이는 로컬 분류일 뿐 노드에 특별한 기능이 있다는 뜻은 아닙니다.
번호 필드: 숫자를 항상 두 자리로 맞추면 이름순 정렬에서 01, 02, 10의 순서가 어긋나지 않습니다.

결론: 메모에는 변하지 않는 속성만 기록하세요

지역·출처·용도는 메모에 적합합니다. 실시간 지연 시간, 남은 트래픽, 당일 속도는 계속 변하므로 테스트 결과와 구독 상태에 맡기세요. 측정할 때마다 이름을 수정하는 일을 피할 수 있습니다.

구독 업데이트 시 원격 기록을 기준으로 노드가 다시 생성될 수 있다는 점에 유의하세요. 서버 표시 이름을 로컬에서 직접 수정한 뒤 다음 업데이트에도 유지되는지는 버전, 그룹 설정, 노드 일치 결과에 따라 달라집니다. 중요한 별칭은 개별 노드에만 저장하지 말고 구독 그룹 이름이나 별도 기록에도 출처 정보를 남기세요. 대량 정리를 시작하기 전에 노드 5개로 업데이트를 한 번 테스트해 로컬 메모가 유지되는지 확인하는 것이 좋습니다.

키워드 필터로 서버 목록 좁히기

필터의 목적은 노드를 영구적으로 삭제하는 것이 아니라, 현재 확인해야 할 범위를 수백 개에서 수십 개로 줄이는 것입니다. 해당 구독 그룹으로 이동한 뒤 서버 목록의 필터 또는 검색 영역에 지역·용도·회선 키워드를 입력하세요. v2rayN 7.x의 세부 버전에 따라 컨트롤 위치는 조금 다를 수 있지만 원칙은 같습니다. 먼저 구독 그룹을 제한하고, 이름을 필터링한 다음, 표시된 결과에 테스트와 정렬을 적용합니다.

단일 키워드는 일상적인 전환에 적합합니다. 예를 들어 “HK”를 입력하면 홍콩 노드를, “Backup”을 입력하면 보조 노드를 볼 수 있습니다. 조건을 조합하려면 현재 버전의 필터 입력이 정규 표현식을 지원하는지 먼저 확인하세요. 일반 텍스트만 지원한다면 “JP-BGP”처럼 통일된 메모의 전체 구간을 사용하면 됩니다. 너무 넓은 단일 문자는 회선·용도·지역 필드에 동시에 일치할 수 있으므로 피하세요.

필터 대상	입력 예시	예상 범위	다음 작업
단일 지역	`HK-`	홍콩 노드	지연 시간 테스트 실행
지역 및 회선	`JP-BGP`	일본 BGP 노드	지연 시간 오름차순으로 확인
업무 용도	`-Work-`	업무용으로 표시한 노드	출구 조건 확인
보조 목록	`-Backup-`	지역 간 보조 노드	실제 연결 테스트

128개

예시 원본 노드 수

18개

HK로 필터링한 후

6개

시간 초과 결과를 제외한 후

3회

권장 반복 테스트 횟수

위 숫자는 필터링 순서를 설명하기 위한 예시입니다. 먼저 128개 기록을 지역 기준으로 18개까지 줄이고, 6초 안에 응답하지 않은 기록을 제외한 다음, 남은 노드를 3회 반복 테스트합니다. 한 번 80ms가 나왔다가 다음에는 320ms가 되는 노드는 최저값만으로 1순위에 올려서는 안 됩니다. 세 번의 결과가 일정한 범위에 모이는지, 연속 시간 초과가 발생하는지를 확인하는 편이 중요합니다.

결론: 먼저 필터링하고, 다음에 속도를 측정한 뒤, 마지막으로 정렬하세요

모든 노드에 전체 테스트를 반복해서 실행하지 마세요. 먼저 그룹과 이름으로 후보를 10~20개까지 줄인 뒤 세 차례의 지연 시간과 실제 연결 결과를 비교하면 더 빠르고 이상값도 쉽게 찾을 수 있습니다.

정렬할 때 지연 시간·속도·안정성을 구분하세요

v2rayN의 서버 목록에는 지연 시간, 속도 또는 테스트 상태를 표시할 수 있지만 각 열이 답하는 질문은 서로 다릅니다. 지연 시간은 탐색 요청의 왕복 시간을 나타내고, 속도 테스트는 특정 시점의 데이터 전송 성능을 보여 줍니다. 실제 사용 가능 여부는 대상 사이트, 라우팅 분할, DNS, 로컬 네트워크의 영향도 받습니다. 지연 시간이 가장 짧다고 모든 상황에서 가장 빠른 것은 아니며, 한 번 속도가 높았다고 저녁에도 안정적이라는 뜻은 아닙니다.

“두 번의 1차 필터링과 한 번의 실측” 순서를 권장합니다. 첫 단계에서는 이름이나 그룹으로 필터링합니다. 두 번째 단계에서는 지연 시간 테스트를 실행하고 결과를 오름차순으로 정렬해 연속 시간 초과와 뚜렷한 이상값을 제외합니다. 세 번째 단계에서는 상위 3~5개를 하나씩 활성 서버로 설정하고 실제로 필요한 서비스를 열어 보면서 코어 로그에 연결 시간 초과, TLS 핸드셰이크 실패, 라우팅 거부가 나타나는지 확인합니다.

서버 목록에서 구독 그룹을 하나 선택하고 지역 또는 용도 키워드를 입력합니다.
현재 표시된 노드에 지연 시간 테스트를 실행하고 전체 작업이 끝난 뒤 정렬합니다.
30초 간격으로 3회 반복하고 변동 범위를 기록합니다. 한 번의 최저값은 사용하지 않습니다.
결과가 안정적인 노드 중 3~5개를 골라 하나씩 활성 서버로 설정합니다.
시스템 프록시 또는 TUN 작동 모드가 현재 요구 사항에 맞는지 확인한 뒤 실제 접속을 테스트합니다.
최종 선택을 용도 메모에 기록하되 실시간 밀리초 수치는 노드 이름에 넣지 않습니다.

정렬이 끝난 뒤 뒤쪽의 모든 기록을 삭제하지 않는 것이 좋습니다. 구독 제공자가 진입점이나 회선을 조정할 수 있으므로 오늘 지연 시간이 높은 보조 노드도 다른 네트워크 환경에서는 사용할 수 있습니다. 당장 사용하지 않는 노드는 필터로 숨기거나 보조 그룹에 넣으세요. 명확히 만료되었고 중복되며 업데이트 후 다시 나타나지 않는 것이 확인된 로컬 기록만 정리하는 것이 적절합니다.

구독 업데이트로 기존 분류가 흐트러지지 않게 하기

정리 결과를 가장 쉽게 망치는 작업은 출처를 확인하지 않은 채 모든 구독을 업데이트한 뒤 새 목록을 기준으로 즉시 일괄 삭제하는 것입니다. 그룹별로 업데이트하는 것이 안전합니다. 먼저 업데이트 전 노드 수를 기록하고, 한 그룹만 업데이트한 뒤 추가·감소·이름 변경을 확인하고, 마지막으로 필터와 테스트를 실행하세요. 노드 수가 갑자기 42개에서 0개가 되었다면 다른 정상 그룹을 덮어쓰지 말고 구독 주소, 네트워크 상태, 업데이트 로그부터 확인해야 합니다.

VMess와 VLESS는 노드 프로토콜이지 그룹 분류 기준이 아닙니다. 하나의 구독에 여러 프로토콜이 함께 포함될 수 있고, 같은 지역에도 서로 다른 전송 설정이 존재할 수 있습니다. 분류할 때는 출처·지역·용도를 우선 사용하세요. 프로토콜 호환성이나 전송 문제를 점검할 때만 VMess, VLESS, TCP, WebSocket, TLS, REALITY 등의 필드로 개별 노드 설정을 확인하면 됩니다.

업데이트 후 수동으로 적은 메모가 원래 이름으로 돌아가면 어떻게 하나요?

먼저 업데이트로 노드 기록이 다시 생성되었는지 확인하세요. 안정적인 분류는 구독 그룹 별칭에 넣고, 개별 노드에는 필요한 메모만 남기세요. 일괄 수정 전에 소수의 노드로 “이름 수정—구독 업데이트—결과 확인” 테스트를 한 번 진행하는 것이 좋습니다.

두 구독에 같은 노드가 나타나면 바로 삭제해야 하나요?

먼저 주소, 포트, 사용자 식별자, 전송 및 TLS 매개변수를 비교하세요. 표시 이름이 같아도 설정이 같다는 뜻은 아닙니다. 모든 핵심 매개변수가 동일한 것을 확인한 뒤 출처가 안정적인 그룹을 남기고, 다른 그룹은 그룹 필터로 숨기세요.

필터링 후에도 테스트 결과가 너무 많이 나오는 이유는 무엇인가요?

키워드가 너무 짧지 않은지 확인하고 현재 대상 구독 그룹에 있는지도 확인하세요. “J”를 “JP-”로 바꾸거나 “-Work-”처럼 구분자가 포함된 전체 필드를 사용하면 이름의 잘못된 일치를 줄일 수 있습니다.

구독 업데이트가 실패하고 시간 초과가 표시되면 어떻게 처리하나요?

먼저 구독 주소에 여전히 접속할 수 있는지 확인한 다음 현재 사용 가능한 프록시를 통해 업데이트를 시도하세요. 한 그룹만 실패했다면 모든 그룹을 반복해서 업데이트하지 말고 로그의 요청 시간과 상태를 확인해 해당 출처만 처리하세요.

지연 시간순으로 정렬했을 때 첫 번째 노드가 반드시 가장 좋은가요?

반드시 그렇지는 않습니다. 최소 3회 반복 테스트하고 상위 3~5개는 실제 접속으로 확인하세요. 한 번 측정된 최저 밀리초 수치보다 변동이 작고 연속 연결에 성공하며 용도 요건을 충족하는 노드를 우선 선택하세요.

지속적으로 실행할 수 있는 업데이트 체크리스트

각 구독 주소에 명확한 그룹 하나를 연결하고 출처를 섞지 않습니다.
업데이트 전에 그룹의 노드 수와 현재 활성 서버를 기록합니다.
한 번에 그룹 하나만 업데이트하고 확인을 마친 뒤 다음 그룹을 처리합니다.
“지역-회선-용도-번호” 메모 구조를 일관되게 사용합니다.
먼저 10~20개까지 필터링한 다음 지연 시간 테스트를 3회 실행합니다.
노드를 전환한 뒤 시스템 프록시, 라우팅 규칙, 코어 로그를 확인합니다.
보조 노드를 남겨 두고 한 번의 테스트 결과로 장기 안정성을 대신 판단하지 않습니다.

노드가 수백 개에 이르면 관리 효율은 얼마나 철저히 삭제했는지가 아니라 규칙이 얼마나 안정적인지에 달려 있습니다. 구독 그룹은 출처 추적을, 통일된 메모는 가독성을, 키워드 필터는 후보 범위 축소를, 반복 테스트와 실제 접속은 최종 선택을 담당합니다. 이 네 단계를 고정하면 구독 내용이 계속 바뀌어도 몇 분 안에 올바른 그룹과 사용 가능한 노드를 찾을 수 있습니다.