Clash for Windows explicado a fondo: de la configuración inicial y las reglas a la prevención de fugas de DNS e IP

1. Estado del proyecto: CFW está descontinuado

Clash for Windows es un cliente gráfico para el núcleo proxy Clash. No proporciona servidores proxy y no es una red de anonimato ni un servicio VPN completo. El proyecto original se detuvo en noviembre de 2023; la última versión pública fue 0.20.39 y el repositorio original de GitHub ya no está disponible.

Los paquetes anunciados como «CFW 2026», «0.20.39.x» u «Opt build» no deben considerarse lanzamientos oficiales de Fndroid. El cliente heredado ya no recibe mantenimiento y el canal original no puede verificar réplicas aleatorias. Para una instalación nueva conviene un cliente basado en mihomo que siga manteniéndose. Esta guía sirve sobre todo a quienes ya usan CFW o mantienen una configuración existente.

Distingue entre el núcleo antiguo Clash/Premium de CFW, Clash.Meta, mihomo y las variantes de terceros. Sus campos de configuración no son totalmente compatibles, así que no pegues opciones nuevas como respect-rules, strict-route o pilas recientes en un perfil antiguo de CFW sin comprobar la compatibilidad.

2. Cuatro conceptos que no deben confundirse

La ruta real en CFW tiene cuatro capas: cómo llega la aplicación al núcleo, qué salida elige el núcleo, cómo se resuelve DNS y qué ocurre tras un fallo. Activar un interruptor no demuestra que las demás capas funcionen bien.

• System Proxy configura las aplicaciones compatibles para usar un punto local; algunos terminales, juegos, aplicaciones UDP y apps empaquetadas pueden ignorarlo.
• TUN captura más tráfico, pero el enrutamiento y las reglas siguen decidiendo si usa el proxy. Activarlo por sí solo no garantiza nada.
• Global solo trata el tráfico que ya llegó al núcleo y no captura aplicaciones que evitan Clash; además GLOBAL debe elegir un nodo real, no DIRECT.
• El tráfico web puede usar el nodo mientras DNS sigue yendo al ISP, al router, a otra interfaz o al DoH del navegador.

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

3. Límites de privacidad: qué puede y qué no puede ocultar CFW

Por eso, «prevención de fugas» significa reducir la exposición no deseada de red y dirección, no lograr anonimato absoluto. Si hace falta proteger la ubicación precisa, revisa también los ajustes de ubicación del sistema, los permisos del navegador y los datos de la cuenta, no solo cambies de nodo.

• Para el sitio de destino: cuando toda la solicitud usa el proxy, normalmente se ve la IP de salida del nodo y no la IP pública original de casa u oficina.
• Para el proveedor del proxy: normalmente ve la IP pública original porque recibe la conexión; CFW no puede ocultarla al proveedor.
• Para la red local o el ISP: pueden seguir viendo el punto proxy, la hora y los metadatos del tráfico; la visibilidad del contenido depende del protocolo y del cifrado.
• Para el proveedor DNS: DoH/DoT cifran el transporte, pero un resolvedor contactado directamente puede ver la IP de origen y los nombres consultados. El cifrado no es anonimato.
• Cuentas, cookies, idioma, zona horaria, huellas del navegador, permisos de ubicación y localización por Wi-Fi también pueden revelar identidad o ubicación.

4. Inicio rápido para principiantes

Un perfil remoto puede definir nodos, reglas DIRECT, DNS, MATCH final, TUN y Fake IP. Un perfil no confiable puede dirigir parte del tráfico directamente a propósito, así que su origen importa tanto como el proveedor de nodos. Haz copia de tus cambios antes de actualizar un perfil remoto.

• Importa una suscripción HTTPS confiable o un YAML local en Profiles. La URL suele contener un token de cuenta y no debe aparecer en capturas ni registros públicos.
• Selecciona el perfil y luego elige Rule y un nodo proxy real en Proxies.
• Activa General → System Proxy y comprueba la conexión y la IP de salida en el navegador.
• Instala Service Mode y activa TUN solo cuando necesites cubrir mejor escritorio, terminal o UDP.
• Mantén Allow LAN desactivado; las aplicaciones locales que usan 127.0.0.1 no necesitan acceso LAN.
• Start with Windows solo inicia CFW al arrancar; no valida el perfil, el nodo, DNS ni la prevención de fugas.

5. Elegir entre System Proxy y TUN

Para navegación normal con buena compatibilidad suele bastar System Proxy con Rule. Usa TUN cuando terminales, juegos, chats o programas que ignoran el proxy del sistema deban llegar a Clash. Activar ambos no crea «doble cifrado» y puede dificultar el diagnóstico.

• Instala el servicio en General → Service Mode → Manage y aprueba el aviso de Windows.
• Verifica Service Mode antes de activar TUN Mode; la documentación antigua solía usar gVisor por compatibilidad.
• No experimentes con TAP antiguo y TUN a la vez; restaura una configuración que funcione en lugar de desactivar todo el firewall de Windows.
• En Rule comprueba coincidencias DIRECT, el MATCH final y destinos públicos en la lista de omisión del proxy del sistema.
• Para una prueba controlada de salida única, usa temporalmente Global con un nodo real y luego decide si vuelves a Rule.

6. Ejemplo DNS/TUN en CFW antiguo y sus límites

Este ejemplo ilustra la sintaxis Mixin de CFW antiguo. Haz copia y fusiónalo con una copia de la configuración actual en lugar de reemplazar un perfil que funciona o pegarlo en mihomo actual. La prioridad de CFW es Mixin > ajustes de TUN Mode > Profile, así que no edites los mismos campos en tres lugares.

• Fake IP devuelve direcciones reservadas a las aplicaciones mientras el núcleo guarda las asignaciones de dominio; no es cifrado ni anonimato.
• Combina fake-ip-filter con la lista existente para LAN y servicios del sistema que necesitan direcciones reales.
• dns.ipv6: false solo suprime respuestas AAAA; no desactiva IPv6 en Windows.
• El valor dns-hijack mostrado es sintaxis de CFW antiguo y no es universal para todos los clientes.
• DoH/DoT cifran el transporte ascendente, pero no demuestran que CFW antiguo envíe DNS por el nodo. Si el resolvedor no debe ver la IP original, CFW antiguo no es una solución fiable por sí solo.

mixin:
  dns:
    enable: true
    enhanced-mode: fake-ip
    fake-ip-range: 198.18.0.1/16
    fake-ip-filter:
      - "*.lan"
      - "localhost"
      - "dns.msftncsi.com"
      - "www.msftncsi.com"
      - "www.msftconnecttest.com"
    nameserver:
      - "https://1.1.1.1/dns-query"
      - "tls://1.0.0.1:853"
    ipv6: false
  tun:
    enable: true
    stack: gvisor
    dns-hijack:
      - "198.18.0.2:53"
    auto-route: true
    auto-detect-interface: true

7. DoH del navegador, IPv6, WebRTC, QUIC y kill switch

• DNS seguro del navegador: considéralo desactivado solo tras verificar TUN y DNS hijacking, para que Clash resuelva los nombres de forma coherente. No desactives DoH antes de que funcione la captura DNS.
• IPv6: el interruptor de CFW no es un interruptor general del sistema operativo. 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. Captúrala por completo o restríngela deliberadamente y vuelve a probar.
• WebRTC: STUN puede evitar un proxy de aplicación convencional y exponer direcciones adicionales. En escenarios estrictos puede servir disable_non_proxied_udp en Chromium, pero puede degradar o romper llamadas de voz y vídeo.
• QUIC y HTTP/3 usan UDP. No supongas que un fallo siempre produce un retorno seguro a TCP; verifica la ruta o desactiva QUIC temporalmente con una política compatible del navegador.
• Kill switch: el interruptor TUN de CFW no es un mecanismo fail-closed verificado. Fallos, suspensión, cambios de red, actualizaciones del perfil y otras VPN pueden crear rutas no previstas.
• Un candidato .local por mDNS en un navegador moderno no prueba automáticamente una fuga de IP pública; concéntrate en IPv4/IPv6 públicas originales.

8. Ajustes de General y Proxies explicados

• Port: punto proxy mixto local; usa el valor realmente mostrado y no des por hecho 7890.
• Allow LAN: permite que otros dispositivos LAN usen el proxy local; mantenlo apagado en la base de privacidad.
• Log Level: Info basta para uso normal y Debug sirve para diagnosticar; oculta dominios, IP, rutas de procesos y datos de suscripción antes de compartir registros.
• IPv6: controla el comportamiento del núcleo, no toda la pila IPv6 del sistema operativo.
• Home Directory: contiene configuración, registros y caché; revísalo antes de compartirlo.
• GeoIP Database: alimenta reglas GEOIP; actualizarlo no actualiza nodos ni núcleo.
• UWP Loopback: elimina restricciones loopback para apps empaquetadas concretas; aplícalo solo a quienes lo necesiten.
• Service Mode: da soporte privilegiado para TUN; no es un servicio proxy.
• Mixin: inyecta campos compartidos en perfiles y sirve para conservar ajustes DNS personales.
• Tipos de grupo: select para elección manual, url-test para elección medida, fallback para conmutación y load-balance para repartir conexiones; baja latencia no equivale a más ancho de banda.

9. Perfiles, Mixin y sintaxis de reglas

Los perfiles contienen nodos, grupos y reglas. Las actualizaciones remotas pueden sobrescribir ediciones manuales, así que usa Mixin, Diff o una copia local para personalización duradera. El JavaScript de Mixin y los parsers son código activo y solo deben ejecutarse desde fuentes confiables.

• Las reglas se evalúan en orden y MATCH pertenece al final.
• Sustituye Proxy por el nombre exacto de un grupo proxy existente.
• PROCESS-NAME suele necesitar el nombre completo del proceso de Windows, incluido .exe.
• no-resolve solo evita resolución DNS adicional para comparar la regla; no es un interruptor de privacidad.
• REJECT bloquea una conexión en lugar de ocultar su dirección mediante proxy.

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - PROCESS-NAME,git.exe,Proxy
  - IP-CIDR,203.0.113.0/24,Proxy,no-resolve
  - MATCH,DIRECT

10. Logs, Connections y Settings para verificar

• Logs revela errores de carga de perfil, DNS, handshake de nodo e inicio de TUN.
• Connections muestra Process Path, la Rule coincidente y las Chains salientes; una cadena que termina en DIRECT evita el nodo.
• Los tipos de entrada distinguen HTTP, SOCKS5 y TUN; Network distingue TCP y UDP.
• Cierra conexiones antiguas tras cambiar nodos, modos o perfiles para que una TCP vieja no siga usando la salida anterior.
• Break When Proxy Change / Profile Change / Mode Change en Settings reduce la confusión por conexiones antiguas.
• Core Secret y un puerto de controlador aleatorio protegen la API local; no expongas una API sin autenticación en 0.0.0.0.

11. Hacer que CFW funcione con distintas aplicaciones

Chrome y Edge suelen seguir el proxy del sistema, pero revisa extensiones proxy, DoH del navegador, WebRTC y QUIC. Firefox puede usar ajustes del sistema o SOCKS v5 manual con DNS remoto. El IDE, sus plugins, los servidores de lenguaje y el terminal integrado pueden mantener ajustes proxy separados.

Para apps empaquetadas de Windows, prueba primero TUN y usa UWP Loopback solo en aplicaciones concretas que lo necesiten. Juegos, voz y emuladores suelen requerir TUN con UDP; que el lanzador funcione no demuestra que el juego use proxy. WSL, Docker y las máquinas virtuales tienen pilas de red separadas, y 127.0.0.1 dentro de un contenedor normalmente no es el punto CFW de Windows.

# Ajustes temporales para la sesión actual de PowerShell
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"

# curl con proxy HTTP explícito
curl.exe --proxy http://127.0.0.1:7890 https://example.com/

# SOCKS con resolución remota del nombre de host
curl.exe --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

# Quitar variables proxy de esta sesión
Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue

12. Lista de verificación y diagnóstico

• Prueba IPv4 e IPv6 por separado con dos servicios independientes de eco de IP; una ciudad de geolocalización imprecisa no demuestra por sí sola una fuga.
• En Connections verifica proceso, regla, cadena y entradas UDP; si no hay entrada, normalmente la aplicación evitó Clash.
• Ejecuta pruebas DNS estándar y extendidas y busca ISP, router o resolvedores locales inesperados; la IP de un resolvedor público no tiene que coincidir con la IP del nodo.
• En WebRTC busca direcciones públicas originales y no trates nombres .local por mDNS como prueba automática de fuga pública.
• Vuelve a probar tras cambiar nodos, actualizar perfiles, suspender, cambiar Wi‑Fi, reiniciar CFW y apagados inesperados de TUN.
• Si las aplicaciones recuperan Internet directo cuando CFW se detiene, la configuración no es fail-closed.
• Si TUN rompe la conectividad, revisa Service Mode, firewall, DNS, clientes VPN/TUN competidores y la pila; restaura una copia antes de desactivar todo el firewall.