필요한 사이트를 위한 프록시: sing-box 및 mihomo 도메인

전형적인 상황: 독일 Amazon에서 상점을 열려면 독일 IP로 접속해야 하고, 미국의 공급자 대시보드는 미국 IP로 접속해야 하며, YouTube, 업무용 메신저 및 시스템 업데이트는 직접 연결해야 합니다. 시스템 전체에 프록시를 활성화하는 것은 불편하고 비용이 많이 듭니다: 프록시를 통해 기가바이트를 결제할 때 모든 백그라운드 트래픽이 소모됩니다. 수동으로 켜고 끄는 것은 가장 불편한 순간에 잊어버리게 됩니다. 해결책은 도메인 기반 라우팅: 로컬 클라이언트가 어떤 사이트를 어떤 프록시를 통해 연결할지, 어떤 사이트는 직접 연결할지를 스스로 결정합니다. 아래는 2026년 가장 인기 있는 두 엔진인 sing-box와 mihomo(구 Clash Meta)의 작업 구성과 일반적으로 이 схем이 실패하는 함정에 대한 설명입니다.

브라우저의 프록시와 PAC 파일보다 나은 점

브라우저 설정이나 확장 프로그램의 프록시는 해당 브라우저에서만 작동합니다. PAC 파일은 도메인에 따라 프록시를 선택할 수 있지만, 여전히 브라우저와 시스템 설정 내에서만 작동합니다 — 데스크톱 마켓플레이스 클라이언트, Telegram, Python 스크립트 또는 콘솔 유틸리티는 이를 무시합니다.

sing-box와 mihomo는 더 낮은 수준에서 작동합니다: 가상 네트워크 인터페이스를 설정하고 (TUN 모드) 모든 프로그램의 트래픽을 통과시킵니다. 이후 각 연결은 규칙 목록을 따라갑니다: 도메인, IP 서브넷, 프로세스 이름, 포트. 규칙이 일치하면 연결이 지정된 출력(필요한 국가의 프록시 또는 직접 연결)으로 나갑니다.

실제로 이것이 주는 이점은 다음과 같습니다:

트래픽 절약. 유료 프록시는 작업 사이트에만 사용되고, 비디오, 업데이트 및 클라우드 백업은 직접 연결됩니다.
동시에 여러 국가. amazon.de는 독일 출구를 통해, walmart.com는 미국 출구를 통해, 전환 없이 연결됩니다.
프로그램별 규칙. 특정 프로세스를 프록시로 전체 전송할 수 있습니다 (예: 데스크톱 클라이언트 또는 스크립트), 나머지는 건드리지 않고요.
인간의 실수 감소. 프록시가 켜져 있는지 기억할 필요가 없으며, 사이트는 항상 "올바른" IP로 열립니다.

필요한 것

SOCKS5 또는 HTTP를 지원하고 로그인 및 비밀번호로 인증하는 프록시. 두 엔진 모두 로그인과 비밀번호를 스스로 전달할 수 있으며, 로컬 게이트웨스는 필요하지 않습니다.
클라이언트: sing-box의 경우 Android, iOS 및 macOS용 공식 애플리케이션 또는 Windows/Linux용 커널; mihomo의 경우 Clash Verge Rev 또는 FlClash와 같은 그래픽 인터페이스.
프록시를 통해 연결해야 할 도메인 목록. 미리 수집하는 것이 좋습니다 — 아래에서 설명합니다.

옵션 1: sing-box (버전 1.12 이상)

버전에 대한 중요한 주의사항. 많은 인터넷의 구성은 구 버전 sing-box에 맞춰 작성되었으며 최신 빌드에서는 실행되지 않습니다. 공식적으로 지원되지 않는 기능 목록: geosite 및 geoip는 1.12.0에서 제거됨 (대신 rule-set 사용), 규칙 내의 outbound 필드는 1.11부터 동작으로 변경됨 ("action": "route"), 구식 DNS 서버 형식은 1.14.0에서 제거되었으며, 특수 출력 block 및 dns는 1.13.0에서 제거되었습니다. 작성 시점의 최신 안정 버전은 1.14입니다.

최소 작업 구성: 몇 개의 도메인에 대한 독일 거주자 프록시, 나머지는 직접 연결됩니다.

{
  "log": { "level": "info" },
  "dns": {
    "servers": [ { "type": "local", "tag": "local" } ]
  },
  "inbounds": [
    {
      "type": "tun",
      "tag": "tun-in",
      "address": [ "172.18.0.1/30" ],
      "auto_route": true,
      "strict_route": true
    }
  ],
  "outbounds": [
    {
      "type": "socks",
      "tag": "resi-de",
      "server": "ХОСТ_ИЗ_КАБИНЕТА",
      "server_port": 1080,
      "username": "ЛОГИН",
      "password": "ПАРОЛЬ"
    },
    { "type": "direct", "tag": "direct" }
  ],
  "route": {
    "auto_detect_interface": true,
    "default_domain_resolver": "local",
    "rules": [
      { "action": "sniff" },
      { "protocol": "dns", "action": "hijack-dns" },
      {
        "network": "udp",
        "port": 443,
        "domain_suffix": [ "amazon.de", "otto.de" ],
        "action": "reject"
      },
      {
        "domain_suffix": [ "amazon.de", "otto.de", "ipinfo.io" ],
        "action": "route",
        "outbound": "resi-de"
      }
    ],
    "final": "direct"
  }
}

호스트, 포트, 로그인 및 비밀번호는 공급자 대시보드에서 가져오세요. 포트 1080은 예시일 뿐입니다.

각 부분의 기능

TUN 입력 (auto_route)는 시스템 전체의 트래픽을 sing-box로 전달합니다. strict_route는 Windows에서 DNS 유출 방지를 위한 방화벽 규칙을 추가합니다 (문서에서는 이것이 일부 프로그램, 예: VirtualBox를 망가뜨릴 수 있다고 경고합니다).
"action": "sniff" — 핵심 줄입니다. TUN을 통해 IP 주소로 연결이 들어오고 도메인으로는 들어오지 않습니다. 스니핑은 TLS 핸드쉐이크(SNI) 또는 HTTP 헤더에서 사이트 이름을 추출하고, 그 후에만 domain_suffix 규칙이 작동합니다. 이 줄이 없으면 도메인 규칙이 조용히 작동하지 않으며 — "구성이 적용되지 않음"의 일반적인 원인입니다.
hijack-dns는 시스템의 DNS 요청을 가로채고 이를 sing-box의 DNS 모듈에 전달합니다.
UDP 443에 대한 reject 규칙은 프록시 도메인에 대해 QUIC (HTTP/3)를 비활성화합니다. 브라우저는 일반 HTTPS로 롤백되며 TCP를 통해 프록시로 전송됩니다. 이유는 함정 섹션에서 설명합니다.
domain_suffix는 도메인과 모든 하위 도메인을 포착합니다: amazon.de는 www.amazon.de 및 sellercentral.amazon.de를 포함합니다.
auto_detect_interface는 sing-box의 출발 연결을 물리적 네트워크 어댑터에 바인딩합니다. 이 없이는 프록시 서버로의 트래픽이 다시 TUN으로 들어가게 되어 라우팅 루프가 발생합니다.
final: direct — 어떤 규칙과도 일치하지 않는 모든 것은 직접 연결됩니다.

여러 국가 및 프로그램별 규칙

두 번째 출구는 또 다른 socks 객체로 추가되며 고유한 태그(예: resi-us)와 별도의 규칙이 필요합니다. 프로그램을 프록시로 전체 전송하려면 process_name 필드를 사용하는 규칙이 필요합니다 (Windows, macOS 및 Linux에서 작동):

{
  "process_name": [ "python.exe" ],
  "action": "route",
  "outbound": "resi-us"
}

규칙은 위에서 아래로 첫 번째 일치하는 항목까지 확인되므로, 특정 규칙은 일반 규칙보다 위에 배치하세요.

옵션 2: mihomo (Clash Meta)

mihomo는 성숙한 그래픽 인터페이스가 있어 편리하며, 구성은 YAML로 작성되어 읽기 쉽습니다. 동일한 시나리오:

tun:
  enable: true
  stack: gvisor
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query

proxies:
  - name: resi-de
    type: socks5
    server: ХОСТ_ИЗ_КАБИНЕТА
    port: 1080
    username: ЛОГИН
    password: ПАРОЛЬ

rule-providers:
  work-de:
    type: inline
    behavior: classical
    payload:
      - DOMAIN-SUFFIX,amazon.de
      - DOMAIN-SUFFIX,otto.de
      - DOMAIN-SUFFIX,ipinfo.io

rules:
  - RULE-SET,work-de,resi-de
  - MATCH,DIRECT

sing-box와의 주요 차이점:

fake-ip 모드는 "연결이 IP로 들어왔고 도메인으로는 들어오지 않았다"는 문제를 다르게 해결합니다: mihomo는 DNS 요청에 가짜 주소로 응답하고, 해당 도메인과의 관계를 기억하며, 이를 기반으로 규칙을 적용합니다. 실제 사이트의 주소는 프록시 서버가 자신의 측에서 알아냅니다.
규칙 세트 (rule-providers)는 별도의 목록으로 유지하는 것이 편리합니다. inline 유형은 도메인을 구성 내에 직접 저장하고, http 유형은 링크를 통해 목록을 가져와 주기적으로 업데이트합니다, 예를 들어 팀의 공통 목록을 리포지토리에서 가져옵니다.
MATCH는 final의 유사한 기능을 합니다: 나머지는 직접 연결됩니다.
프로그램별 규칙에는 PROCESS-NAME이 있으며, Android에서는 애플리케이션의 패키지 이름을 받습니다.

도메인 목록을 수집하고 필요한 것을 놓치지 않는 방법

사이트는 하나의 도메인으로 구성되지 않습니다. 마켓플레이스는 CDN에서 이미지를 로드하고, 스크립트는 별도의 도메인에서 로드되며, 인증은 세 번째 도메인에서 이루어질 수 있습니다. 기본 도메인이 독일 IP를 통해 연결되고, 로그인 도메인이 실제 IP로 연결되면, 안티 프로드는 세션에서 두 개의 다른 주소를 감지합니다.

개발자 도구(F12 → 네트워크 탭)를 열고, 일반적인 시나리오를 진행하세요: 로그인, 검색, 제품 카드, 대시보드.
Domain 열에서 모든 도메인을 기록하세요. 외부 카운터와 광고는 추가할 필요가 없으며, 서비스 자체의 도메인( CDN 및 인증 서버 포함)은 반드시 포함해야 합니다.
이들을 규칙에 추가하고 시나리오를 반복하세요. sing-box의 로그(레벨 info) 또는 mihomo의 연결 탭에서 각 연결에 대해 어떤 규칙이 작동했는지 확인할 수 있습니다.
목록에 ipinfo.io와 같은 "검사" 도메인을 유지하세요: 이는 프록시의 IP를 보여주며, 목록에 포함되지 않은 인근 IP 검사 서비스는 실제 IP를 보여줍니다. 이렇게 하면 라우팅이 작동하는지 즉시 확인할 수 있습니다.

이 схем이 실패하는 함정

1. QUIC가 프록시를 우회합니다

Chrome 및 기타 브라우저는 HTTP/3, 즉 UDP를 통해 대형 사이트에 기꺼이 연결합니다. 많은 프록시 제공업체는 SOCKS5를 통해 UDP를 지원하지 않거나 제한적으로 지원합니다. 최악의 경우 연결이 잘못된 곳으로 나가고, 최상의 경우 사이트가 느려지며 브라우저가 TCP로 롤백할 때까지 기다려야 합니다. 따라서 sing-box의 구성에서는 작업 도메인에 대해 UDP 443을 명시적으로 거부합니다. mihomo에서는 브라우저에서 QUIC를 비활성화하여 유사한 효과를 쉽게 얻을 수 있습니다 (플래그 chrome://flags/#enable-quic).

2. DNS 유출이 제공업체로 이어집니다

작업 도메인이 인터넷 제공업체의 로컬 DNS를 통해 해결되면, 사이트는 이를 감지하지 못합니다: 연결은 여전히 프록시의 IP에서 발생합니다. 그러나 제공업체와 DNS를 보는 모든 사람은 사용자가 어떤 사이트를 열고 있는지 알 수 있습니다. mihomo의 fake-ip 모드와 sing-box에서 스니핑 후 도메인을 프록시 서버로 전달하는 것은 이 문제를 줄여줍니다. DNS 유출 방지 방법에 대한 자세한 내용은 DNS 유출 방지 방법 분석에서 확인하세요.

3. 다른 VPN 또는 안티 감지와의 충돌

두 개의 TUN 인터페이스가 동시에 존재하는 것은 라우팅에서 보장된 혼란을 초래합니다. 안티 감지 브라우저의 프로필에 이미 자신의 프록시가 있다면, 해당 트래픽은 TUN에서 제외하는 것이 좋습니다: 프로세스 이름에 대한 규칙을 사용하여 브라우저를 direct로 보내면 각 프로필이 자신의 프록시를 통해 연결됩니다.

4. 시스템 라우팅이 안티 감지를 대체하지 않습니다

컴퓨터의 모든 프로그램은 하나의 IP로 도메인에 연결됩니다. 하나의 상점에는 괜찮습니다. 그러나 한 플랫폼에 10개의 계정이 있을 경우 — 그렇지 않습니다: 플랫폼은 동일한 브라우저 지문과 하나의 주소를 감지합니다. 멀티 계정 관리를 위해 도메인 기반 라우팅은 보조 도구일 뿐, "별도의 프로필 + 별도의 프록시" 조합을 대체할 수는 없습니다.

5. 세션 중간에 IP가 변경됩니다

프록시가 각 요청 시 IP를 변경하도록 설정되어 있다면, 인증이 필요한 사이트는 각 이미지 로드 시 새로운 주소를 감지합니다. 대시보드, 상점 및 소셜 미디어의 경우, 고정 세션(작업 시간 동안 고정된 IP)으로 로그인하거나 수십 분 간격으로 타이머에 따라 IP를 변경하는 것이 좋습니다.

6. 필요한 프로토콜을 지원하지 않는 프록시

제공업체가 HTTP 프록시만 제공하는 경우, sing-box에서는 http 유형의 출구를 사용하고, mihomo에서는 type: http를 사용하세요. 두 엔진 모두 HTTP에 대한 로그인 및 비밀번호를 지원합니다. 프로그램이 인증이 있는 프록시와 함께 작동할 수 없다면, TUN을 올리고 싶지 않다면 gost, 3proxy 또는 Squid의 로컬 게이트웨이를 사용할 수 있습니다.

어떤 프록시를 규칙에 넣을지

마켓플레이스, 소셜 미디어, 판매자 대시보드, 광고 대시보드 — 필요한 국가의 거주자 프록시와 고정 세션. 자택 제공자의 주소는 안티 프로드에서 가장 적은 의문을 일으킵니다.
가장 엄격한 검사를 받는 플랫폼 (모바일 애플리케이션, TikTok, Instagram) — 모바일 프록시: 하나의 운영자 IP로 동시에 여러 실제 가입자가 네트워크에 연결됩니다.
API, 문서, 패키지 리포지토리, 안티 봇 보호가 없는 서비스 — 데이터 센터 프록시: 이들은 더 저렴하고 빠르며, 이러한 작업에는 "자택" IP가 필요하지 않습니다.

구성에서 여러 유형의 출구를 설정하고 도메인을 분산시키는 것이 편리하며, 가장 비싼 프록시를 통해 모든 것을 처리할 필요는 없습니다.

결론

도메인 기반 라우팅은 프록시를 "스위치"에서 정밀한 도구로 변모시킵니다: 필요한 사이트는 항상 필요한 IP로 열리고, 나머지 트래픽은 결제된 기가바이트를 소모하지 않습니다. 시작하려면 30줄의 구성만 있으면 됩니다. 가장 중요한 것은 스니핑(또는 fake-ip)을 잊지 않고, 프록시 도메인에 대해 QUIC를 비활성화하며, 서비스의 전체 도메인 목록을 수집하고 최신 구문을 사용하는 것입니다: 1.12 이전의 sing-box 구성은 최신 버전에서 실행되지 않습니다.