01 프록시 그룹 고급 사용법
프록시 그룹은 노드 그룹이 자동 또는 수동으로 어떻게 선택될지를 결정합니다. 적절한 유형을 선택하면 일상 사용의 안정성을 크게 높일 수 있습니다.
| 타입 | 동작 | 적용 상황 |
|---|---|---|
| select | 완전히 수동으로 선택하며 자동 전환하지 않음. | 특정 노드를 장기간 고정해서 사용하거나, 경로를 수동으로 제어하려는 경우. |
| url-test | 정기적으로 속도를 측정해 지연 시간이 가장 낮은 노드로 자동 전환. | 일상 사용의 첫 번째 선택으로, 수동 개입 없이 비교적 좋은 경로를 얻을 수 있음. |
| fallback | 순서대로 노드를 시도하며, 현재 노드가 실패했을 때만 다음으로 전환. | 특정 메인 노드를 우선 사용하고, 장애가 발생했을 때만 전환하고 싶은 경우. |
| load-balance | 하나의 노드만 사용하지 않고 여러 노드 간에 연결을 분산. | 여러 노드의 대역폭이 제한적이어서 대역폭을 합치거나 부하를 분산하고 싶은 경우. |
| relay | 여러 노드를 순서대로 연결해 트래픽이 각 홉을 차례로 거칩니다. | 익명성을 높이거나 특정 제한을 우회하기 위해 다단계 경로가 필요한 경우에 사용하며, 속도는 느려집니다. |
# 조합 사용 예시: 바깥쪽은 select로 지역을 수동 전환, 안쪽은 url-test로 자동 최적화
proxy-groups:
- name: "PROXY"
type: select
proxies: ["HK-AUTO", "SG-AUTO", "JP-AUTO"]
- name: "HK-AUTO"
type: url-test
proxies: ["HK-01", "HK-02"]
url: "http://www.gstatic.com/generate_204"
interval: 300팁:프록시 그룹은 서로 중첩하여 참조할 수 있습니다（위 예시처럼）. 이는 "지역 수동 선택 + 노드 자동 최적화" 2단계 구조를 만들 때 흔히 사용하는 방식입니다. 전체 필드 설명은 설정 문서의 proxy-groups 필드를 참고하세요.
02 TUN 모드 상세 설명과 설정
TUN 모드는 시스템 네트워크 계층에 가상 네트워크 어댑터를 만들어 기기의 거의 모든 네트워크 트래픽을 처리합니다. 시스템 프록시 모드보다 호환성이 더 좋으며, 특히 시스템 프록시 설정을 따르지 않는 게임이나 일부 클라이언트 소프트웨어에 유용합니다.
# TUN 모드를 켜는 최소 설정
tun:
enable: true
stack: gvisor
auto-route: true
auto-detect-interface: true
# TUN 모드는 Fake-IP와 함께 켜는 것을 추천
dns:
enable: true
enhanced-mode: fake-ip운영체제별 권한 설정 방식
| 시스템 | 권한 설정 방식 |
|---|---|
| Windows | 클라이언트를 관리자 권한으로 실행하세요. 처음 켤 때 TUN/TAP 드라이버가 자동으로 설치됩니다. |
| macOS | 처음 켤 때 네트워크 확장이나 VPN 설정 설치를 요청하므로, 시스템 설정에서 허용을 확인하세요. |
| Android / iOS | 시스템에서 VPN 연결 허용 메시지가 표시되며, 수동으로 허용을 클릭해야 합니다. |
| Linux | root 권한으로 실행하거나 바이너리 파일에 CAP_NET_ADMIN 권한을 설정해야 합니다. |
팁:TUN 모드를 켠 후 인터넷에 연결되지 않으면, 먼저
auto-route와 auto-detect-interface가 모두 켜져 있는지 확인하세요. 여전히 문제가 있다면 stack을 gvisor에서 system으로 전환해 네트워크 스택 호환성 문제인지 확인해보세요.03 Fake-IP와 DNS 심화 설정
Fake-IP는 코어가 DNS 해석 단계에서 가상의 로컬 주소를 반환하고, 실제 연결 대상 판단은 트래픽이 코어를 거칠 때로 지연시키는 방식입니다. 이렇게 하면 도메인 매칭 규칙（DOMAIN-SUFFIX 등）이 더 정확하게 적용되며, TUN 모드에서 추천하는 조합 방식입니다.
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "localhost.ptlogin2.qq.com"
nameserver:
- 223.5.5.5
- 119.29.29.29
fallback:
- tls://1.1.1.1:853
- tls://8.8.8.8:853필드 설명
| 필드 | 설명 |
|---|---|
| fake-ip-range | Fake-IP에서 사용하는 가상 주소 대역으로, 보통 실제 LAN 주소와의 충돌을 피하기 위해 프라이빗 네트워크 대역을 사용합니다. |
| fake-ip-filter | Fake-IP를 사용하지 않는 도메인 화이트리스트로, LAN 내 기기나 로그인 인증 등의 상황에서는 자주 제외가 필요합니다. |
| nameserver | 일반 해석에 사용하는 상위 DNS로, 중국 본토 주소는 중국 본토 해석 노드 사용을 추천합니다. |
| fallback | nameserver의 해석 결과가 오염으로 판정될 때（반환된 IP가 예상 지역이 아닌 경우 등）사용하는 백업 암호화 DNS. |
팁:LAN 내 라우터 관리 페이지나 LAN 직접 연결이 필요한 일부 로그인 인증 서비스는, 잘못된 프록시로 인해 접속이 안 되는 것을 방지하기 위해
fake-ip-filter에 추가하는 것을 추천합니다.04 Rule Provider 규칙 세트 고급 사용법
규칙 세트는 대량의 규칙을 원격 파일에 통합 관리하고 클라이언트가 정기적으로 가져와 업데이트함으로써 수동으로 하나씩 작성하고 관리하는 번거로움을 줄여줍니다. 서로 다른 behavior의 규칙 세트를 조합하면 지속적으로 업데이트 가능한 완전한 분기 방안을 구성할 수 있습니다.
rule-providers:
direct-domain:
type: http
behavior: domain
url: "https://example.com/direct-domain.txt"
path: ./ruleset/direct-domain.yaml
interval: 86400
private-ip:
type: http
behavior: ipcidr
url: "https://example.com/private-ip.txt"
path: ./ruleset/private-ip.yaml
interval: 86400
rules:
- RULE-SET,private-ip,DIRECT
- RULE-SET,direct-domain,DIRECT
- MATCH,PROXY팁:업데이트 주기（
interval）는 너무 짧게 설정하지 않는 것을 추천합니다. 규칙 세트는 보통 자주 변경되지 않으며, 너무 빈번하게 가져오면 불필요한 네트워크 요청만 늘어납니다. 자세한 선택 방법은 블로그 글 「Rule Provider 규칙 세트 완전 가이드」를 참고하세요.05 성능과 안정성 최적화 제안
1
규칙 목록 간결화규칙 수가 많을수록 매칭에 드는 비용이 커집니다. 사용 빈도가 낮은 규칙은 규칙 세트로 통합하고, 자주 사용하는 사용자 규칙 몇 개만 로컬 목록에 남기세요.
2
속도 측정 간격을 적절히 설정url-test의 interval을 너무 짧게 설정하면 불필요한 트래픽과 CPU 사용량이 늘어나고, 너무 길게 설정하면 노드 이상 발생 시 전환이 늦어집니다. 300~600초가 적절한 균형점입니다.
3
불필요한 다단계 연결 피하기relay 유형의 다단계 노드 연결은 지연 시간을 크게 늘리므로, 정말 필요한 경우（다중 경로가 필요한 경우 등）에만 사용하세요.
4
필요에 따라 로그 레벨 설정일상적인 사용에서는 log-level을 warning이나 error로 설정하는 것을 추천합니다. 문제 해결 시에만 임시로 debug로 전환하여 장기간 대량의 로그 파일이 생성되는 것을 방지하세요.
5
코어와 클라이언트 버전 정기 확인새 버전에는 보통 성능 최적화와 프로토콜 호환성 수정이 포함되어 있으므로, 다운로드 페이지에서 정기적으로 업데이트를 확인하는 것을 추천합니다.