Profile이란 정확히 무엇인가

많은 사람들이 "구독 링크"와 "설정 파일"을 같은 것으로 착각하지만, 엄밀히 말하면 둘은 완전히 같지 않습니다. 구독 링크는 HTTP 주소이며, 클라이언트는 주기적으로 이 주소에 요청을 보냅니다. 응답으로 받은 내용이 바로 실제 설정 파일이며, 보통 YAML 형식의 텍스트로 되어 있고 업계에서는 이를 Profile이라 부릅니다. 클라이언트는 이 텍스트를 로컬에 내려받아 해석한 뒤 실행하며, 화면에서 보이는 노드 목록, 프록시 그룹 전환 버튼, 규칙 매칭 결과는 모두 이 YAML 내용에서 나옵니다.

Profile은 본질적으로 구조화된 텍스트 설정일 뿐 신비롭거나 복잡하지 않습니다. 뜯어보면 실제로 동작하는 것은 세 개의 핵심 부분뿐입니다: 노드 정의, 프록시 그룹 편성, 규칙 목록. 나머지 필드는 대부분 포트, 로그 레벨, DNS 같은 실행 파라미터이며, 세 부분을 이해하면 Profile의 동작 방식을 기본적으로 이해한 것입니다.

노드, 프록시 그룹, 규칙: 세 부분이 각각 담당하는 것

Profile을 위에서 아래로 한 번 읽어보면, 내용이 기본적으로 세 계층으로 구성되어 있고 계층 간에는 명확한 참조 관계가 있음을 알 수 있습니다. 이 참조 체인을 이해하지 못하면 이후의 다중 설정 관리와 규칙 조정에서 헛수고를 하게 됩니다.

proxies: 노드란 무엇인가

proxies 부분은 사용 가능한 모든 프록시 서버를 나열하며, 각 항목은 서버 주소, 포트, 암호화 방식, 비밀번호 또는 키 등 연결 파라미터를 포함하고, 특정 서버 노드에 대응합니다. 이 계층은 가장 하위의 "원재료"로서 트래픽의 방향을 직접 결정하지 않으며, 단지 "어떤 서버를 사용할 수 있는지"를 선언할 뿐입니다.

proxy-groups: 프록시 그룹이란 무엇인가

proxy-groups 부분은 위에서 선언한 노드를 논리적으로 그룹화합니다. 자주 쓰이는 그룹 유형은 다음과 같습니다:

  • select——수동 선택 그룹, 화면에 노드 버튼이 나열되어 클릭한 노드를 사용;
  • url-test——자동 속도 테스트 그룹, 지연 시간에 따라 자동으로 최적 노드를 선택하며 보통 주기적 탐지와 함께 사용;
  • fallback——장애 복구 그룹, 메인 노드가 실패하면 자동으로 백업 노드로 전환;
  • load-balance——로드 밸런싱 그룹, 여러 노드가 트래픽을 분산.

프록시 그룹은 서로 중첩 참조도 가능합니다. 예를 들어 "자동 선택"의 url-test 그룹이 또 다른 수동 select 그룹의 옵션 중 하나로 들어갈 수 있는데, 이런 중첩은 규칙 매칭 이상을 조사할 때 가장 쉽게 놓치는 부분입니다.

rules: 규칙이란 무엇인가

rules 부분은 위에서 아래로 순서대로 매칭되는 목록으로, 각 규칙은 매칭 조건과 대상 정책으로 구성되며 형식은 대략 다음과 같습니다:

DOMAIN-SUFFIX,openai.com,미국 노드
DOMAIN-KEYWORD,github,자동 선택
GEOIP,CN,DIRECT
MATCH,자동 선택

매칭 조건으로 흔히 쓰이는 것은 DOMAIN(정확한 도메인), DOMAIN-SUFFIX(도메인 접미사), DOMAIN-KEYWORD(도메인 키워드), GEOIP(대상 IP의 지역 기준), IP-CIDR(IP 대역 기준)이며, 마지막 줄은 보통 MATCH로 "위 조건에 모두 해당하지 않을 때 여기로"라는 최종 기본 정책을 뜻합니다. 규칙은 위에서 아래로 순서대로 비교하며 한 번 매칭되면 즉시 해당 정책을 실행하고 더 이상 아래로 매칭하지 않습니다——이 "매칭되면 중단"이라는 특성이 뒤에서 다룰 규칙 덮어쓰기 문제의 핵심 전제입니다.

Notice / 참고

규칙에 적는 "대상 정책"은 앞의 proxy-groups에 이미 존재하는 그룹명이거나, DIRECT/REJECT라는 두 내장 정책 중 하나여야 합니다. 그룹명을 잘못 쓰면 해당 규칙이 그대로 무효화되거나 로드 오류가 발생합니다.

여러 구독 설정이 공존할 때의 전환 로직

사용 기간이 길어지면 대부분 구독 하나만 갖고 있지 않게 됩니다. 일부 서비스 제공처는 서로 다른 구독 주소에 대응하는 여러 노선을 제공하고, 일부 사용자는 일상용 구독 하나와 특정 상황을 위한 커스텀 규칙 구독 하나를 동시에 보유합니다. 여러 설정이 공존할 때 클라이언트의 처리 방식은 대략 다음 몇 가지 논리를 따릅니다.

설정은 배타적으로 로드되며, 누적 로드가 아니다

클라이언트는 어느 시점에도 하나의 Profile만 로드해 실행 상태로 만듭니다. 설정을 전환하는 것은 본질적으로 "현재 설정을 언로드하고 다른 설정을 로드하는" 과정이며, 여러 설정의 규칙을 누적해 동시에 적용하는 것이 아닙니다. 이 부분은 오해하기 쉽습니다——두 번째 구독을 추가하면 두 설정의 규칙이 합쳐져서 적용될 것이라 생각하는 사용자가 있지만, 실제로는 전환 후 이전 설정의 노드, 프록시 그룹, 규칙이 전부 교체되며 어떤 교차 상태도 남지 않습니다.

전환 시점과 적용 범위

설정을 전환하면 프록시 그룹과 규칙 표가 다시 만들어지며, 진행 중인 연결은 보통 중단되지 않지만 새로 시작하는 연결은 즉시 새 설정의 규칙에 따라 매칭됩니다. 전환 후 특정 사이트가 갑자기 접속되지 않는다면, 새 설정에서 해당 도메인의 규칙 정책이 이전 설정과 다를 가능성이 큽니다. 서둘러 클라이언트를 재시작하기보다 먼저 새 설정의 규칙 매칭 결과를 확인하세요.

자동 업데이트와 수동 전환의 경계

각 구독은 개별적으로 자동 업데이트 주기를 설정할 수 있으며, 자동 업데이트는 해당 구독 자체의 내용만 갱신할 뿐 현재 선택된 설정이 어느 것인지에는 영향을 주지 않습니다. 즉, 백그라운드에서는 여러 구독이 각자의 주기에 따라 동시에 업데이트될 수 있지만, 화면상 실제 적용되는 것은 항상 수동으로 선택한 설정 하나이며, 업데이트 동작과 전환 동작은 서로 독립된 별개의 로직으로 서로를 촉발하지 않습니다.

이름 규칙: 다중 설정을 헷갈리지 않게 만들기

설정 수가 늘어나면 가장 먼저 문제가 되는 것은 기술적인 부분이 아니라 "설정 착각"이라는 인적 실수입니다——업무용 규칙 세트로 전환하려 했는데 내용이 비슷한 다른 구독을 클릭하는 식입니다. 명확한 이름 규칙을 습관화하면 조사 시간을 크게 줄일 수 있습니다.

  • 용도별 접두사로 이름 짓기: 예를 들어 "일상-XX서비스", "업무-규칙구독", "테스트-자체구축노드"처럼 이름만 보고도 사용 시나리오를 알 수 있게;
  • 업데이트 주기나 기한 표시: 특정 구독이 속도 테스트용 단기 구독이라면 이름에 날짜나 "임시" 표시를 붙여 정식 설정 목록에 오래 섞여 있지 않게 하기;
  • 기본 파일명 사용 피하기: 많은 클라이언트가 구독을 가져오면 "config.yaml" 같은 기본 이름을 자동 생성하는데, 여러 구독이 모두 이 이름이면 구분이 거의 불가능하므로 가져온 즉시 이름을 바꿀 것;
  • 구독 출처 기록: 클라이언트가 비고 필드를 지원한다면 구독에 대응하는 서비스 제공처나 용도를 비고에 적어두면 반년 후 목록을 봐도 바로 기억을 떠올릴 수 있음.

규칙 덮어쓰기 방지 관리법

"규칙 덮어쓰기"는 보통 두 설정의 규칙이 실제로 병합되어 충돌하는 것을 뜻하지 않습니다. 사용자가 같은 설정 안에서 수동으로 항목을 추가하거나 수정한 뒤, 다음번 구독 자동 업데이트 시 서버가 반환한 새 내용으로 전체가 덮어써지면서 수동 변경 내용이 사라지는 것을 말합니다. 이는 다중 설정 관리에서 가장 걸려 넘어지기 쉬운 부분입니다.

덮어쓰기가 발생하는 근본 원인

대부분의 클라이언트는 구독을 업데이트할 때 원격에서 반환된 전체 YAML 내용으로 로컬 파일을 통째로 교체하며, 필드 단위로 병합하지 않습니다. 즉, 로컬에서 규칙 목록에 수동으로 커스텀 규칙을 추가했는데 그 규칙이 서버가 반환한 원본 구독에 존재하지 않는다면, 다음 자동 업데이트가 발생하는 순간 이 수동 추가 규칙은 전체 파일이 교체되면서 사라지며 아무런 알림도 없습니다.

세 가지 회피 방법

  1. 클라이언트의 "오버라이드" 또는 "추가 규칙" 기능 사용: 일부 클라이언트는 구독 외에 별도의 로컬 오버라이드 파일을 유지할 수 있게 지원하며, 구독 업데이트 시 구독 자체의 내용만 교체하고 로컬 오버라이드 부분은 독립적으로 유지되어 별도로 적용됩니다. 가장 권장하는 방법;
  2. 해당 구독의 자동 업데이트를 끄고 수동으로 관리: 이 설정에서 규칙을 자주 수동으로 조정해야 하고 서비스 제공처의 업데이트 빈도가 낮다면, 자동 업데이트를 직접 끄고 변경 내용은 직접 "업데이트" 버튼을 누를 때만 덮어써지게 하면 위험을 통제할 수 있음;
  3. 커스텀 규칙을 별도 설정으로 저장하고 구독 변환 도구로 병합: 어느 정도 손재주가 있는 사용자에게 적합. 수동 규칙을 독립된 규칙 파일로 관리하고, 구독 변환 서비스를 통해 원본 구독과 커스텀 규칙을 이어붙여 새로운 구독 주소로 만들면, 매번 업데이트 시 가져오는 것은 이미 병합된 내용이 되어 클라이언트에서 반복적으로 수동 보완할 필요가 없음.
Notice / 주의

클라이언트가 로컬 오버라이드 기능을 지원하는지 확실치 않다면, 먼저 수동 변경 테스트를 해보세요: 변경 후 즉시 수동으로 "구독 업데이트"를 한 번 실행해 변경 내용이 지워지는지 확인합니다. 동작을 확인한 뒤 어떤 방식으로 장기 관리할지 결정하는 것이, 나중에 규칙을 잃고 나서 복구하는 것보다 훨씬 마음 편합니다.

일상 유지관리를 위한 몇 가지 점검 동작

설정 수가 늘어난 뒤에는 몇 가지 고정된 점검 습관을 들이는 것이 좋습니다. 문제가 커지기 전에 이상을 발견할 수 있습니다:

  • 주기적으로 규칙 목록을 열어 마지막 줄의 MATCH 최종 정책이 가리키는 프록시 그룹이 예상과 일치하는지 확인해, 구독 업데이트로 최종 정책이 몰래 바뀌는 것을 방지;
  • 설정을 전환한 뒤 클라이언트 내장 지연 시간 테스트 기능으로 노드 상태를 한 번 갱신하세요. 새 설정의 노드 풀은 이전 설정과 완전히 같지 않은 경우가 많음;
  • 여러 설정을 동시에 유지한다면 일정 기간마다 더 이상 쓰지 않는 구독을 정리해 잘못 전환할 가능성을 줄이기;
  • 수동으로 추가한 규칙은 손이 가는 김에 로컬 백업을 남기는 습관을 들이세요. 오버라이드 기능을 사용하더라도 클라이언트 데이터 손실에 대비해 텍스트 사본을 하나 보관하는 것을 권장.

노드, 프록시 그룹, 규칙 세 계층의 참조 관계를 정리하고, 명확한 이름 규칙과 적절한 업데이트 전략을 함께 적용하면, 다중 설정 공존은 부담이 되지 않으며 오히려 각 상황별 트래픽 분산을 더 정밀하고 통제 가능하게 만들어 줍니다.