대부분의 구독에서 기본으로 생성되는 프록시 그룹 유형은 select(수동 선택)나 url-test(자동 속도 테스트로 최적 노드 선택)이며, 이 두 가지만으로도 일상적인 요구는 충분히 충족됩니다. 하지만 노드가 많거나 안정성을 더 중요하게 여긴다면 fallback과 load-balance가 더 나은 장애 대응과 분산 효과를 제공합니다.
01네 가지 프록시 그룹 유형 한눈에 보기
| 유형 | 선택 로직 | 적용 상황 |
|---|---|---|
| select | 완전 수동 선택, 코어는 자동으로 전환하지 않음 | 어떤 노드를 쓸지 직접 정밀하게 제어하고 싶을 때 |
| url-test | 주기적으로 속도를 측정해 자동으로 지연이 가장 낮은 노드 선택 | 일상 사용, 신경 쓰고 싶지 않을 때. 대부분 구독의 기본 설정 |
| fallback | 목록 순서대로 첫 번째로 사용 가능한 노드를 사용, 현재 노드가 실패할 때만 다음으로 전환 | 명확한 "주 노드/백업 노드" 우선순위가 있고 특정 노드를 우선 사용하고 싶을 때 |
| load-balance | 알고리즘에 따라 서로 다른 연결을 여러 노드에 분산해 동시에 사용 | 노드가 여러 개이고 트래픽을 분산해 단일 노드의 과부하를 피하고 싶을 때 |
02Fallback 장애 조치 설정 예시
Fallback은 작성한 노드 순서대로 연결을 시도합니다. 목록의 첫 번째 노드가 사용 가능한 한 계속 그 노드를 쓰고, 상태 확인이 실패했을 때만 다음 노드로 전환합니다. 즉 노드의 나열 순서 자체가 우선순위입니다.
proxy-groups:
- name: "Fallback-Group"
type: fallback
proxies: ["HK-Primary", "HK-Backup", "SG-Backup"]
url: "http://www.gstatic.com/generate_204"
interval: 300위 예시에서는 "HK-Primary" 노드의 상태 확인이 정상인 동안 계속 그 노드를 사용합니다. 상태 확인이 실패했을 때만 "HK-Backup", 그다음 "SG-Backup" 순서로 시도합니다.
03Load Balance 부하 분산 설정 예시
Load Balance는 (같은 연결 내의 패킷이 아니라) 서로 다른 연결을 그룹 내 여러 노드에 분배해 트래픽을 분산시킵니다. 동시에 어떤 노드가 다운되면 새 연결이 다른 정상 노드로 자동 할당되므로 자연스럽게 어느 정도의 장애 대응 능력도 갖게 됩니다.
proxy-groups:
- name: "LoadBalance-Group"
type: load-balance
proxies: ["HK-01", "HK-02", "HK-03"]
strategy: consistent-hashing
url: "http://www.gstatic.com/generate_204"
interval: 300strategy 필드의 두 가지 값
- consistent-hashing: 연결의 목적지 주소를 기준으로 일관 해싱을 수행해, 같은 목적지는 대부분 같은 노드로 연결됩니다. 소스 IP 변경에 민감한 일부 사이트처럼 "세션 유지"가 필요한 경우에 적합합니다.
- round-robin: 순서대로 그룹 내 노드에 균등하게 분배합니다. 더 균일하게 분산되지만 같은 목적지가 항상 같은 노드로 가는 것은 보장하지 않습니다.
04어떤 것을 선택해야 할까
안정적인 노드가 1~2개뿐이라면 url-test만으로도 충분합니다. 특정 노드의 품질이 확실히 더 좋아서 우선 사용하고 나머지는 백업으로만 쓰고 싶다면 fallback을 사용하세요. 품질이 비슷한 노드가 여러 개 있고 하나의 노드로는 여러 기기의 동시 사용을 버티지 못할까 걱정된다면 load-balance가 더 적합합니다. 세 가지 유형은 중첩해서 조합할 수도 있습니다. 예를 들어 fallback 그룹을 다른 프록시 그룹의 후보 중 하나로 사용하는 식으로, 실제 구성은 보유한 노드 상황에 따라 결정하면 됩니다.
05상태 확인과 관련된 두 필드
fallback과 load-balance는 모두 백그라운드 상태 확인으로 노드 사용 가능 여부를 판단합니다. 이 동작은 url과 interval 두 필드로 제어되며, 잘못 설정하면 전환이 늦어지거나 상태 확인이 너무 빈번해 트래픽을 낭비하게 됩니다.
- url: 상태 확인 요청이 접속하는 주소로, 일반적으로 가벼운 테스트용 주소(예: http://www.gstatic.com/generate_204)를 사용합니다. 응답이 성공하면 노드가 사용 가능한 것으로 판단하며, 실제 서비스 사이트로 바꿀 필요는 없습니다.
- interval: 확인 간격(단위: 초)입니다. 값이 너무 작으면 클라이언트가 너무 자주 상태 확인 요청을 보내 불필요한 트래픽과 배터리 소모가 늘어납니다. 값이 너무 크면 노드 장애를 감지하고 전환하는 데 더 오래 걸립니다. 일반적으로 300초 전후가 균형 잡힌 선택입니다.
06자주 묻는 질문
Q: load-balance 그룹 안의 노드 수에 상한이 있나요?
엄격한 상한은 없지만, 노드가 많아질수록 상태 확인의 부담도 커집니다. 실제로는 품질이 비슷한 3~6개 노드로도 좋은 분산 효과를 얻을 수 있고, 노드가 너무 많으면 오히려 문제를 찾기 어려워집니다.
Q: 프록시 그룹을 전환할 때 연결이 끊기나요?
fallback과 load-balance는 "새 연결"이 어느 노드로 할당될지에만 영향을 주며, 이미 맺어진 연결이 강제로 끊기는 경우는 보통 없습니다. 다만 원래 노드가 실제로 다운된 상태라면 그 연결 자체도 이미 정상적으로 사용할 수 없을 가능성이 높으므로, 클라이언트가 다시 요청을 시작해야 합니다.