프록시 그룹이 해결하는 것은 "어떤 노드를 쓸지"의 문제

규칙 파일의 DOMAIN-SUFFIX,google.com,PROXY 규칙에서 PROXY는 특정 노드가 아니라 프록시 그룹의 이름입니다. 규칙은 "이 트래픽이 어떤 그룹을 사용해야 하는지"만 판단하며, 그룹 내에서 실제로 어떤 노드를 쓰고 어떻게 전환할지는 프록시 그룹 자체의 스케줄링 로직이 결정합니다. 이렇게 설계한 장점은, 구독을 바꿔서 노드가 전부 바뀌어도 규칙은 항상 그룹 이름을 참조하므로 규칙 파일을 전혀 수정할 필요가 없다는 것입니다.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 香港01
      - 新加坡01
      - DIRECT

위의 가장 간단한 예시에서 PROXY 그룹의 타입은 select입니다. 즉 어떤 노드를 쓸지는 직접 수동으로 선택하며, 클라이언트 UI에서 한 번 클릭하면 전환되고 자동으로는 바뀌지 않습니다.

네 가지 스케줄링 방식을 하나씩 설명

1. select: 완전 수동, 자동 전환 없음

select는 가장 단순한 타입으로, 클라이언트는 proxies 목록의 노드를 그대로 보여주기만 하며 어떤 것을 쓸지는 직접 클릭해서 선택하고 절대 자동으로 전환되지 않습니다. 이미 어떤 노드의 경로가 안정적인지 알고 있어서 프로그램이 "알아서" 전환하는 것을 원치 않는 상황에 적합합니다.

2. url-test: 지연 시간이 가장 낮은 노드를 자동 선택

url-test는 일정한 주기(interval)로 테스트 주소에 접속해 그룹 내 각 노드의 지연 시간을 측정하고, 현재 가장 빠른 노드로 자동 전환합니다. UI에 표시되는 것은 읽기 전용 "현재 사용 중인 노드"로, 수동으로 고정할 수 없습니다.

proxy-groups:
  - name: 自动选优
    type: url-test
    proxies: [香港01, 香港02, 新加坡01, 日本01]
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

tolerance는 핵심 파라미터입니다: 새 노드의 지연 시간이 현재 노드보다 이 허용치(밀리초 단위)만큼 낮아야만 실제로 전환됩니다. 이는 지연 시간이 비슷한 두 노드가 계속 오락가락 전환되는 것을 막기 위한 것입니다. tolerance를 너무 작게 설정하는 것이 "노드가 계속 바뀐다"는 문제의 가장 흔한 원인입니다.

3. fallback: 기본 노드가 죽었을 때만 전환

fallback도 주기적으로 노드가 사용 가능한지 확인하지만 로직이 다릅니다: 목록의 첫 번째로 연결 가능한 노드가 실패하지 않는 한 계속 그것을 사용하며, "더 빠른 노드가 있다"는 이유로는 전환되지 않습니다. 현재 사용 중인 노드가 검사에 실패했을 때만 순서대로 다음 노드로 전환됩니다. 특정 기본 노드를 고정적으로 쓰고, 그것이 완전히 사용 불가능할 때만 백업 라인을 활성화하고 싶은 상황에 적합합니다.

proxy-groups:
  - name: 主备切换
    type: fallback
    proxies: [主力节点, 备用节点A, 备用节点B]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

4. load-balance: 트래픽을 여러 노드로 분산

load-balance는 일관성 해싱이나 라운드로빈 방식으로 서로 다른 연결을 그룹 내 여러 노드에 분산시키므로, 동시에 여러 연결이 각각 다른 노드를 사용할 수 있습니다. 모든 노드의 대역폭이 충분해서 부하를 분산시키고 싶은 상황에 적합하지만, 대가로 같은 사이트에 대한 서로 다른 요청이 서로 다른 IP에서 오는 것처럼 보일 수 있어, IP 일관성에 민감한 일부 사이트에서 문제가 발생할 수 있습니다.

proxy-groups:
  - name: 负载均衡
    type: load-balance
    proxies: [香港01, 香港02, 香港03]
    strategy: consistent-hashing
    url: "https://www.gstatic.com/generate_204"
    interval: 300

프록시 그룹은 중첩할 수 있습니다: 그룹 안에 그룹

proxies 목록에는 특정 노드 이름뿐만 아니라 다른 프록시 그룹의 이름도 쓸 수 있어, 이를 통해 계층 구조를 만들 수 있습니다. 흔히 쓰는 방식은 먼저 지역별로 url-test 자동 속도 측정 그룹을 여러 개 만든 다음, select 그룹으로 이 지역 그룹들을 모아 "이번에는 어느 지역을 주로 쓸지"를 수동으로 선택하는 것입니다:

proxy-groups:
  - name: 香港自动
    type: url-test
    proxies: [港01, 港02, 港03]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: 日本自动
    type: url-test
    proxies: [日01, 日02]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: PROXY
    type: select
    proxies: [香港自动, 日本自动, DIRECT]

이 방식의 장점은 규칙에서는 가장 바깥쪽의 PROXY만 참조하면 되고, 각 지역 내부에서 어떻게 자동 속도 측정 및 전환이 이루어지는지는 완전히 안쪽 그룹 자체의 일이라는 점입니다. 두 계층의 로직이 서로 간섭하지 않아 설정 파일도 유지보수하기 훨씬 쉬워집니다.

노드가 자주 전환되나요? 먼저 이 두 파라미터를 확인하세요

url-test를 사용했는데 "현재 노드"가 계속 전환되어 다운로드나 영상 통화 같은 장기 연결이 자주 끊긴다면, 보통 이 두 파라미터가 제대로 조정되지 않은 경우입니다: interval이 너무 짧아 속도 측정 자체가 너무 자주 일어나거나, tolerance가 너무 낮거나 설정되지 않아 지연 시간이 비슷한 두 노드가 "더 나은 선택지가 있다"고 판단되어 반복적으로 전환되는 것입니다. interval을 300초 이상으로, tolerance를 50ms 정도로 조정하면 보통 이 문제가 눈에 띄게 개선됩니다.

마지막으로

프록시 그룹 타입 선택은 결국 하나의 질문에 답하는 것입니다: "이 그룹 안의 노드에 대해, 프로그램이 얼마나 많은 결정을 대신 내려주길 원하는가?" 전혀 도와주지 않길 원하면 select, 속도를 측정해서 가장 빠른 것을 골라주길 원하면 url-test, 장애가 났을 때만 대신 처리해주길 원하면 fallback, 부하를 분산시키고 싶으면 load-balance를 사용하세요. 이 네 가지 타입의 차이를 이해한 후 분기 규칙과 함께 "누가 어떤 그룹을 써야 하는지"를 결정하면, 완전하고 유지보수하기 좋은 설정이 거의 완성됩니다. 어떤 용어의 의미가 궁금하면 언제든 용어집에서 확인할 수 있습니다.