왜 지금 “Gemini Mac + Clash 분기”가 자주 등장할까

2026년 들어 Google은 macOS용 Gemini 네이티브 클라이언트와 데스크톱에서 빠르게 띄우는 흐름을 강화했고, 업계 전반에서도 AI 데스크톱 앱 경쟁이 한층 뜨거워졌습니다. 새 클라이언트가 처음 깔리는 시기에는 로그인 리디렉션, 모델 호출 API, 웹 콘솔이 서로 다른 경로로 나가다가 한 축만 막히는 사례가 반복됩니다. 사용자 입장에서는 “Clash를 켰는데도 앱만 안 된다”로 느껴지지만, 실제로는 브라우저 세션과 앱 번들이 잡는 호스트 이름이 완전히 같지 않거나, 규칙 목록에 새 호스트가 아직 없는 경우가 많습니다.

이 글은 속도 벤치마크가 아니라 도메인·API 식별 → 전용 전략 그룹 → 규칙 순서에 초점을 맞춥니다. ChatGPT·Grok 등 브라우저 중심 AI 사이트만 모아 둔 분기 가이드는 AI 웹 전용 분기 글에 두고, 여기서는 Google Gemini macOS 앱과 Google AI Studio·Generative Language API가 실제로 자주 붙는 호스트 축을 분리해 설명합니다. 같은 “생성형 AI”라도 제품 표면이 다르면 규칙 설계도 달라집니다.

흔한 증상: “브라우저는 되는데 앱만” 멈춘다

정리하면 아래 패턴이 반복됩니다. 공통점은 한 단계에서만 멈춘다는 점입니다.

  • 로그인 스피너가 길게 돌고 계정 화면으로 넘어가지 않는다. accounts.google.com 또는 OAuth 관련 호스트가 기대와 다른 출구를 탄다.
  • 대화 입력은 되는데 생성 응답만 타임아웃된다. UI 자산은 직접 연결이나 CDN으로 받아오지만, 모델 추론 API만 다른 노드로 빠지거나 반대로 직결로 막힌다.
  • Google AI Studio에서 키를 만들거나 프로젝트를 저장할 때만 실패한다. 콘솔이 붙는 호스트가 앱과 다르다.
  • 시스템 프록시를 켜도 앱이 시스템 설정을 무시하고 자체 스택으로 나가며 Clash 로그에 잡히지 않는다. 이때는 TUN이나 앱별 프록시 정렬이 필요하다.

이런 증상을 “노드 하나만 바꾸면 된다”로 접근하면 재발하기 쉽습니다. 먼저 실제 SNI·도메인을 로그에서 모으고, 그 목록을 좁은 전략 그룹에 매핑하는 편이 유지보수에 유리합니다.

어떤 호스트를 한 묶음으로 볼까

Google 쪽 생성형 스택은 공개 문서와 실측 로그를 합치면 대략 아래 축으로 나눌 수 있습니다. 정확한 이름은 빌드·지역·기업 SSO에 따라 달라질 수 있으므로 항상 본인 환경의 연결 로그를 기준으로 삼으세요.

  • 소비자용 Gemini 웹·앱 표면: gemini.google.com 등 사용자가 채팅 UI를 여는 데 필요한 호스트
  • 개발자 콘솔·실험 UI: aistudio.google.com, ai.google.dev 문서·샘플이 붙는 경로 — 키 발급·모델 카탈로그·샌드박스가 여기로 모이는 경우가 많습니다
  • Generative Language API: generativelanguage.googleapis.com 및 관련 googleapis.com 하위 — 앱·SDK가 실제 토큰 스트리밍을 요청하는 축
  • 계정·OAuth·공통 Google API: accounts.google.com, oauth2.googleapis.com, www.googleapis.com 등 — 로그인 단계에서 빠지면 앱 전체가 “연결 중”처럼 보입니다

여기서 흔한 실수는 googleapis.com처럼 접미사가 매우 넓은 규칙을 한 번에 PROXY로 보내 다른 업무 API까지 끌고 가는 경우입니다. 반대로 너무 쪼개면 유지보수가 어려워지므로, 처음에는 Gemini·AI Studio·Generative Language 세 덩어리만 잡고 로그로 세분화하는 접근이 현실적입니다.

팁

macOS에서는 Little Snitch나 Clash 계열 로그의 Connections 화면으로 앱 프로세스별 호스트를 빠르게 모을 수 있습니다. “앱 이름이 Gemini인 행만” 필터링해 보면 브라우저 탭과 다른 호스트가 한눈에 드러납니다.

전략 그룹 설계: PROXY_GEMINI를 어떻게 채울까

실무에서는 proxy-groups에 Gemini·Google AI 전용 그룹을 하나 두고 이름을 PROXY_GEMINI처럼 고정합니다. 멤버는 단순히 핑이 가장 낮은 노드가 아니라 TLS 세션이 길게 유지되고 스트리밍 응답이 끊기지 않는 출구를 넣습니다. select로 수동 고정하면 출시 직후처럼 엔드포인트가 바뀔 때도 자동 전환에 휘둘리지 않아 체감이 안정적입니다.

로그인만 자주 실패한다면 PROXY_GOOGLE_ACCOUNT를 분리해 accounts.google.com 계열을 따로 묶는 패턴도 있습니다. 다만 그룹이 늘수록 규칙 순서 실수가 생기기 쉬우니, 처음에는 하나의 전용 그룹으로 시작하고 증상이 명확히 갈라질 때 단계적으로 나누는 것을 권합니다.

규칙 예시와 순서

Clash·mihomo의 rules는 위에서 아래로 평가되며 처음 매칭이 최종입니다. Gemini 관련 줄은 GEOIP,CN,DIRECT나 넓은 MATCH보다 위에 두되, 직장망·사내 도메인을 깨지 않도록 검증된 RULE-SET + 소량의 DOMAIN-SUFFIX를 병행하는 편이 안전합니다. 아래는 개념 스케치이며 실제 프로필의 provider 이름·경로에 맞게 바꿔야 합니다.

# Conceptual excerpt — adapt names to your profile
proxy-groups:
  - name: PROXY_GEMINI
    type: select
    proxies:
      - NODE_GEMINI_1
      - NODE_GEMINI_2
      - PROXY_DEFAULT

rules:
  - DOMAIN-SUFFIX,gemini.google.com,PROXY_GEMINI
  - DOMAIN-SUFFIX,aistudio.google.com,PROXY_GEMINI
  - DOMAIN-SUFFIX,ai.google.dev,PROXY_GEMINI
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,PROXY_GEMINI
  - DOMAIN-SUFFIX,accounts.google.com,PROXY_GEMINI
  - DOMAIN-SUFFIX,googleapis.com,PROXY_GEMINI
  - GEOIP,CN,DIRECT
  - MATCH,PROXY_DEFAULT

googleapis.com 한 줄은 범위가 매우 넓어 Google Drive API 같은 다른 업무 트래픽까지 끌고 올 수 있습니다. 운영 환경에서는 커뮤니티 RULE-SET에서 Gemini 관련 서브도메인만 추출하거나, 로그에 실제로 찍힌 호스트를 DOMAIN 규칙으로 좁히는 편이 낫습니다. YAML 전체 구조·DNS 모드 충돌은 YAML 심층 가이드와 함께 보면 프로필 전체와 어긋남이 줄어듭니다.

주의

서비스 약관·지역 정책·고용·보안 규정을 위반하는 우회를 돕는 내용은 다루지 않습니다. 이 글은 합법적으로 사용 권한이 있는 네트워크에서 기술적 경로 불일치로 인한 끊김을 줄이는 설정에 한합니다.

macOS에서 시스템 프록시·TUN·DNS를 한 축으로

네이티브 앱은 브라우저와 달리 시스템 프록시를 따르지 않는 경우가 섞여 있습니다. Safari에서는 Gemini 웹이 잘 되는데 앱만 실패하면, 우선 Clash 로그에 앱 트래픽이 잡히는지 확인하세요. 잡히지 않으면 TUN 모드로 시스템 레벨에서 코어로 흘려보내거나, 사용 중인 Clash GUI가 제공하는 앱별 라우팅 옵션을 검토합니다. 메뉴바 아이콘만 켜두고 코어가 실제로 해당 프로필을 로드했는지도 함께 확인합니다.

DNS는 enhanced-mode: fake-ip를 쓰면 로컬 스텁 응답과 터널 내부 질의가 어긋나는 문제를 완화하기 쉬운데, OAuth 리디렉션이 특정 IP 대역을 가정하는 경우 fake-ip-filter 예외가 필요할 수 있습니다. IPv6가 활성화되어 있으면 AAAA만 타고 나가며 규칙이 기대와 다르게 보이는 사례도 있으니, 재현 시에는 한 번에 한 변수만 바꿔 좁히는 것이 안전합니다. Verge 계열 GUI를 쓰는 경우 최신 코어 조합은 Windows·macOS Verge 가이드에서 확인할 수 있습니다.

점검 순서 체크리스트

프로필을 크게 뒤집기 전에 아래 순서를 권합니다.

  1. 실제 로드된 프로필이 rule 모드인지, 메뉴바 앱과 코어 버전이 맞는지 확인한다.
  2. Gemini 앱을 켠 채 Clash 로그에서 도메인·SNI를 수집하고, 해당 줄이 DIRECT나 넓은 MATCH보다 위에 있는지 본다.
  3. PROXY_GEMINI가 가리키는 노드가 의도한 지역·ASN인지, 자동 전환 그룹이 과도하게 바뀌지 않는지 본다.
  4. DNS가 Fake-IP인지, 로그인 리디렉션 호스트가 fake-ip-filter 예외를 빠뜨리지 않았는지 본다.
  5. 다른 VPN·회사 ZTNA와의 중복을 제거하고, IPv6 변수를 분리한다.
  6. 증상을 로그인만, 생성만, AI Studio만으로 나누어 재현한다.

이 순서는 신규 클라이언트가 호스트를 추가해도 로그 기반으로 목록을 갱신하기 쉽게 해 줍니다. 출시 직후에는 커뮤니티 RULE-SET이 늦을 수 있으니, 개인용 rule-providers에 로컬 보정 파일을 얹는 패턴이 잘 맞습니다.

ChatGPT·Grok 중심 “AI 웹 분기”와 무엇이 다른가

기존의 AI 웹사이트 분기 글은 주로 브라우저 탭이 여는 채팅 도메인과 공개된 API 엔드포인트를 기준으로 합니다. Gemini macOS 앱은 번들된 클라이언트가 Google 계정 OAuth와 Generative Language API를 한 세션에 엮어 쓰는 경우가 많아, 계정 호스트와 모델 API를 같은 전략 그룹에 두지 않으면 “로그인만 되고 생성만 안 된다”는 부분 실패가 나옵니다. 또 Google AI Studio는 웹 콘솔이지만 키 발급·쿼터 페이지가 추가 호스트를 밟을 수 있어, 단순히 openai.com류의 목록에 넣어두는 것과는 다른 유지보수 리듬이 필요합니다.

정리하면 제품 축을 “브라우저형 채팅”이 아니라 “Google 계정 + Gemini 앱 + AI Studio + googleapis 추론 API”로 잡는 것이 이 글의 초점입니다. 같은 Clash라도 규칙을 이렇게 쪼개 두면 이후에 다른 Google AI 실험 기능이 붙어도 같은 그룹으로 흡수하기 쉽습니다.

정리

macOS용 Gemini 클라이언트가 처음 깔리는 시기에는 호스트 맵이 빠르게 변하고 사용자 규칙 세트가 따라가지 못해 “앱만” 문제가 표면화됩니다. 브라우저 세션과 동일한 한 줄짜리 AI RULE-SET에만 의존하기보다, Gemini 표면·AI Studio·Generative Language·계정 OAuth를 한 전략 그룹에 묶되 범위는 로그로 좁혀 가는 방식이 장기적으로 안정적입니다.

Clash·mihomo는 YAML 한 장으로 이런 분기를 명시적으로 유지할 수 있어, 문제가 생겼을 때도 원인 후보를 빠르게 좁힐 수 있습니다. 최신 클라이언트와 호환되는 코어 조합은 다운로드 페이지에서 확인할 수 있습니다. → Clash를 무료로 내려받아 프로필을 정리한 뒤, PROXY_GEMINI 전용 그룹과 규칙 순서부터 차근차근 맞춰 보시기 바랍니다.