Durante las últimas semanas participamos en el análisis de un incidente que afectaba el acceso a un repositorio institucional basado en DSpace. Los usuarios reportaban intermitentemente el siguiente mensaje:
Error 522 – Connection Timed Out
Como suele ocurrir, la primera reacción fue asumir que el servidor presentaba problemas o que la aplicación había dejado de responder. Sin embargo, luego de una investigación más profunda, los resultados fueron muy distintos.
Este caso nos dejó varias enseñanzas que creemos pueden ser útiles para administradores de repositorios institucionales, equipos TI y organizaciones que publican sus servicios detrás de Cloudflare.
Uno de los errores más malinterpretados de Internet es el 522 Connection Timed Out.
Al pertenecer a la familia de códigos 5xx, muchas personas asumen inmediatamente que se trata de un problema del servidor de origen.
En realidad, el significado es bastante más específico.
Un Error 522 indica que Cloudflare no logró completar una conexión TCP/HTTPS con el servidor de origen dentro del tiempo máximo establecido por la plataforma.
Es importante destacar que esto no significa necesariamente que el servidor esté caído.
Tampoco significa que la aplicación (DSpace, Apache, Tomcat, Nginx, etc.) haya dejado de funcionar.
Simplemente indica que Cloudflare no consiguió comunicarse exitosamente con el origen antes de que expirara el tiempo de espera.
Cuando un usuario accede directamente a un servidor, la comunicación es relativamente sencilla.
Cuando se utiliza Cloudflare, aparece un intermediario adicional.
Por lo tanto, un Error 522 puede originarse en cualquiera de los componentes que participan entre Cloudflare y el servidor.
Cuando aparece un Error 522 es frecuente revisar inmediatamente:
Todo eso es correcto.
Pero muchas veces el problema no está allí.
En nuestro caso, ninguno de esos componentes mostraba errores.
La primera validación consistió en acceder directamente al servidor, evitando completamente Cloudflare.
La respuesta fue inmediata.
HTTP 200 OK
Tiempo de respuesta promedio:
≈ 60 milisegundos
Esto ya entregaba una pista importante.
El servidor estaba completamente operativo.
Luego realizamos una comparación permanente entre ambas formas de acceso.
Acceso mediante Cloudflare
HTTP 522
≈20 segundos
Acceso directo al servidor
HTTP 200
≈0.06 segundos
En varias oportunidades se obtuvo exactamente el siguiente comportamiento:
Cloudflare = HTTP 522 (20 segundos)
Servidor directo = HTTP 200 (0.06 segundos)
Desde el punto de vista técnico esta evidencia es muy fuerte.
Mientras Cloudflare informaba que no podía conectarse al servidor, el propio servidor seguía respondiendo normalmente.
Para descartar problemas locales se verificó:
Todas las pruebas resultaron satisfactoras.
Se ejecutó continuamente el siguiente procedimiento:
Consultar el repositorio mediante Cloudflare.
Consultar inmediatamente el mismo recurso directamente contra la IP del servidor.
Los resultados fueron muy ilustrativos.
Cloudflare
HTTP 522
20 segundos
Mientras tanto...
Servidor
HTTP 200
64 milisegundos
Esto demuestra que el origen nunca dejó de responder.
Una vez descartado el servidor, la investigación cambió completamente de enfoque.
Las posibilidades restantes eran:
Es decir, componentes que normalmente no aparecen cuando se revisan únicamente los logs del servidor.
Muchas organizaciones publican un sitio web sin saber realmente cuántas capas existen entre Internet y el servidor.
Por ejemplo:
Usuario > Cloudflare > Firewall institucional > Balanceador > WAF > Proveedor de Hosting > Servidor Linux > Nginx > Tomcat > DSpace
Cada una de estas capas puede aceptar, modificar, retrasar o incluso bloquear una conexión.
Por eso resulta tan importante comprender el recorrido completo de una solicitud.
Otro aprendizaje importante es que los códigos 5xx no representan un único tipo de problema.
Por ejemplo:
Aunque todos pertenecen a la familia 5xx, sus causas y responsables pueden ser completamente diferentes.
Nuestra experiencia nos permitió elaborar una pequeña lista de buenas prácticas.
Verifique primero si el servidor responde mediante acceso directo.
Muchas veces el problema está antes de llegar al origen.
Realice pruebas simultáneas:
Si ambas entregan resultados distintos, probablemente el problema no está en la aplicación.
No basta con revisar DSpace.
También deben considerarse:
Los registros, tiempos de respuesta y pruebas reproducibles son mucho más útiles que las suposiciones.
Una buena evidencia permite que distintos equipos (biblioteca, TI, proveedor de hosting y Cloudflare) trabajen sobre los mismos antecedentes.
En plataformas modernas es habitual que participen varios actores:
Resolver este tipo de incidentes requiere compartir información y realizar pruebas coordinadas.
Los errores de conectividad rara vez se resuelven únicamente observando la aplicación.
En este caso, la evidencia permitió demostrar que DSpace, Nginx y el servidor continuaban funcionando correctamente incluso cuando Cloudflare reportaba un Error 522.
Más allá de la solución específica del incidente, la principal enseñanza es metodológica: antes de atribuir una falla al servidor o a la aplicación, es fundamental analizar todo el recorrido de la comunicación y respaldar cada conclusión con pruebas objetivas.
En INFODI creemos que un buen diagnóstico no consiste en encontrar rápidamente un culpable, sino en comprender cómo interactúan todos los componentes que hacen posible un servicio digital. Esa mirada integral es la que permite resolver problemas complejos de manera eficiente y entregar información útil para todos los equipos involucrados.