홈/블로그/로드 밸런싱과 페일오버

실전 가이드

로드 밸런싱과 페일오버: 여러 노드로 안정적인 연결 만들기

노드 하나에만 의존하면 언젠가 속도 제한, 불안정, 심지어 완전한 끊김을 겪게 됩니다. fallback과 load-balance라는 두 프록시 그룹 타입은 "노드 하나에 문제가 생기는 것"이 "전체 네트워크의 문제"가 되지 않도록 만들어졌습니다. 이 글에서는 각각의 판단 로직, 설정 방법, 그리고 여러 전략을 계층적으로 결합해 실제로 안정적이고 오래 쓸 수 있는 구성을 만드는 방법을 정리합니다.

🗓️ 2026년 7월 17일 ⏱️ 약 8분 소요 🔗 관련 문서: 고급 설정 · 프록시 그룹: 4가지 스케줄링 전략

단일 노드로는 버틸 수 없는 이유

노드는 항상 일정하지 않습니다. "제공자가 일시적으로 점검 중", "상류 회선이 불안정", "동시 접속자가 너무 많아 속도가 제한됨" — 이런 상황들은 노드 자체가 다운되지 않았더라도 실제 체감 품질을 눈에 띄게 떨어뜨립니다.

프록시 그룹이 수동 select 모드라면, 노드에 문제가 생겼을 때 직접 알아채고 수동으로 전환해야 하며, 그 사이의 모든 연결이 함께 멈추거나 타임아웃됩니다. fallback과 load-balance는 각각 "장애 시 전환"과 "부하 분산"이라는 다른 각도에서 이 문제를 해결하며, 서로 다른 상황을 커버하기 위해 동시에 사용할 수도 있습니다.

fallback 페일오버의 판단 로직

fallback 그룹은 설정한 순서대로 앞쪽 노드를 지속적으로 헬스체크하며, 현재 사용 중인 노드가 "비정상"으로 판정될 때만 순서상 다음 노드로 전환합니다:

config.yamlyaml
proxy-groups:
  - name: 페일오버
    type: fallback
    proxies: [메인, 백업A, 백업B]
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    max-failed-times: 3

핵심 필드 몇 가지:

  • url: 헬스체크 요청의 대상 주소입니다. 용량이 작고 전 세계적으로 접근성이 좋은 테스트 엔드포인트를 사용해, 체크 자체가 트래픽을 많이 소모하거나 해당 URL이 제한되어 오판되는 것을 피하세요.
  • interval: 헬스체크 주기(초)입니다. 너무 짧으면 불필요한 탐지 트래픽이 늘고, 너무 길면 장애 복구가 지연됩니다. 300초가 비교적 흔히 쓰이는 절충값입니다.
  • max-failed-times: 몇 번 연속 실패해야 "비정상"으로 판정할지를 정합니다. 한 번의 우발적인 타임아웃으로 잘못 전환되는 것을 막기 위함입니다.
💡

fallback은 "현재 노드가 비정상"일 때만 전환합니다. 백업 노드의 지연시간이 더 낮아도 메인 노드의 헬스체크가 정상이라면 능동적으로 전환하지 않습니다 — 이것이 url-test와 가장 큰 동작상의 차이이며, "메인 회선"을 고정해두고 다른 노드는 비상용 백업으로만 쓰고 싶은 상황에 적합합니다.

load-balance의 두 가지 분산 전략

load-balance는 "가장 좋은 것을 고르는" 방식이 아니라, 서로 다른 연결을 그룹 내 여러 노드에 능동적으로 분산시킵니다. 구체적인 분산 방식은 strategy 필드로 결정됩니다:

consistent-hashing (일관성 해싱)

  • 연결의 발신 주소를 기준으로 해시를 계산해, 같은 발신지는 대체로 같은 노드에 고정적으로 배정됨
  • "세션 유지"가 필요한 상황(연결이 바뀌는 데 민감한 사이트/게임 등)에 더 적합함
  • 특정 노드가 제거되어도 그 노드에 매핑됐던 일부 연결만 영향을 받고 전체가 재분배되지 않음

round-robin (라운드로빈)

  • 새 연결을 그룹 내 노드에 순서대로 배정해 더 균등하게 분산됨
  • 같은 발신지가 항상 같은 노드에 머문다는 보장이 없어 "세션이 바뀌는" 현상이 생길 수 있음
  • 짧고 독립적인 연결이 많고 세션 유지가 필요 없는 상황에 더 적합함
config.yamlyaml
proxy-groups:
  - name: 로드밸런스
    type: load-balance
    strategy: consistent-hashing
    proxies: [노드A, 노드B, 노드C]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

특별한 이유가 없다면 consistent-hashing이 연결 안정성에 미치는 영향이 더 적어 보통 더 안전한 기본값입니다.

실전: 계층적으로 결합해 안정적인 구성 만들기

세 가지 전략은 서로 배타적이지 않습니다. 실제 설정에서 흔히 쓰는 방식은 계층적으로 중첩하는 것입니다 — 바깥쪽 층에는 select를 두어 수동 마스터 스위치로 삼고, 중간 층에는 url-test나 load-balance로 자동 스케줄링을 하며, 극단적인 상황을 위해 fallback을 최후의 안전장치로 둡니다:

config.yamlyaml
proxy-groups:
  - name: PROXY
    type: select
    proxies: [자동 스케줄링, 수동 지정]

  - name: 자동 스케줄링
    type: fallback
    proxies: [고속 풀, 백업 회선]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: 고속 풀
    type: load-balance
    strategy: consistent-hashing
    proxies: [노드A, 노드B, 노드C]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

이렇게 구성하면 평상시에는 "고속 풀"이 연결을 세 노드에 분산시키고, 이 계층 전체에 이상(예: 소속 데이터센터 장애)이 생기면 가장 바깥의 fallback이 자동으로 "백업 회선"으로 전환하며, PROXY 계층에서는 항상 수동으로 개입할 수 있는 여지를 남겨둡니다.

흔한 실수

  1. 헬스체크 주소를 방문 빈도가 낮은 일반 웹사이트로 설정: 이런 주소는 응답 시간 변동이 커서 정상 노드를 "비정상"으로 오판하기 쉽습니다. 반드시 가볍고 안정적인 테스트 엔드포인트를 사용하세요.
  2. load-balance에서 속도 차이가 큰 노드를 섞어 사용: 라운드로빈/해싱 분배는 노드 속도를 고려하지 않으므로, 섞어 쓰면 연결마다 체감 품질이 들쭉날쭉해집니다. 같은 load-balance 그룹 안의 노드는 품질을 비슷하게 맞추세요.
  3. interval을 너무 짧게 설정: 빈번한 헬스체크는 노드 리소스와 본인의 트래픽을 함께 소모합니다. 대부분의 상황에서 300초보다 짧게 설정할 필요는 없습니다.

설정 후 전환 동작이 예상과 다르다면 고급 설정 가이드의 프록시 그룹 섹션과 대조해 각 필드의 의미를 다시 확인하거나, Dashboard를 열어 각 프록시 그룹의 현재 상태를 직접 확인해보세요.

다음으로 읽어보세요