Solucion Problemas

Síntoma	Causa probable	Qué revisar
El dominio queda en Pending para siempre	No hay worker de cola corriendo	Confirmar que `php artisan queue:work` está activo (supervisor/systemd)
"The node hosting this server does not have the domain proxy feature enabled"	Falta `NodeProxySetting` para ese nodo, o está `enabled=false`	Admin → Nodes → (nodo) → Proxy → tildar Enabled
"Server, node, or allocation not found"	El servidor no tiene una allocation asignada	Admin → Servers → (server) → Network → asignar allocation
"Could not connect to Wings on node [...]"	Wings caído, binario sin el addon, firewall bloqueando el puerto del daemon	`curl` al endpoint `/api/proxy/health` desde el panel hacia el nodo (ver Instalación Wings)
Error de nginx (`nginx config test failed`)	Puerto ya en uso por otro vhost, sintaxis rota en un `.conf` editado a mano	Ejecutar `nginx -t` directamente en el nodo y leer el detalle del error
Let's Encrypt falla (`certbot failed for ...`)	Puerto 80 cerrado, DNS todavía no resuelve al nodo, rate limit de Let's Encrypt alcanzado	`dig <dominio>` debe apuntar a la IP del nodo; confirmar puerto 80 abierto; revisar límites de Let's Encrypt en https://letsencrypt.org/docs/rate-limits/
"The domain 'x' is already in use on this panel" al recrear un dominio que se acaba de borrar	Falta la migración `2026_05_29_000001_fix_server_domains_unique_index.php`, o el panel corre una versión vieja de `DomainService`/`RevokeDomainProxy` que hacía soft-delete	Confirmar que la migración corrió (`php artisan migrate:status`) y que `DomainService::delete()` hace un hard delete
Cloudflare en modo "Full" o "Full Strict" da error de SSL en el origen	`manager.go` desactualizado, sin el bloque de certificado autofirmado para `cf_proxied`	Verificar que `wings/new-files/proxy/manager.go` es la versión incluida en este paquete (genera cert autofirmado + listener 443 automáticamente)
El panel muestra "Wings proxy module status" en rojo en Admin → Nodes → Proxy	El health check `GET /api/proxy/health` no responde	Confirmar que Wings tiene el binario compilado con este addon y que está corriendo (`systemctl status wings`)
El usuario no ve la pestaña "Proxy" en su servidor	Le faltan los 3 permisos `domain.*`, o no se recompiló el frontend	Revisar Permisos; confirmar que se corrió `yarn run build:production` después de instalar
Dominio queda en Active pero al visitarlo aparece otra cosa (otro sitio, error 444, página por defecto de nginx)	El nodo tiene otros `server{}` en el mismo puerto (por ejemplo el propio panel corriendo en el mismo servidor) y el directorio de configs de PawProxy nunca quedó incluido en el `nginx.conf` principal	Confirmar que el bloque `http {}` de `nginx.conf` tiene `include <domains_path>/*.conf;`, ver Instalación Wings, paso 4. Wings valida esto automáticamente después de cada `Apply()` (ver siguiente fila)
"nginx accepted and reloaded the config for [...], but it never actually loaded it"	Wings escribió el `.conf` y `nginx -t`/`nginx -s reload` no dieron error, pero el `server_name` del dominio nunca apareció en `nginx -T`. Casi siempre falta el `include` de arriba	Agregar el `include` faltante al `nginx.conf`, recargar nginx, y volver a intentar (borrar el dominio en estado `error` y crearlo de nuevo). Mejor todavía: usar el botón "Test configuration" en Admin → Nodes → (nodo) → Proxy antes de que cualquier cliente cree un dominio, así se detecta exactamente este problema sin necesidad de que nadie lo pise primero.
Dominio en modo None funciona por `http://` pero no carga (o Cloudflare devuelve `520`) por `https://`	El dominio tiene la nube naranja activada en Cloudflare, y None no abre ningún listener en 443 a propósito. Cloudflare (o el navegador, que por defecto intenta HTTPS primero) no tiene con quién hablar en el origen	Si el dominio va a estar proxied en Cloudflare, usar el modo Cloudflare en vez de None (agrega el listener 443 con cert autofirmado que Cloudflare necesita), o pasar el DNS de ese dominio a nube gris (DNS-only) si de verdad se quiere HTTP puro
Actualizaste un archivo `.php` del addon (por ejemplo tras un fix) y el comportamiento viejo sigue ahí; los cambios no parecen aplicarse a los jobs de dominio	`php artisan queue:work` (el proceso detrás de `pteroq`) carga las clases una sola vez al arrancar y las reutiliza para todos los jobs mientras siga corriendo. Subir un archivo nuevo no alcanza si el worker no se reinicia	`php artisan queue:restart` (le avisa al worker que termine el ciclo actual y se reinicie) o `systemctl restart pteroq` directamente. Esto no hace falta para cambios en controllers/rutas del lado web (esos sí se recargan solos), es específico de los Jobs que corren en la cola.

Dónde mirar los logs

Panel: storage/logs/laravel.log, ahí quedan las excepciones de los jobs (ApplyDomainProxy/RevokeDomainProxy) si algo revienta antes de llegar a Wings.
Cola: si usás php artisan queue:work con --verbose o supervisor, la salida estándar muestra cada intento y su resultado (recordá que los jobs reintentan 3 veces con backoff antes de marcar el dominio como error definitivo).
Wings: logs propios del daemon (journalctl -u wings -f o donde esté configurado). Ahí aparecen los errores de nginx -t, nginx -s reload y certbot con la salida completa del comando.
Estado del dominio: la columna error_message de la tabla server_domains (o el tooltip en DomainRow.tsx) siempre tiene el último error tal cual lo devolvió Wings.

Siguiente: Limitaciones conocidas →