# "IP fantasma: un backup en data/admin/ips/ deja nginx y Apache sin arrancar"

- **Ámbito:** DirectAdmin (cualquier versión), nginx y/o Apache
- **Autor:** Abdelkarim Mateos
- **Actualizado:** 2026-07-17
- **Gravedad:** alta — el servidor deja de servir TODA la web

## El síntoma

Ni nginx ni Apache arrancan. En el journal:

```text
nginx: [emerg] host not found in "192.0.2.10.bak.20260709" of the "listen" directive
       in /etc/nginx/nginx-vhosts.conf:3

```

```text
AH00526: Syntax error on line 31 of /etc/httpd/conf/extra/httpd-vhosts.conf:
       <VirtualHost> directive missing closing '>'

```

Fíjate en el nombre: `192.0.2.10.bak.20260709`. DirectAdmin está intentando escuchar en una «IP» que en realidad es **el nombre de un fichero de backup**.

Si el monitor de servicios de DirectAdmin está activo, reintentará arrancarlos periódicamente y **enviará un aviso por cada intento fallido**. Eso llega al buzón como «nginx se cae cada hora» y hace pensar en una intermitencia — pero **no es intermitente: es una caída continua**. Cada correo es un reintento, no una caída nueva.

## El mecanismo

**DirectAdmin enumera el directorio `/usr/local/directadmin/data/admin/ips/` tratando CADA NOMBRE DE FICHERO como una entidad IP.** No lee un índice ni valida el formato: lo que hay en ese directorio *es* la lista de IPs del servidor.

Si dejas ahí un backup:

```bash
# /usr/local/directadmin/data/admin/ips/

192.0.2.10                  ← la IP legítima (diradmin:diradmin)

192.0.2.10.bak.20260709     ← un backup: DirectAdmin lo lee como OTRA IP

```

…al generar las configuraciones de nivel servidor concatena ambos «nombres de IP» en el token de la plantilla y produce esto:

```nginx
   server {
        listen       192.0.2.10.bak.20260709

192.0.2.10:80;

        server_name  hostname.ejemplo.com 192.0.2.10.bak.20260709

192.0.2.10;

                proxy_pass http://192.0.2.10.bak.20260709

192.0.2.10:8080;

```

y en Apache un `<VirtualHost>` partido en dos líneas — de ahí el «missing closing `>`».

## Por qué es traicionero: el daño es LATENTE

Este es el punto importante.

`data/admin/ips/` **solo se lee cuando se regeneran las configuraciones de nivel servidor**. Mientras nadie las regenere, el fichero de más convive ahí sin causar ningún daño: **días o semanas**.

La avería aparece cuando algo dispara esa regeneración:

- Una actualización de DirectAdmin.
- Un `./build update_versions`.
- Un `./build rewrite_confs`.
- Cualquier mantenimiento que toque el stack del panel.

**Consecuencia práctica: quien detona la mina no es quien la puso.** El cuadro típico es «hice un mantenimiento rutinario y el servidor se quedó sin web» — y la conclusión fácil («lo rompió la actualización») es falsa: la actualización solo reveló un fichero que llevaba semanas ahí. Si te pasa, **no cierres culpando al mantenimiento**: mira el directorio.

## Detección: cuesta un `ls`

Cualquier nombre en ese directorio que no sea una IPv4 o IPv6 válida es una mina armada:

```bash
ls -1 /usr/local/directadmin/data/admin/ips/ 2>/dev/null \

  | grep -vE '^([0-9]{1,3}\.){3}[0-9]{1,3}$|^[0-9a-fA-F:]+$'
```

- **Salida vacía:** limpio.
- **Cualquier línea:** mina armada — arréglalo **antes** de tocar el servidor.

Merece la pena incorporarlo al pre-flight de cualquier mantenimiento de paquetes o del panel, porque **es precisamente ese mantenimiento el que la detona**. Detectarla después es llegar tarde.

## Solución

```bash
# 1. Retirar el fichero FUERA del árbol de datos (mover, no borrar)
mkdir -p /root/da-stray-backups
mv /usr/local/directadmin/data/admin/ips/192.0.2.10.bak.20260709 /root/da-stray-backups/

# 2. Regenerar las confs de NIVEL SERVIDOR
cd /usr/local/directadmin/custombuild && ./build rewrite_confs

# 3. Verificar sintaxis y arrancar
nginx -t && httpd -t
systemctl start httpd nginx

```

Antes de retirarlo, comprueba que el backup no contiene nada que necesites: lo habitual es que solo difiera en `value=` (el contador de uso que DirectAdmin recalcula solo en el tally nocturno), es decir, que sea **basura sin valor**.

### Trampa: `rewrite_confs` no es lo mismo que la task queue

Este paso se falla a menudo:

- **`echo "action=rewrite&value=httpd" >> data/task.queue` + `dataskq` → NO basta.** Regenera únicamente los vhosts **de usuario** (`data/users/*/nginx.conf`). Tras ejecutarlo, `nginx-vhosts.conf` sigue roto y parece que el arreglo no ha funcionado.
- **Los ficheros de nivel servidor** (`nginx-vhosts.conf`, `httpd-vhosts.conf`) los genera **CustomBuild** → hace falta **`./build rewrite_confs`**.

Y no pierdas el tiempo editando `nginx-vhosts.conf` a mano: **es autogenerado**. Mientras la causa siga en la capa de datos, DirectAdmin lo reescribirá igual de roto en la siguiente pasada.

## Dónde SÍ y dónde NO

No todo backup dentro del árbol de DirectAdmin es una bomba. **Solo `data/admin/ips/` tiene la semántica «un fichero = una entidad»:**

| Directorio | Cómo lo lee DirectAdmin | Un `.bak` ahí es… |
|------------|-------------------------|-------------------|
| `data/admin/ips/` | **enumera por nombre de fichero** | **una bomba** — IP fantasma |
| `conf/` | por nombre exacto (`directadmin.conf`) | inerte (basura) |
| `data/admin/` | por nombre exacto (`cluster.conf`…) | inerte (basura) |
| `data/users/<user>/` | por nombre exacto (`user.conf`…) | inerte (basura) |

Dicho de otro modo: un backup en `conf/` es desorden; un backup en `data/admin/ips/` deja el servidor sin web.

## La regla

**Un backup NUNCA va dentro del árbol de datos del panel.** Va fuera: `/root/`, `/var/backups/`, donde quieras — pero fuera.

Es tentador hacer `cp fichero fichero.bak` en el propio directorio antes de editar algo: es el reflejo de toda la vida y en el 99% de los sitios es inofensivo. En `data/admin/ips/` te cuesta la web del servidor entero, y te la cuesta **semanas después**, cuando ya nadie relaciona una cosa con la otra.

```bash
# MAL — el backup se convierte en una IP fantasma
cp /usr/local/directadmin/data/admin/ips/192.0.2.10{,.bak}

# BIEN — el backup vive fuera del árbol
cp /usr/local/directadmin/data/admin/ips/192.0.2.10 /root/192.0.2.10.bak

```