Clash for macOS explicado a fondo: ClashX Meta para principiantes, TUN/DNS, prevención de fugas y ajustes de todas las apps

1. Qué significa realmente «Clash for macOS»

El nombre puede referirse al ClashX original, ClashX Pro con modo mejorado, ClashX Meta basado en mihomo, la compilación macOS descontinuada de Clash for Windows o forks independientes de la comunidad. Sus núcleos, menús y campos de configuración no son idénticos.

En la comprobación, el último lanzamiento de ClashX Meta de MetaCubeX era v1.4.46, publicado el 1 de octubre de 2026. El README del lanzamiento dice expresamente que el proyecto no tiene sitio web oficial. Descarga solo desde MetaCubeX/ClashX.Meta Releases y no confíes en sitios de descarga con el mismo nombre.

La rama master predeterminada puede contener código antiguo, mientras que los lanzamientos usan la rama meta y etiquetas de versión. Usa un lanzamiento en lugar de juzgar funciones por la rama predeterminada o compilar código viejo. Esta guía se centra en ClashX Meta v1.4.46; ClashX antiguo y CFW solo se distinguen cuando hace falta.

2. System Proxy, TUN, modos de enrutamiento y DNS son capas separadas

• System Proxy cubre solo aplicaciones que respetan los ajustes proxy de macOS; terminal, apps UDP, juegos, Docker, máquinas virtuales y servicios en segundo plano pueden ignorarlo.
• TUN captura más aplicaciones, pero el resultado depende de auto-route, reglas, UDP, IPv6, DNS y otras VPN o interfaces virtuales.
• Global solo trata el tráfico que llega al núcleo; no captura aplicaciones que evitan Clash.
• DoH es cifrado, no anonimato, y TUN es un mecanismo de captura, tampoco anonimato. El proveedor proxy aún puede ver la IP pública original.
• Cuentas, cookies, idioma, zona horaria, huellas del navegador, Servicios de localización de macOS y localización por Wi-Fi también pueden revelar identidad o ubicación.

Aplicación
   │
   │  1. System Proxy: la app se conecta a un puerto proxy local de Clash
   │  2. TUN: una interfaz utun captura tráfico de capa de red
   ▼
ClashX Meta / mihomo
   │
   │  3. Rule / Global / Direct: elige la salida
   │  4. DNS: decide cómo y dónde se resuelven los nombres
   ▼
DIRECT / nodo proxy / REJECT
   │
   ▼
Destino

3. Instalación e inicio rápido para principiantes

• Descarga el ZIP del lanzamiento solo desde MetaCubeX/ClashX.Meta Releases, extráelo y mueve la app a Applications. No desactives Gatekeeper globalmente ni quites el atributo de cuarentena a una app desconocida sin necesidad.
• Aprueba el ayudante privilegiado en el primer arranque solo tras verificar la fuente; gestiona el proxy del sistema, TUN y DNS.
• El directorio de configuración predeterminado es ~/.config/clash.meta/; ábrelo desde Config → Open config folder y haz copia antes de editar.
• Añade un perfil HTTPS confiable desde Config → Remote Config → Manage, o coloca un YAML local en el directorio de configuración y selecciónalo.
• Elige Rule y un nodo real, activa Set as system proxy, verifica en el navegador y solo entonces decide si necesitas TUN.
• Start at login solo inicia la app al entrar; no valida el nodo, el perfil ni DNS.

4. Ajustes de la barra de menús explicados

• Set as system proxy: escribe los ajustes HTTP/HTTPS/SOCKS en macOS. Wi‑Fi, Ethernet y otros servicios pueden necesitar comprobación separada, y otra VPN puede sobrescribirlos.
• TUN Mode: captura aplicaciones que ignoran el proxy del sistema. Una marca en el menú no demuestra enrutamiento sano; verifica DNS, Connections y la salida real.
• Outbound modes: Rule para división diaria, Global para pruebas controladas y Direct para evitar nodos proxy.
• Allow LAN: permite que otros dispositivos usen los puertos proxy del Mac. Mantenlo apagado; el uso local de 127.0.0.1 no lo necesita, sobre todo en Wi‑Fi público.
• Copy shell command: copia variables HTTP/HTTPS/SOCKS para shells compatibles y procesos hijos. La variante de IP externa también implica exposición LAN.
• Los perfiles remotos y las actualizaciones automáticas pueden sobrescribir ediciones manuales; guarda personalización duradera en una copia local.
• Lista de omisión del proxy: localhost, 127.0.0.1, rangos privados y *.local suelen pertenecer ahí. No añadas destinos públicos que deban usar proxy.
• La sincronización de configuración por iCloud puede incluir URLs de suscripción, credenciales de nodos y reglas; actívala solo si esos datos pueden llegar a tus otros dispositivos.
• La suspensión por SSID puede restaurar conexión directa en redes Wi‑Fi elegidas; es comodidad, no privacidad, así que revisa la lista.
• Dashboard y Connections muestran procesos, destinos, TCP/UDP, reglas y cadenas; cierra conexiones antiguas tras cambiar nodos.
• Sniffer recupera dominios de handshakes HTTP, TLS y QUIC para ayudar al enrutamiento; no es descifrado TLS completo ni anonimato.
• Fake IP y cachés gestionan asignaciones de dominio; limpia entradas antiguas tras cambios de DNS o TUN; Fake IP no es cifrado.
• GEO y Providers suministran GeoIP/GeoSite, nodos remotos y reglas; las fuentes deben ser confiables.
• Controlador remoto y API: mantenlos locales con secreto, no expongas una API sin autenticación ni entregues el secreto a un panel alojado no confiable.
• El núcleo Alpha es para pruebas; un usuario normal no debe ejecutar núcleos no verificados con privilegios elevados.

5. Elegir entre System Proxy y TUN

• Para navegación normal basta System Proxy con Rule y una lista de omisión auditada; TUN no es obligatorio.
• Para varias apps de escritorio, terminal o UDP, usa TUN y verifica explícitamente DNS, IPv6 y UDP.
• Activar System Proxy y TUN a la vez no crea doble cifrado y puede complicar el diagnóstico.
• Para una prueba controlada de salida única, usa Global temporalmente y confirma que GLOBAL elige un nodo real; luego vuelve al Rule adecuado.
• Cierra conexiones antiguas tras cambiar nodos o perfiles para que una TCP vieja no siga usando la salida anterior.
• Usa scutil --proxy para inspeccionar el proxy del sistema y networksetup -listallnetworkservices para listar servicios de red.

6. Por qué el TUN DNS de ClashX Meta se entiende mal fácilmente

El código del lanzamiento actual usa 8.8.8.8 como Meta TUN DNS predeterminado. El ayudante privilegiado aplica ajustes DNS al iniciar TUN, mientras dns-hijack de mihomo redirige solicitudes coincidentes al resolvedor interno. Por tanto, Meta TUN DNS no es necesariamente el resolvedor ascendente final.

La documentación de mihomo dice expresamente que macOS y Windows no pueden capturar automáticamente solicitudes DNS dirigidas a direcciones LAN. No cambies Meta TUN DNS a 192.168.1.1 u otra dirección de router sin pensarlo, porque podría evitar el resolvedor interno.

• Asegúrate de que dns-hijack cubre UDP y TCP en el puerto 53.
• Ver 8.8.8.8 en scutil --dns no demuestra ni fuga ni configuración segura; revisa nameserver interno y conexiones DNS reales.
• Tras detener TUN o un fallo, comprueba si los ajustes DNS originales se restauraron; si hace falta, restáuralos en Network → Details → DNS.
• Algunas actualizaciones pueden dejar el estado del menú inconsistente con el TUN/DNS real; apágalo y enciéndelo y prueba de verdad en lugar de confiar en la marca.

7. Ejemplo DNS/TUN para mihomo actual

Fusiona este fragmento en una copia del perfil existente. No reemplaces toda la suscripción ni lo copies a ClashX antiguo o CFW.

• respect-rules hace que las conexiones DNS sigan reglas de enrutamiento; si la propia dirección del resolvedor coincide con DIRECT, sus consultas pueden seguir directas.
• proxy-server-nameserver resuelve nombres de servidores proxy y evita dependencias circulares al arrancar; la resolución inicial aún puede necesitar un resolvedor directo accesible.
• Un nameserver puede elegir salida con #NombreDeGrupo, por ejemplo https://1.1.1.1/dns-query#Proxy, pero Proxy debe ser el nombre real del grupo.
• dns.ipv6: false solo suprime respuestas AAAA; no desactiva IPv6 en macOS.
• auto-redirect es principalmente para Linux; strict-route se documenta sobre todo para Windows/Linux y no es un interruptor universal de fugas en 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 del navegador, IPv6, WebRTC, QUIC y Private Relay

• El DoH gestionado por el navegador puede evitar el resolvedor interno y Fake IP. Considera desactivarlo solo tras verificar TUN y DNS hijacking, y vuelve a probar.
• El interruptor IPv6 no es un interruptor general de macOS. Si la red física tiene IPv6 público y el túnel solo cubre IPv4, los destinos IPv6 pueden ver la dirección original.
• WebRTC puede exponer direcciones adicionales mediante STUN. disable_non_proxied_udp de Chromium puede convenir en escenarios estrictos, pero puede perjudicar la comunicación en tiempo real.
• QUIC usa UDP; el nodo y TUN deben tener una ruta UDP definida. No supongas un retorno seguro a TCP.
• iCloud Private Relay cambia la ruta de Safari y parte del tráfico sin cifrar. Combinado con Clash, Safari puede mostrar una salida distinta de otras apps, así que prueba una ruta claramente definida cada vez.
• Los Servicios de localización de macOS pueden usar redes Wi‑Fi cercanas. Revisa permisos por app en System Settings → Privacy & Security → Location Services en lugar de mirar solo la IP del nodo.
• TUN no es automáticamente un kill switch. El firewall integrado de macOS gestiona sobre todo conexiones entrantes y no es un diseño fail-closed completo para tráfico saliente.

9. Configurar Terminal, Git, curl y SSH

Las aplicaciones de terminal no leen necesariamente el proxy del sistema de macOS. Define primero variables de entorno solo en la shell actual y escríbelas en ~/.zshrc solo tras confirmar puertos estables y arranque.

• El proxy HTTP(S) de Git no configura SSH automáticamente; usa TUN o ProxyCommand para SSH.
• Homebrew y herramientas de descarga suelen respetar variables proxy, pero configúralas y verifícalas en la misma sesión de terminal.
• La diferencia importante de socks5h es que el nombre de host puede resolverse a través del proxy en lugar de localmente.

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 a través del proxy HTTP
curl --proxy http://127.0.0.1:7890 https://example.com/

# SOCKS con resolución remota del nombre de host
curl --proxy socks5h://127.0.0.1:7890 https://example.com/

# Configurar y quitar el proxy HTTP(S) de Git
git config --global http.proxy http://127.0.0.1:7890
git config --global --unset http.proxy

# Limpiar variables proxy en la shell actual
unset http_proxy https_proxy all_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

# Ejemplo de SSH ProxyCommand solo para un host
Host example.com
    ProxyCommand nc -X 5 -x 127.0.0.1:7890 %h %p

10. Navegadores, IDE, Docker, máquinas virtuales y juegos

• Safari suele seguir el proxy del sistema, pero revisa también Private Relay, reglas DIRECT, permiso de ubicación y Connections.
• Chrome y Edge requieren revisar extensiones proxy, DNS seguro, WebRTC y QUIC; Firefox puede usar SOCKS v5 manual con DNS remoto.
• El IDE, plugins, servidores de lenguaje, gestores de paquetes y terminal integrado pueden tener ajustes de red separados; que uno funcione no demuestra que los demás funcionen.
• Dentro de un contenedor Docker, 127.0.0.1 suele referirse al propio contenedor. host.docker.internal puede llegar al host, pero usarlo con Clash puede requerir Allow LAN, binding y firewall; no expongas un proxy sin autenticación en Wi‑Fi público.
• Parallels, VMware y emuladores pueden usar NAT, puente o interfaces virtuales independientes. El TUN del host no garantiza captura en toda topología, así que verifica enrutamiento y DNS dentro de cada entorno.
• Juegos y voz en tiempo real suelen necesitar TUN con UDP, y el lanzador puede ser otro proceso. ping y traceroute no demuestran cobertura proxy porque ICMP difiere de TCP y UDP proxyficados.

11. Verificar eficacia y evasiones comunes

• Usa scutil --proxy para confirmar puntos HTTP/HTTPS/SOCKS y scutil --dns para inspeccionar resolvedores configurados.
• En Connections y registros verifica proceso, regla, cadena y entradas UDP; una cadena que termina en DIRECT evita el nodo.
• Prueba IPv4 e IPv6 por separado con dos servicios independientes; una ciudad de geolocalización incorrecta no demuestra por sí sola una fuga.
• Las pruebas DNS deben buscar ISP, router, resolvedores locales inesperados y DoH del navegador; la IP de un resolvedor público no tiene que coincidir con la IP del nodo.
• En WebRTC mira IPv4/IPv6 públicas originales; un candidato .local por mDNS no es automáticamente una fuga de IP pública.
• Vuelve a probar tras suspender, cambiar Wi‑Fi, cambiar nodo, actualizar perfil, reiniciar ClashX Meta y apagados inesperados de TUN.
• Si las apps recuperan Internet directo cuando Clash se detiene, la configuración no es fail-closed.

12. Diagnóstico y recomendaciones finales

• Safari funciona pero el terminal no: usa variables de entorno, proxy específico de la aplicación o TUN.
• System Proxy está activado pero aparece la IP original: revisa reglas DIRECT, omisiones, IPv6, otras VPN, Private Relay y conexiones antiguas.
• TUN rompe la conectividad: revisa ayudante, DNS del sistema, dns-hijack, DNS interno, VPN competidoras y pila TUN; restaura primero una configuración buena.
• TUN parece activado pero el terminal sigue directo: verifica el estado real, no solo el indicador del menú, luego alterna e inspecciona scutil --dns y registros.
• Fake IP rompe un servicio concreto: añade una entrada dirigida a fake-ip-filter en lugar de desactivar todo el módulo DNS.
• DNS sigue mal tras desactivar TUN: comprueba si se restauró la configuración original y corrígela en Network de Apple si hace falta.
• Las actualizaciones del perfil borran ediciones: guarda personalización duradera en una copia local y no edites el archivo gestionado remotamente.
• Para privacidad más alta, usa software mantenido, verifica DNS, WebRTC, Private Relay, ubicación e identificadores de cuenta; usa un diseño fail-closed verificado para tráfico saliente cuando haga falta.