Mi servidor aparece offline: TCPShield, V4Guard y otros bloqueos
Hay un caso especialmente desconcertante para el dueño de un servidor: la comunidad juega con normalidad, pero una página de rankings lo muestra offline. Antes de culpar al comprobador, conviene mirar la ruta completa. Entre el jugador y el backend puede haber un proxy, un firewall, una protección anti-DDoS o un servicio como TCPShield o V4Guard.
La dirección que usan los jugadores no siempre es la del backend
Cuando se coloca una capa de protección delante del servidor, la dirección pública suele apuntar a esa capa. El backend real queda oculto y solo recibe tráfico reenviado. Es una arquitectura razonable: evita publicar la IP de origen y permite filtrar ataques, pero obliga a configurar bien todos los tipos de conexión.
El error aparece cuando la protección permite el tráfico normal del juego, pero no responde correctamente a un handshake de estado. El jugador puede entrar porque completa una conexión normal y la sonda puede fallar porque espera una respuesta rápida y concreta.
Cómo distinguir un bloqueo de una caída real
- Confirma que varios jugadores pueden entrar en ese mismo momento.
- Comprueba el dominio y el registro SRV, si lo utilizas.
- Prueba el estado desde una red externa, como el comprobador de 40servidoresMC.
- Revisa los logs del proxy y del firewall buscando conexiones rechazadas o timeouts.
- Compara la hora del fallo con cambios recientes en DNS, protección o reglas de acceso.
Si el dominio no resuelve o el proxy no acepta ninguna conexión, el problema es más amplio. Si solo falla una sonda concreta mientras los jugadores entran desde varias redes, el foco debe ponerse en la ruta de comprobación.
Qué revisar en TCPShield, V4Guard o un proxy parecido
Los nombres y paneles cambian, pero las comprobaciones importantes suelen ser las mismas: que el dominio apunte al endpoint correcto, que el puerto público sea el anunciado y que el servicio acepte el protocolo de estado de Minecraft. Revisa también si existe una lista de IP permitidas, un modo de protección estricto o una regla que bloquee proveedores de hosting.
Si el proveedor ofrece una guía para permitir sondas de monitorización, sigue esa guía y utiliza únicamente las direcciones oficiales que te indique. No abras el backend a todo Internet para arreglar un punto rojo: elimina una protección importante y puede ocultar el problema real.
DNS y SRV: el detalle que más se olvida
Un registro SRV permite que los jugadores escriban un dominio corto aunque el servicio escuche en otro host o puerto. Si el SRV sigue apuntando al proveedor anterior, unos clientes pueden resolver la dirección nueva y otros conservar la antigua. Comprueba el host objetivo, el puerto y el TTL antes de cambiar más cosas.
Después de un cambio, deja pasar el tiempo de propagación y vuelve a probar desde más de una red. Los resultados pueden variar durante unas horas si todavía hay resolvers con la respuesta anterior.
Qué información enviar al proveedor
Un buen ticket incluye el dominio público, el puerto, la edición Java o Bedrock, la hora del fallo, el mensaje exacto y una prueba de que los jugadores sí pueden conectarse. Añade si utilizas proxy, qué capa de protección está delante y desde qué servicio llega la comprobación.
Con esa información el proveedor puede buscar el rechazo en sus logs sin pedirte que desactives toda la seguridad. Cuando el estado vuelva a responder, mantén una prueba periódica y revisa cualquier cambio de IP o configuración antes de cerrar el caso.
