GEOIP와 GEOSITE가 다른 점
GEOIP는 연결의 목적지 IP(또는 코어가 판단한 최종 목적지)를 GeoIP/GeoLite 등의 MMDB로 조회해 국가·지역 코드와 맞춥니다. 그래서 “이 IP가 어느 나라에 속하는가”를 기준으로 DIRECT와 PROXY를 갈라야 할 때 유용합니다. 반면 GEOSITE는 도메인 이름이 규칙 엔진에 전달된 뒤, geosite.dat(또는 동등한 데이터 소스) 안의 태그 이름과 대조합니다. 즉 “google”, “cn”, “geolocation-!cn” 같은 커뮤니티에서 통용되는 라벨에 어떤 접미사·도메인이 묶여 있는지에 의존합니다. 둘 다 “한 줄로 광역을 잡는” 도구이지만, 입력 정보가 IP냐 호스트냐에서 출발이 갈립니다.
HTTPS처럼 처음에는 IP만 보이는 경로에서는 호스트명이 비어 있으면 GEOSITE가 작동하지 않을 수 있습니다. 이때는 Sniffer로 SNI 등에서 이름을 복원하거나, DNS 정책을 정렬해 “규칙이 볼 이름”을 맞추는 편이 안전합니다. 반대로 순수 IP 접속만 하는 클라이언트는 GEOIP나 IP-CIDR 쪽이 더 직접적입니다.
1전제: mode: rule과 geodata
GEOIP·GEOSITE 줄은 mode가 rule일 때 의미가 있습니다. 또한 코어가 geodata를 읽을 수 있어야 합니다. 배포본에 Country.mmdb·geosite.dat가 포함되거나, 프로필에서 경로를 명시하는 방식이 흔합니다. GUI 클라이언트는 데이터 파일을 자동으로 내려받는 경우가 많지만, 컨테이너·서버에서는 볼륨에 파일이 없으면 규칙이 조용히 실패하거나 예전 DB만 쓰는 일이 생깁니다. Docker 배포 글처럼 설정 디렉터리를 영속화해 두면 경로 문제를 줄일 수 있습니다.
TUN을 켜 트래픽이 코어를 통과하게 만드는 것은 TUN 가이드와 맞물립니다. 시스템 프록시만으로는 일부 앱이 우회해 GEOIP까지 도달하기 전에 다른 경로로 나가기도 합니다.
2인라인 규칙 문법 스케치
아래는 개념을 잡기 위한 예시입니다. 키 이름·옵션은 사용 중인 Mihomo 버전 문서를 반드시 확인하세요. 국가 코드는 보통 ISO 3166-1 alpha-2(예: KR, US, JP, CN)를 씁니다.
# Sketch — merge into your real profile; verify against Mihomo docs
rules:
- GEOSITE,google,PROXY
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT,no-resolve
- GEOIP,private,DIRECT,no-resolve
- MATCH,PROXY
no-resolve는 DNS 조회를 강제하지 않도록 하는 플래그로 자주 쓰입니다. 잘못 쓰면 불필요한 리졸브나 루프가 생길 수 있으니, 공식 문서의 의미를 확인한 뒤 프로필에 맞게 넣으세요. private는 사설 대역을 국가 DB가 아닌 내장 사설 목록으로 처리하는 관용적인 쓰임이 있습니다(버전별로 키워드가 다를 수 있음).
팁: GEOSITE 태그 이름은 구독·룰셋 제작자가 정한 목록에 따릅니다. Loyalsoldier·ACL4SSR 등 서로 다른 geosite 빌드는 같은 태그라도 내용이 다를 수 있으니, Rule Provider 비교 글과 함께 “내가 쓰는 데이터 파일이 무엇인지”를 먼저 고정하는 것이 좋습니다.
3rule-providers와 RULE-SET
인라인 rules만으로는 유지보수가 어려울 때가 많습니다. 원격이나 로컬의 규칙 파일을 rule-providers로 등록하고, rules 안에서는 RULE-SET 한 줄로 끌어오는 패턴이 일반적입니다. 이때 RULE-SET 안에도 GEOIP·GEOSITE 타입 규칙이 들어갈 수 있습니다(제공자·형식에 따름).
# Sketch — provider type/url/path must match your setup
rule-providers:
my-geosite:
type: http
behavior: domain
url: "https://example.com/rules/geosite.yaml"
path: ./ruleset/geosite.yaml
interval: 86400
rules:
- RULE-SET,my-geosite,PROXY
- GEOIP,CN,DIRECT,no-resolve
- MATCH,DIRECT
behavior는 domain·ipcidr·classical 등으로 나뉘며, 받은 파일 형식과 맞아야 합니다. 잘못 맞추면 “파일은 받았는데 한 줄도 안 맞는다”는 상태가 됩니다. 구독 상점이 제공하는 통합 프로필을 쓰는 경우에도, 최종적으로 어떤 RULE-SET이 GEOIP/GEOSITE를 포함하는지 로그로 확인하는 습관이 중요합니다.
4규칙 순서: 위에서 아래로, 한 번만 걸림
Clash 계열은 rules를 위에서 아래로 평가하고, 먼저 맞는 한 줄에서 끝납니다. 그래서 넓은 GEOIP를 너무 위에 두면, 그 아래의 세밀한 DOMAIN-SUFFIX까지 도달하지 못합니다. 반대로 특정 사이트 예외를 위에 두고 GEOIP,XX로 나머지를 처리하는 식이 흔합니다.
IP 기반 줄(GEOIP, IP-CIDR)과 도메인 기반 줄(GEOSITE, DOMAIN)을 섞을 때는, 스니퍼·DNS 때문에 “같은 연결인데 평가 시점에 보이는 정보가 다름”이 생기지 않는지도 함께 봐야 합니다. 순서만 바꿔도 체감이 크게 달라집니다.
5반전·예외 패턴
일부 프로필에서는 특정 국가가 아닌 나머지 전부를 프록시에 태우고, 몇몇 국가만 직접 연결하는 식의 요구가 있습니다. Mihomo 문법에는 부정·반전을 표현하는 관용이 있을 수 있으니(예: 국가 앞의 ! 등), 현재 버전의 공식 예시를 그대로 따르는 것이 안전합니다. 잘못된 반전은 “전부 DIRECT”나 “전부 PROXY” 같은 극단으로 이어지기 쉽습니다.
주의: 예시 YAML을 포럼에서 복사할 때 정책 그룹 이름(PROXY, DIRECT, 🇰🇷 KR 등)이 자신의 프로필에 실제로 존재하는지 확인하세요. 이름이 하나라도 어긋나면 재로드 오류이거나 조용히 기본 그룹으로 떨어질 수 있습니다.
6자주 나는 실수
- HTTPS에서 호스트가 비어 GEOSITE가 안 맞음: Sniffer·DNS를 같이 점검합니다.
- GEOIP DB가 오래됨 또는 경로 오류: CDN·클라우드 IP가 예상과 다른 국가로 잡히는 현상이 납니다.
no-resolve남용: 필요한 연결에서 리졸브가 막혀 규칙이 엇나갈 수 있습니다. 문서 의미를 확인합니다.- RULE-SET과 behavior 불일치: domain/ip/classical 혼동이 가장 흔한 설정 실수 중 하나입니다.
- 앱별 출구가 필요: 도메인·국가만으로 부족하면 PROCESS-NAME을 병행합니다.
7검증: 로그와 패널
저장 후에는 추측하지 말고 연결 로그에서 (1) 어떤 줄이 매칭됐는지 (2) 목적지가 IP인지 호스트인지 (3) 선택된 정책 그룹이 무엇인지를 확인합니다. GUI가 없다면 Yacd 패널이 디버깅에 도움이 됩니다. DNS가 엇나가면 DNS 유출 방지 가이드의 순서를 먼저 맞추는 편이 좋습니다.
정리
Clash Meta·Mihomo에서 GEOIP는 국가·지역 단위로 IP를 묶고, GEOSITE는 도메인 집합 태그로 트래픽을 묶는 기둥입니다. 둘 다 rule 모드·geodata·그리고 (도메인 쪽은) 이름 정보가 규칙까지 도달하는 경로가 전제입니다. RULE-SET으로 외부 규칙을 끌어오면 유지보수가 쉬워지고, 순서만으로도 정책 체감이 크게 바뀝니다. PROCESS-NAME·Sniffer 글과 역할을 나눠 보면, 같은 구독이라도 원하는 대로 다듬기 쉬워집니다.
클라이언트는 릴리스 직링크보다 사이트 다운로드 허브에서 고르는 편이 플랫폼·빌드 혼선이 적습니다. 오픈소스 저장소는 이슈·라이선스 확인용으로 두고, 아래 링크에서 받아 GEOIP·GEOSITE 줄을 바로 시험해 보세요.