프록시 그룹(Proxy Group)은 규칙이 매칭된 후 실제로 어떤 노드를 사용할지 결정합니다. 많은 사람이 구독을 설정한 뒤 프록시 그룹을 한 번도 건드리지 않고 프로바이더가 제공한 기본 그룹을 그대로 사용하는데, 기본 설정은 대개 "쓸 수 있는" 수준일 뿐이며 "쓰기 좋은" 수준까지는 조정할 여지가 많이 남아 있습니다.
세 가지 유형이 각각 해결하는 문제
| 유형 | 해결하는 문제 | 대가 |
|---|---|---|
| select | 특정 노드를 수동으로 고정할 수 있어 동작이 완전히 예측 가능함 | 노드 장애 시 자동으로 전환되지 않아 수동 처리가 필요함 |
| url-test | 지연이 가장 낮은 노드를 자동으로 선택해 수동 속도 테스트와 전환이 필요 없음 | 테스트 자체가 약간의 트래픽과 시간을 소모하며, 파라미터가 부적절하면 자주 전환됨 |
| fallback | 메인 노드 장애 시 순서대로 다음 사용 가능한 노드로 자동 전환 | "사용 가능"은 연결이 된다는 뜻일 뿐, 지연이 가장 낮다는 뜻은 아님 |
| load-balance | 연결을 여러 노드에 분산시켜 단일 노드의 대역폭 부담을 줄임 | 같은 시간대의 서로 다른 연결이 다른 노드를 탈 수 있어, "동일 IP 유지"가 필요한 상황에는 부적합 |
url-test: 자동 속도 테스트의 두 가지 핵심 파라미터
url-test는 가장 흔히 사용되는 유형이지만, 많은 사람이 proxies 목록만 설정하고 그대로 둡니다. 실제로는 interval과 tolerance 이 두 파라미터가 체감 품질을 결정하는 핵심입니다.
proxy-groups: - name: Auto type: url-test proxies: [HK-01, HK-02, SG-01, JP-01] url: http://www.gstatic.com/generate_204 interval: 300 # 300초마다 속도 테스트. 너무 자주 하면 트래픽 소모가 늘어남 tolerance: 50 # 지연 차이가 50ms 미만이면 전환하지 않아, 흔들림으로 인한 빈번한 전환을 방지 lazy: true # 실제 트래픽이 없을 때는 테스트를 멈춰 배터리와 데이터를 절약
tolerance는 가장 간과되기 쉽지만 영향은 가장 큰 파라미터입니다. 0으로 설정하면 두 노드의 지연 차이가 1ms만 나도 전환이 발생해서, 오래 쓰면 "왜 자꾸 노드가 계속 바뀌지"라는 느낌을 받게 됩니다. 50~100ms 정도가 균형 잡힌 값으로, 정상적인 네트워크 흔들림은 걸러내고 지연 차이가 실제로 뚜렷할 때만 전환하게 해줍니다.
fallback: 메인 회선에 예비 회선을 붙여주기
지연은 낮지만 간혹 불안정한 "메인 노드"가 있다면, 끊길 때마다 직접 지켜보고 수동으로 전환하는 대신 fallback으로 한 겹 감싸는 것이 좋습니다. 평소에는 항상 우선순위가 가장 높은 노드를 사용하고, 사용 불가가 감지되는 즉시 자동으로 다음 노드로 넘어갑니다.
proxy-groups: - name: Fallback type: fallback proxies: [HK-Premium, Auto, SG-01] url: http://www.gstatic.com/generate_204 interval: 180
여기서 순서가 중요합니다: HK-Premium은 메인 노드로 맨 앞에 두고, Auto는 앞서 설정한 url-test 그룹으로 "더 똑똑한 예비 회선" 역할을 하며, SG-01은 마지막 안전망입니다. fallback은 순서대로 확인하며, 앞의 것이 사용 불가일 때만 다음 것을 사용합니다. 평소에는 존재를 거의 느끼지 못하지만, 메인 노드에 실제로 문제가 생겼을 때 그 가치를 발휘합니다.
load-balance: 정말 필요한 순간은 언제인가
load-balance는 "속도를 높여준다"고 오해받는 경우가 많지만, 실제로 해결하는 문제는 "단일 노드의 대역폭이 부족하다" 또는 "연결을 여러 출구로 분산하고 싶다"는 것입니다. 하나의 다운로드 작업 속도 향상에는 한계가 있는데, TCP 연결 하나는 항상 하나의 노드만 타기 때문에 동시 연결이 여러 개일 때만 분산 효과가 나타납니다.
- 동영상 시청이나 일상적인 웹 서핑이 주된 용도라면, load-balance는 거의 필요 없고 url-test만으로도 충분합니다.
- 여러 클라이언트 기기가 같은 노드 세트를 공유하거나, 여러 개의 동시 다운로드 작업이 자주 있다면, load-balance로 부하를 더 균등하게 분산할 수 있습니다.
- load-balance는 round-robin(순환 방식)과 consistent-hashing(일관성 해싱, 동일한 목적지 주소는 가능한 같은 노드를 타도록 함) 두 가지 전략을 지원합니다. 후자는 "같은 사이트는 항상 같은 출구 IP를 유지"해야 하는 경우에 더 적합합니다.
조합하기: 실용적인 3단 구조
실제 설정에서는 한 가지만 고르기보다 세 가지 유형을 겹쳐서 사용하는 것을 추천합니다:
- 가장 아래 계층에서는 url-test 그룹으로 같은 지역의 노드를 모아 자동으로 가장 빠른 노드를 선택합니다.
- 중간 계층에서는 fallback으로 한 겹 감싸서, "메인 노드"와 "url-test 그룹"을 우선순위대로 배치해 장애 시 자동으로 안전망 역할을 하게 합니다.
- 가장 바깥 계층에서는 규칙에 노출할 select 그룹을 하나 두고, 그 후보 목록에 fallback 그룹과 수동으로 선택 가능한 예비 노드 몇 개를 넣어 언제든 수동으로 개입할 수 있게 합니다.
규칙은 항상 가장 바깥의 select 그룹만 참조하도록 합니다. 속도 테스트와 페일오버 로직은 모두 그 후보 목록 안에 캡슐화되어 있어, 프록시 그룹 내부 로직을 조정할 때 규칙을 전혀 수정할 필요가 없습니다.