1. Что на самом деле означает «Clash for macOS»

Под этим названием могут подразумеваться исходный ClashX, ClashX Pro с расширенным режимом, ClashX Meta на mihomo, прекращенная macOS-сборка Clash for Windows или независимые форки сообщества. Их ядра, меню и поля конфигурации не совпадают.

На момент проверки последний релиз ClashX Meta от MetaCubeX — v1.4.46 от 1 октября 2026 года. В README релиза прямо сказано, что у проекта нет официального сайта. Скачивайте только из MetaCubeX/ClashX.Meta Releases и не доверяйте одноименным сайтам загрузок.

Ветка master по умолчанию может содержать старый код, тогда как релизы используют ветку meta и теги версий. Используйте релиз, а не оценивайте возможности по ветке master и не собирайте старый код. Руководство сосредоточено на ClashX Meta v1.4.46; старый ClashX и CFW упоминаются только там, где это нужно.

2. System Proxy, TUN, режимы маршрутизации и DNS — отдельные слои

  • System Proxy охватывает только приложения, учитывающие настройки прокси macOS; терминал, UDP-приложения, игры, Docker, виртуальные машины и фоновые службы могут его игнорировать.
  • TUN перехватывает больше приложений, но результат зависит от auto-route, правил, UDP, IPv6, DNS и других VPN или виртуальных интерфейсов.
  • Global обрабатывает только трафик, попавший в ядро; он не перехватывает приложения, обходящие Clash.
  • DoH — шифрование, а не анонимность, а TUN — механизм перехвата, тоже не анонимность. Провайдер прокси по-прежнему может видеть исходный публичный IP.
  • Аккаунты, cookies, язык, часовой пояс, отпечатки браузера, службы геолокации macOS и определение местоположения по Wi-Fi также могут выдавать личность или местоположение.
Приложение
   │
   │  1. System Proxy: приложение подключается к локальному порту Clash
   │  2. TUN: интерфейс utun перехватывает трафик сетевого уровня
   ▼
ClashX Meta / mihomo
   │
   │  3. Rule / Global / Direct: выбор исходящего пути
   │  4. DNS: определяет, как и где разрешаются имена
   ▼
DIRECT / прокси-узел / REJECT
   │
   ▼
Назначение

3. Установка и быстрый старт для новичка

  • Скачивайте ZIP релиза только из MetaCubeX/ClashX.Meta Releases, распакуйте и переместите приложение в Applications. Не отключайте Gatekeeper глобально и не удаляйте атрибут карантина у неизвестного приложения без необходимости.
  • Разрешите привилегированный помощник при первом запуске только после проверки источника; он управляет системным прокси, TUN и DNS.
  • Каталог конфигурации по умолчанию — ~/.config/clash.meta/; откройте его через Config → Open config folder и сделайте резервную копию перед правкой.
  • Добавьте доверенный HTTPS-профиль через Config → Remote Config → Manage или поместите локальный YAML в каталог конфигурации и выберите его.
  • Выберите Rule и реальный узел, включите Set as system proxy, проверьте в браузере и только затем решайте, нужен ли TUN.
  • Start at login только запускает приложение при входе; он не проверяет узел, профиль или DNS.
  • Set as system proxy: записывает настройки HTTP/HTTPS/SOCKS в macOS. Wi-Fi, Ethernet и другие службы могут требовать отдельной проверки, а другой VPN может перезаписать их.
  • TUN Mode: перехватывает приложения, игнорирующие системный прокси. Галочка в меню не доказывает исправную маршрутизацию; проверяйте DNS, Connections и фактический выход.
  • Outbound modes: Rule для обычного разделения, Global для контролируемого теста и Direct для обхода прокси-узлов.
  • Allow LAN: позволяет другим устройствам использовать прокси-порты Mac. Держите выключенным; локальному использованию 127.0.0.1 это не нужно, особенно в общественном Wi-Fi.
  • Copy shell command: копирует переменные HTTP/HTTPS/SOCKS для совместимых оболочек и дочерних процессов. Вариант с внешним IP также связан с открытием LAN.
  • Удаленные профили и автообновления могут перезаписать ручные правки; храните долгосрочные настройки в локальной копии.
  • Список обхода прокси: localhost, 127.0.0.1, частные диапазоны и *.local обычно должны оставаться там. Не добавляйте публичные адреса, которым нужен прокси.
  • Синхронизация конфигурации через iCloud может включать URL подписки, учетные данные узлов и правила; включайте только если эти данные могут попадать на другие ваши устройства.
  • SSID suspend может восстановить прямое соединение на выбранных Wi-Fi; это удобство, а не функция приватности, поэтому проверьте список.
  • Dashboard и Connections показывают процессы, назначения, TCP/UDP, правила и цепочки; после смены узлов закрывайте старые соединения.
  • Sniffer восстанавливает домены из рукопожатий HTTP, TLS и QUIC для маршрутизации; это не полное расшифрование TLS и не анонимность.
  • Fake IP и кэши управляют соответствиями доменов; очищайте устаревшие записи после смены DNS или TUN; Fake IP не является шифрованием.
  • GEO и Providers поставляют GeoIP/GeoSite, удаленные узлы и правила; источники должны быть доверенными.
  • Remote controller и API: держите локально с секретом, не открывайте API без аутентификации и не передавайте секрет недоверенной веб-панели.
  • Ядро Alpha предназначено для тестирования; обычному пользователю не следует запускать непроверенное ядро с повышенными привилегиями.

5. Выбор между System Proxy и TUN

  • Для обычного просмотра достаточно System Proxy с Rule и проверенным списком обхода; TUN не обязателен.
  • Для нескольких десктопных приложений, терминала или UDP используйте TUN и отдельно проверяйте DNS, IPv6 и UDP.
  • Одновременное включение System Proxy и TUN не создает двойного шифрования и может усложнить диагностику.
  • Для контролируемого теста единого выхода временно используйте Global и убедитесь, что GLOBAL выбирает реальный узел; затем вернитесь к подходящему Rule.
  • После смены узла или профиля закрывайте старые соединения, чтобы старые TCP не продолжали использовать прежний выход.
  • Используйте scutil --proxy для проверки системного прокси и networksetup -listallnetworkservices для списка сетевых служб.

6. Почему TUN DNS в ClashX Meta легко понять неправильно

В исходном коде текущего релиза значением Meta TUN DNS по умолчанию является 8.8.8.8. При запуске TUN привилегированный помощник применяет настройки DNS, а dns-hijack в mihomo перенаправляет подходящие запросы во внутренний резолвер. Поэтому Meta TUN DNS не обязательно является конечным восходящим резолвером.

Документация mihomo прямо указывает, что macOS и Windows не могут автоматически перехватывать DNS-запросы, направленные на адреса LAN. Не меняйте Meta TUN DNS на 192.168.1.1 или другой адрес маршрутизатора, иначе можно обойти внутренний резолвер.

  • Убедитесь, что dns-hijack охватывает UDP и TCP на порту 53.
  • Присутствие 8.8.8.8 в scutil --dns не доказывает ни утечку, ни безопасную конфигурацию; проверяйте внутренний nameserver и фактические DNS-соединения.
  • После остановки или сбоя TUN проверьте, восстановились ли исходные настройки DNS; при необходимости восстановите их через Network → Details → DNS.
  • После некоторых обновлений состояние меню может не совпадать с фактическим TUN/DNS; выключите и включите TUN и проверьте реальным тестом, а не только галочкой.

7. Пример DNS/TUN для текущего mihomo

Объедините этот фрагмент с копией существующего профиля. Не заменяйте всю подписку и не копируйте его в старый ClashX или CFW.

  • respect-rules заставляет DNS-соединения следовать правилам маршрутизации; если сам адрес резолвера совпадает с DIRECT, запросы могут остаться прямыми.
  • proxy-server-nameserver разрешает имена прокси-серверов и предотвращает циклическую зависимость при запуске; начальное разрешение все равно может требовать прямо доступный резолвер.
  • nameserver может выбирать выход через #ИмяГруппы, например https://1.1.1.1/dns-query#Proxy, но Proxy должен быть реальным именем группы.
  • dns.ipv6: false лишь подавляет ответы AAAA; он не отключает IPv6 в macOS.
  • auto-redirect предназначен в основном для Linux; strict-route документирован главным образом для Windows/Linux и не является универсальным выключателем утечек на macOS.
dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  respect-rules: true
  proxy-server-nameserver:
    - "https://1.1.1.1/dns-query"
  nameserver:
    - "https://1.1.1.1/dns-query"
    - "https://8.8.8.8/dns-query"

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

8. DoH в браузере, IPv6, WebRTC, QUIC и Private Relay

  • Управляемый браузером DoH может обходить внутренний резолвер и Fake IP. Отключайте его только после проверки TUN и DNS hijacking, затем повторите тест.
  • Переключатель IPv6 не является общим выключателем macOS. Если в физической сети есть публичный IPv6, а туннель работает только с IPv4, назначения IPv6 могут видеть исходный адрес.
  • WebRTC может раскрывать дополнительные адреса через STUN. Для строгих сценариев подойдет disable_non_proxied_udp в Chromium, но это может ухудшить связь в реальном времени.
  • QUIC использует UDP; у узла и TUN должен быть определенный путь UDP. Не предполагайте безопасный возврат на TCP.
  • iCloud Private Relay меняет путь для Safari и части незашифрованного трафика. В сочетании с Clash Safari может показывать другой выход, чем остальные приложения, поэтому тестируйте один четко определенный путь за раз.
  • Службы геолокации macOS могут использовать ближайшие сети Wi-Fi. Проверяйте разрешения по приложениям в System Settings → Privacy & Security → Location Services, а не смотрите только на IP узла.
  • TUN автоматически не является kill switch. Встроенный брандмауэр macOS в основном управляет входящими соединениями и не является полноценной fail-closed схемой для исходящего трафика.

9. Настройка Terminal, Git, curl и SSH

Приложения терминала не обязательно читают системный прокси macOS. Сначала задайте переменные среды только в текущей оболочке и записывайте в ~/.zshrc только после проверки стабильных портов и запуска.

  • HTTP(S)-прокси Git автоматически не настраивает SSH; для SSH используйте TUN или ProxyCommand.
  • Homebrew и инструменты загрузки обычно учитывают переменные прокси, но задавайте и проверяйте их в той же сессии терминала.
  • Важное отличие socks5h в том, что имя хоста может разрешаться через прокси, а не локально.
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890

# curl через HTTP-прокси
curl --proxy http://127.0.0.1:7890 https://example.com/

# SOCKS с удаленным разрешением имени хоста
curl --proxy socks5h://127.0.0.1:7890 https://example.com/

# Настроить и удалить HTTP(S)-прокси Git
git config --global http.proxy http://127.0.0.1:7890
git config --global --unset http.proxy

# Очистить переменные прокси в текущей оболочке
unset http_proxy https_proxy all_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

# Пример SSH ProxyCommand только для одного хоста
Host example.com
    ProxyCommand nc -X 5 -x 127.0.0.1:7890 %h %p

10. Браузеры, IDE, Docker, виртуальные машины и игры

  • Safari обычно следует системному прокси, но также проверяйте Private Relay, правила DIRECT, разрешение на геолокацию и Connections.
  • Chrome и Edge требуют проверки прокси-расширений, безопасного DNS, WebRTC и QUIC; Firefox может использовать ручной SOCKS v5 с удаленным DNS.
  • IDE, плагины, языковые серверы, менеджеры пакетов и встроенный терминал могут иметь отдельные сетевые настройки; успех одного компонента не доказывает успех остальных.
  • Внутри контейнера Docker 127.0.0.1 обычно указывает на сам контейнер. host.docker.internal может достучаться до хоста, но использование с Clash может требовать Allow LAN, привязку и брандмауэр; не открывайте прокси без аутентификации в общественном Wi-Fi.
  • Parallels, VMware и эмуляторы могут использовать NAT, мост или отдельные виртуальные интерфейсы. TUN хоста не гарантирует перехват в любой топологии, поэтому проверяйте маршрутизацию и DNS внутри каждой среды.
  • Играм и голосовым приложениям реального времени часто нужны TUN и UDP, а лаунчер может быть отдельным процессом. ping и traceroute не доказывают покрытие прокси, потому что ICMP отличается от проксируемых TCP и UDP.

11. Проверка эффективности и типичные обходы

  • Используйте scutil --proxy для подтверждения точек HTTP/HTTPS/SOCKS и scutil --dns для проверки настроенных резолверов.
  • В Connections и журналах проверяйте процесс, правило, цепочку и записи UDP; цепочка, заканчивающаяся DIRECT, обходит узел.
  • Проверяйте IPv4 и IPv6 отдельно двумя независимыми сервисами; неверный город геолокации сам по себе не доказывает утечку.
  • Тесты DNS должны искать провайдера, маршрутизатор, неожиданные локальные резолверы и браузерный DoH; IP публичного резолвера не обязан совпадать с IP узла.
  • В WebRTC смотрите на исходные публичные IPv4/IPv6; кандидат .local через mDNS не является автоматической утечкой публичного IP.
  • Повторяйте тесты после сна, смены Wi-Fi, смены узла, обновления профиля, перезапуска ClashX Meta и неожиданного отключения TUN.
  • Если приложения снова получают прямой интернет после остановки Clash, конфигурация не является fail-closed.

12. Диагностика и итоговые рекомендации

  • Safari работает, а терминал нет: используйте переменные среды, прокси приложения или TUN.
  • System Proxy включен, но виден исходный IP: проверьте правила DIRECT, список обхода, IPv6, другие VPN, Private Relay и старые соединения.
  • TUN ломает связь: проверьте помощник, системный DNS, dns-hijack, внутренний DNS, конкурирующие VPN и стек TUN; сначала восстановите рабочую конфигурацию.
  • TUN выглядит включенным, но терминал идет напрямую: проверяйте фактическое состояние, а не только индикатор меню, затем переключите и посмотрите scutil --dns и журналы.
  • Fake IP ломает отдельную службу: добавьте точечную запись в fake-ip-filter вместо отключения всего модуля DNS.
  • После отключения TUN DNS остается неправильным: проверьте восстановление исходной конфигурации и при необходимости исправьте в настройках Network от Apple.
  • Обновления профиля стирают правки: храните долгосрочные настройки в локальной копии и не редактируйте удаленно управляемый файл.
  • Для повышенной приватности используйте поддерживаемое ПО, проверяйте DNS, WebRTC, Private Relay, геолокацию и идентификаторы аккаунта; при необходимости используйте проверенную схему fail-closed для исходящего трафика.