Saltar al contenido
Herramienta gratuita

Códigos de estado HTTP: lista y significado

Lista de códigos de estado HTTP con buscador: introduce 404, 403, 500, 502 o «redirección» y descubre qué significa cada código, cuál es su causa y cómo solucionarlo. 70 códigos del 100 al 526, con ejemplos de nginx y Apache que puedes copiar, los errores de Cloudflare del 520 al 526 y los códigos 444 y 499 de nginx. Gratis y sin registro: la búsqueda se realiza íntegramente en tu navegador.

Creado por Dimitri Heissler

¿Estás creando tu propio proyecto? Lleva tu sitio web a un hosting web rápido.

Ver alojamiento web

La búsqueda abarca el número, el nombre, la explicación, las causas y los ejemplos de configuración; por ejemplo, «timeout» o «client_max_body_size».

Búsquedas frecuentes:

70 de 70 códigos de estado

Significado

El servidor ha recibido las cabeceras de la solicitud y no tiene objeciones. El cliente puede enviar el cuerpo. Esto corresponde a la cabecera «Expect: 100-continue», con la que un cliente pregunta antes de subir un archivo grande si el servidor lo aceptará.

Véase también:
Definido en RFC 9110

Significado

El servidor cambia de protocolo a petición del cliente, por ejemplo, de HTTP a WebSocket. Para ello, el cliente ha enviado la cabecera «Upgrade».

Véase también:
Definido en RFC 9110

Significado

El servidor sigue procesando la solicitud y aún no ha terminado. Este código procede de WebDAV y evita que se agote el tiempo de espera en operaciones largas. Se considera obsoleto y apenas se utiliza.

Definido en RFC 2518

Significado

El servidor envía indicaciones por adelantado, como cabeceras «Link» para hojas de estilo o scripts, mientras prepara la respuesta principal. El navegador ya puede cargar esos archivos. Es una indicación, no un error.

Definido en RFC 8297

Significado

La solicitud se ha completado correctamente. Con GET, la respuesta contiene el recurso solicitado; con POST, el resultado de la acción. Es la respuesta normal de cualquier página que funciona.

Para la optimización en motores de búsqueda: Un 200 solo indica que el servidor responde, no que el contenido sea correcto. Una página de error entregada con un 200 se denomina «Soft 404» y confunde a los buscadores.
Véase también:
Definido en RFC 9110

Significado

La solicitud se ha completado correctamente y ha creado un nuevo recurso. Es habitual con POST en una API. El encabezado «Location» indica la dirección del nuevo recurso.

Véase también:
Definido en RFC 9110

Significado

El servidor ha aceptado la solicitud, pero aún no ha terminado de procesarla. Entregará el resultado más adelante, por ejemplo mediante una consulta de estado o un webhook. Es habitual en tareas en segundo plano.

Véase también:
Definido en RFC 9110

Significado

La solicitud se ha completado correctamente, pero los datos no proceden directamente del servidor de origen, sino de un proxy que podría haberlos modificado. Es poco frecuente.

Definido en RFC 9110

Significado

La solicitud se ha completado correctamente, pero la respuesta no incluye contenido deliberadamente. Es habitual con DELETE o PUT y con solicitudes CORS previas (OPTIONS). Si se quiere leer la respuesta como JSON, hay que controlar que esté vacía.

Véase también:
Definido en RFC 9110

Significado

La solicitud se ha completado correctamente. El cliente debe restablecer la vista, por ejemplo, vaciar un formulario. La respuesta no tiene contenido. Apenas se utiliza.

Definido en RFC 9110

Significado

El servidor solo entrega la parte solicitada de un archivo porque el cliente ha enviado una cabecera «Range». Se utiliza para el streaming de vídeo, las descargas pausadas y los archivos grandes.

Véase también:
Definido en RFC 9110

Significado

La respuesta contiene varios códigos de estado para varias operaciones parciales, en formato XML. Procede de WebDAV y aparece al sincronizar calendarios, contactos y archivos.

Definido en RFC 4918

Significado

Los miembros de una vinculación WebDAV ya se mostraron en una parte anterior de la misma respuesta y no se vuelven a enumerar. Es muy poco frecuente.

Definido en RFC 5842

Significado

El servidor ha respondido a la solicitud con codificación delta: la respuesta es el resultado de una o varias modificaciones de instancia sobre el recurso actual. No se utiliza en la práctica.

Definido en RFC 3229

Significado

Hay varias respuestas posibles para la solicitud, por ejemplo, el mismo archivo en distintos formatos o idiomas. El cliente o usuario debe elegir una. Apenas se utiliza en la práctica.

Véase también:
Definido en RFC 9110

Significado

Redirección permanente: el recurso tiene una nueva dirección, indicada en la cabecera «Location». Los navegadores y motores de búsqueda deberán usar únicamente la nueva URL en adelante.

Causas habituales

  • Migración de dominio o URL, por ejemplo, de http a https o de www al dominio principal
  • Se ha cambiado el nombre o la ubicación de una página
  • Se aplica una regla de redirección en nginx, Apache o el CMS

Cómo lo solucionas

  • Enlaza directamente a la URL de destino para evitar la redirección.
  • Reduce las cadenas de redirecciones (A, B, C) a un solo paso.
  • Si se produce un bucle (ERR_TOO_MANY_REDIRECTS), comprueba si las reglas de http/https y www se contradicen; a menudo hay conflictos entre el servidor y el CMS.
  • Los navegadores conservan las redirecciones 301 durante mucho tiempo. Prueba los cambios en una ventana de incógnito o con curl -I.

Configuración y comandos (ejemplos)

nginx
return 301 https://example.com$request_uri;
Apache
Redirect 301 /alte-seite https://example.com/neue-seite
Para la optimización en motores de búsqueda: Un 301 transfiere las señales de posicionamiento de la URL antigua a la nueva. Úsalo para cualquier traslado permanente y evita las cadenas de redirecciones.
Véase también:
Definido en RFC 9110

Significado

Redirección temporal: el recurso está disponible provisionalmente en otra dirección. El cliente debe seguir el encabezado «Location» para esta solicitud, pero seguir usando la URL original en el futuro. Algunos clientes convierten un POST en un GET.

Causas habituales

  • Redirección temporal, por ejemplo, para una campaña o por mantenimiento
  • Redirección del inicio de sesión a una página de acceso
  • Redirección por idioma o país
  • Configurado por error, aunque el traslado es permanente

Cómo lo solucionas

  • Indica los traslados permanentes con 301 o 308; de lo contrario, los buscadores conservarán la URL antigua.
  • Si quieres conservar el método, usa 307 (temporal) o 308 (permanente).

Configuración y comandos (ejemplos)

nginx
return 302 https://example.com/sommer-angebot;
Apache
Redirect 302 /angebot https://example.com/sommer-angebot
Para la optimización en motores de búsqueda: Con un 302, la URL antigua permanece en el índice mientras la redirección se considere temporal. Si lo utilizas para un traslado permanente, las posiciones en los resultados de búsqueda se transfieren lentamente.
Véase también:
Definido en RFC 9110

Significado

Redirección con GET: el cliente debe obtener el resultado en otra URL mediante GET. Es habitual después de un POST (Post/Redirect/Get) para evitar que, al recargar la página, se vuelva a enviar el formulario.

Véase también:
Definido en RFC 9110

Significado

El recurso no ha cambiado desde la última solicitud. El servidor no envía ningún cuerpo y el navegador utiliza la copia de la caché. Para ello, el navegador ha enviado «If-None-Match» (ETag) o «If-Modified-Since». Esto ahorra ancho de banda y acelera la carga de la página.

Véase también:
Definido en RFC 9110

Significado

Redirección temporal como la 302, pero el método HTTP y el cuerpo no cambian al seguirla: un POST sigue siendo un POST.

Causas habituales

  • Chrome muestra «307 Internal Redirect» en las herramientas de desarrollo para las redirecciones HSTS de http a https, aunque el servidor no haya enviado nada
  • Un servidor redirige temporalmente una solicitud de API y quiere conservar el método

Cómo lo solucionas

  • Si la redirección es permanente, usa 308 en lugar de 307.

Configuración y comandos (ejemplos)

nginx
return 307 https://example.com$request_uri;
Apache
Redirect 307 /alt https://example.com/neu
Véase también:
Definido en RFC 9110

Significado

Redirección permanente como 301, pero conserva el método HTTP y el cuerpo: un POST sigue siendo un POST. Adecuada para migraciones permanentes de API y formularios que no deben perder sus datos.

Configuración y comandos (ejemplos)

nginx
return 308 https://example.com$request_uri;
Apache
Redirect 308 /alt https://example.com/neu
Para la optimización en motores de búsqueda: Para los motores de búsqueda, 308 funciona como 301 y transfiere el posicionamiento a la nueva dirección.
Véase también:
Definido en RFC 9110

Significado

El servidor no entiende la solicitud porque está mal formada: sintaxis no válida, cabeceras dañadas o una cookie demasiado grande. Desde el punto de vista del servidor, el error está en el cliente.

Causas habituales

  • Caracteres no válidos o URL mal codificada, por ejemplo, un espacio o un % sin dos dígitos hexadecimales
  • Cookies demasiado grandes o dañadas; en nginx aparece como «Request Header Or Cookie Too Large»
  • Cuerpo JSON no válido o campos obligatorios ausentes en una API
  • Cabeceras Host o Content-Length incorrectas, a menudo debido a un proxy

Cómo lo solucionas

  • Elimina las cookies del dominio en el navegador y vuelve a cargar la página.
  • Comprueba la URL y codifica los caracteres especiales, por ejemplo, con URL Encoder.
  • Compara el cuerpo de la solicitud con la documentación de la API.
  • Si los encabezados son demasiado grandes, aumenta el tamaño de los búferes del servidor.

Configuración y comandos (ejemplos)

nginx
large_client_header_buffers 4 16k;
Véase también:
Definido en RFC 9110

Significado

La solicitud requiere una autenticación válida. El cliente no ha iniciado sesión o sus credenciales no son válidas. El servidor incluye el encabezado «WWW-Authenticate», que indica el método esperado. El nombre puede llevar a confusión: significa «no autenticado», no «sin permiso» (eso corresponde al 403).

Causas habituales

  • Token, contraseña o clave API ausente o caducada
  • Cabecera Authorization incorrecta; por ejemplo, falta «Bearer» antes del token
  • Protección HTTP Basic (.htpasswd) para la página o el directorio

Cómo lo solucionas

  • Comprueba las credenciales y la fecha de caducidad del token.
  • Comprueba el formato del encabezado Authorization.
  • Con Basic Auth: comprueba el usuario en .htpasswd y la ruta del archivo en la configuración.

Configuración y comandos (ejemplos)

nginx
auth_basic "Geschützter Bereich";
auth_basic_user_file /etc/nginx/.htpasswd;
Apache
AuthType Basic
AuthName "Geschützter Bereich"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
Véase también:
Definido en RFC 9110

Significado

Reservado para futuros sistemas de pago y nunca estandarizado. Aun así, algunos servicios lo usan, por ejemplo, cuando una suscripción ha caducado o hay que pagar una cuota de API.

Cómo lo solucionas

  • Comprueba con el proveedor el estado de la factura o la suscripción.
  • Consulta la documentación de la API del servicio; allí se define su significado.
Véase también:
Definido en RFC 9110

Significado

El servidor entiende la solicitud, pero la rechaza. A diferencia de 401, volver a iniciar sesión normalmente no ayuda: el acceso no está permitido para esta identidad o dirección.

Causas habituales

  • Los permisos o el propietario del archivo son incorrectos; el usuario del servidor web no puede leerlo
  • Falta un documento de índice en el directorio y el listado de directorios está desactivado
  • Bloqueo de IP, regla de firewall o WAF, o bloqueo geográfico
  • Una regla de .htaccess o de la configuración de nginx prohíbe el acceso (deny all, Require all denied)
  • Un módulo de seguridad como ModSecurity o Fail2ban bloquea la solicitud

Cómo lo solucionas

  • Comprueba los permisos: normalmente 755 para directorios y 644 para archivos, con el usuario del servidor web como propietario. La calculadora CHMOD convierte los valores.
  • Crea un archivo de índice (index.html, index.php) o configura la directiva index.
  • Consulta el registro de errores del servidor web: allí figura el motivo exacto, por ejemplo, «directory index of … is forbidden».
  • Comprueba los bloqueos de IP y las reglas del WAF.

Configuración y comandos (ejemplos)

Shell
namei -l /var/www/html/index.html
nginx
index index.html index.php;
Apache
<Directory /var/www/html>
    Require all granted
</Directory>
Véase también:
Definido en RFC 9110

Significado

Se puede acceder al servidor, pero no reconoce la dirección solicitada. No se ha encontrado el recurso. El servidor no indica si nunca existió o si solo falta por ahora.

Causas habituales

  • Error tipográfico o enlace obsoleto
  • Página eliminada, movida o renombrada sin redirección
  • Ruta de documentos incorrecta en el servidor web (root o alias), o uso incorrecto de mayúsculas y minúsculas, que Linux distingue
  • Faltan reglas de reescritura, por ejemplo, para los enlaces permanentes de WordPress o una aplicación de página única
  • El archivo no se subió durante el despliegue

Cómo lo solucionas

  • Comprueba la ruta y el nombre del archivo, incluidas las mayúsculas y minúsculas.
  • Configura try_files en nginx para que funcionen los enlaces permanentes y las aplicaciones de una sola página: try_files $uri $uri/ /index.php?$args; o /index.html.
  • Redirige las páginas trasladadas a la nueva dirección mediante una redirección 301.
  • Configura una página 404 propia con búsqueda y enlaces.

Configuración y comandos (ejemplos)

nginx
error_page 404 /404.html;
Apache
ErrorDocument 404 /404.html
Para la optimización en motores de búsqueda: Las páginas 404 aisladas no perjudican el posicionamiento. Lo importante son las páginas con enlaces entrantes o tráfico: redirígelas mediante 301. Evita las páginas de error que devuelven un código 200 («Soft 404»).
Véase también:
Definido en RFC 9110

Significado

El recurso existe, pero no admite este método HTTP (GET, POST, PUT, DELETE, etc.). La respuesta debe incluir una cabecera «Allow» con los métodos permitidos.

Causas habituales

  • POST a una ruta que solo admite GET, o viceversa
  • nginx responde con 405 a un POST dirigido a un archivo estático
  • Una redirección 301 o 302 ha convertido la solicitud POST en GET
  • El servidor web o el WAF bloquean métodos como PUT y DELETE

Cómo lo solucionas

  • Consulta la cabecera «Allow»; allí figuran los métodos permitidos.
  • Comprueba la ruta y el controlador en la aplicación.
  • Usa 307 o 308 en lugar de 301 o 302 si quieres conservar el método durante la redirección.
  • Accede directamente a la dirección https definitiva para evitar que una redirección cambie el método.
Véase también:
Definido en RFC 9110

Significado

El servidor no puede responder en ninguno de los formatos admitidos por el cliente mediante la cabecera «Accept», como el tipo de contenido, el idioma o la codificación de caracteres. Algunas Web Application Firewalls (ModSecurity) también bloquean solicitudes con este código.

Causas habituales

  • El encabezado Accept solicita, por ejemplo, solo application/xml, pero el servidor solo devuelve JSON
  • Una regla de ModSecurity ha considerado sospechosa la solicitud, algo frecuente con scripts sin User-Agent

Cómo lo solucionas

  • Ajusta el encabezado Accept u omítelo.
  • En ModSecurity, consulta el registro de auditoría y comprueba la regla que se ha activado.
Véase también:
Definido en RFC 9110

Significado

Como 401, pero es un servidor proxy, no el servidor de destino, el que exige la autenticación. Para ello, el proxy envía la cabecera «Proxy-Authenticate».

Causas habituales

  • Un proxy de empresa o centro educativo requiere iniciar sesión
  • Credenciales del proxy incorrectas en la configuración del sistema o en curl

Cómo lo solucionas

  • Introduce las credenciales del proxy, por ejemplo, en curl con -x benutzer:passwort@proxy:port.
  • Solicita las credenciales correctas al departamento de TI o al proveedor del proxy.
Véase también:
Definido en RFC 9110

Significado

El servidor ha esperado demasiado a recibir la solicitud completa del cliente y ha cerrado la conexión.

Causas habituales

  • Conexión lenta o inestable del cliente
  • Se interrumpe la carga de un archivo grande
  • Un proxy o balanceador de carga mantiene las conexiones abiertas demasiado poco tiempo
  • El navegador abrió una conexión por adelantado, pero nunca la utilizó.

Cómo lo solucionas

  • Comprueba la conexión y repite la solicitud.
  • Aumenta los tiempos de espera en el servidor.
  • Si los archivos son demasiado grandes para subirlos, redúcelos o súbelos por partes.

Configuración y comandos (ejemplos)

nginx
client_header_timeout 60s;
client_body_timeout 60s;
Apache
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
Véase también:
Definido en RFC 9110

Significado

La solicitud entra en conflicto con el estado actual del recurso, por ejemplo, por cambios simultáneos o porque ya existe una entrada. El cliente puede resolver el conflicto y volver a intentarlo.

Causas habituales

  • Ya existe un valor que debe ser único, como una dirección de correo electrónico, un nombre de usuario o un nombre de dominio
  • Dos usuarios modifican el mismo recurso; la versión ya no coincide
  • El recurso no se puede modificar ni eliminar en su estado actual

Cómo lo solucionas

  • Vuelve a cargar el estado actual y aplica de nuevo tu cambio.
  • Consulta el cuerpo de la respuesta: las buenas APIs detallan allí el conflicto.
Véase también:
Definido en RFC 9110

Significado

El recurso existió, pero se eliminó intencionadamente y no volverá. A diferencia de 404, el servidor indica que ha desaparecido de forma permanente.

Causas habituales

  • El contenido se eliminó deliberadamente, por ejemplo, una oferta caducada
  • Una regla del servidor devuelve 410 para las URL antiguas

Cómo lo solucionas

  • Si hay una página sucesora, redirige mediante 301.
  • Responde deliberadamente con 410 a las URL eliminadas que no volverán.

Configuración y comandos (ejemplos)

nginx
location = /alte-seite {
    return 410;
}
Apache
Redirect gone /alte-seite
Para la optimización en motores de búsqueda: Con 410, indicas claramente a los motores de búsqueda que la página se ha eliminado intencionadamente. Sin embargo, Google trata 404 y 410 de forma similar, por lo que la diferencia es pequeña.
Véase también:
Definido en RFC 9110

Significado

El servidor exige la cabecera «Content-Length», que falta en la solicitud. Solo acepta el cuerpo si conoce su longitud.

Causas habituales

  • Un cliente envía el cuerpo de la solicitud por partes (chunked) a un servidor que no lo acepta
  • Un script o proxy omite la cabecera

Cómo lo solucionas

  • Establece Content-Length o usa un cliente HTTP que envíe la cabecera automáticamente.
  • Comprueba la configuración del proxy para el almacenamiento en búfer de las solicitudes.
Véase también:
Definido en RFC 9110

Significado

No se cumple una condición del encabezado de la solicitud (If-Match, If-Unmodified-Since, etc.). Por eso, el servidor no aplica el cambio. Así se evita sobrescribir modificaciones.

Causas habituales

  • El recurso ha cambiado desde que el cliente cargó el ETag
  • ETag obsoleto en If-Match

Cómo lo solucionas

  • Vuelve a cargar el recurso, obtén el nuevo ETag y envía el cambio otra vez.
Véase también:
Definido en RFC 9110

Significado

El cuerpo de la solicitud supera el tamaño que acepta el servidor. Suele ocurrir al subir archivos. Antes, este código se llamaba «Payload Too Large» y, anteriormente, «Request Entity Too Large».

Causas habituales

  • nginx: client_max_body_size es de solo 1 MB de forma predeterminada
  • Apache: LimitRequestBody está configurado
  • PHP: upload_max_filesize o post_max_size son demasiado pequeños
  • Una CDN o un proxy situado delante limita el tamaño

Cómo lo solucionas

  • Aumenta el límite en la configuración y recarga el servidor (nginx -s reload).
  • Aumenta upload_max_filesize y post_max_size en php.ini. post_max_size debe ser al menos igual que upload_max_filesize.
  • Comprueba cada etapa de la cadena: CDN, proxy, servidor web y PHP. Se aplica el límite más bajo.

Configuración y comandos (ejemplos)

nginx
client_max_body_size 50M;
Apache
LimitRequestBody 52428800
Véase también:
Definido en RFC 9110

Significado

La URL es más larga de lo que puede procesar el servidor. Suele deberse a un error de la aplicación, no a una dirección real.

Causas habituales

  • Demasiados parámetros en una solicitud GET
  • Un bucle de redirección añade más parámetros en cada vuelta
  • Los grandes volúmenes de datos se transmiten por URL en lugar de POST

Cómo lo solucionas

  • Envía los datos grandes mediante POST.
  • Elimina el bucle de redirección.
  • Aumenta el límite del servidor si es necesario.

Configuración y comandos (ejemplos)

nginx
large_client_header_buffers 4 16k;
Apache
LimitRequestLine 16384
Véase también:
Definido en RFC 9110

Significado

El servidor no reconoce el formato del cuerpo enviado (cabecera «Content-Type»). Por ejemplo, solo procesa JSON, pero recibe datos de formulario.

Causas habituales

  • El encabezado Content-Type falta o es incorrecto; por ejemplo, application/json en lugar de text/plain.
  • El servidor espera multipart/form-data para las subidas.

Cómo lo solucionas

  • Establece el Content-Type adecuado para el cuerpo.
  • Consulta la documentación de la API.
Véase también:
Definido en RFC 9110

Significado

El rango solicitado (encabezado «Range») queda fuera del archivo. El servidor indica el tamaño real en «Content-Range».

Causas habituales

  • Se reanuda una descarga desde una posición determinada, pero el archivo ha reducido su tamaño o ha sido reemplazado
  • Un gestor de descargas defectuoso

Cómo lo solucionas

  • Elimina la descarga parcial y vuelve a empezar.
Véase también:
Definido en RFC 9110

Significado

El servidor no puede cumplir la expectativa indicada en la cabecera «Expect». Normalmente se trata de «100-continue», que el proxy o el servidor no admite.

Causas habituales

  • Un proxy antiguo o un servidor sin compatibilidad con Expect
  • curl envía automáticamente Expect: 100-continue en solicitudes POST grandes

Cómo lo solucionas

  • Desactiva el encabezado en curl con -H 'Expect:'.
  • Actualiza el proxy.

Configuración y comandos (ejemplos)

Shell
curl -H 'Expect:' -d @datei.json https://example.com/api
Véase también:
Definido en RFC 9110

Significado

Una broma del Día de los Inocentes incluida en RFC 2324 (Hyper Text Coffee Pot Control Protocol): una tetera se niega a preparar café. El código está reservado y, en la práctica, se usa como broma o para bloquear bots.

Definido en RFC 2324

Significado

La solicitud se envió a un servidor que no puede responder para esta combinación de esquema y host. Ocurre con HTTP/2 cuando un navegador reutiliza una conexión para varios nombres de host.

Causas habituales

  • Varios dominios en una IP con un certificado compartido, pero distinta configuración para cada host
  • SNI y la cabecera Host no coinciden

Cómo lo solucionas

  • Unifica los certificados y hosts virtuales de los dominios afectados.
  • Comprueba con curl --resolve qué host responde.
Véase también:
Definido en RFC 9110

Significado

El servidor entiende la solicitud y el formato es correcto, pero el contenido no es válido, por ejemplo porque falta un campo obligatorio o un valor está fuera del intervalo permitido. Antes, este código se llamaba «Unprocessable Entity». Muchos frameworks lo utilizan para errores de validación.

Causas habituales

  • La validación falla, por ejemplo, por el formato del correo electrónico, la longitud o un campo obligatorio
  • Un error lógico, como una fecha de finalización anterior a la fecha de inicio

Cómo lo solucionas

  • Consulta el cuerpo de la respuesta: allí figuran los campos y los mensajes de error.
  • Comprueba los datos introducidos con la documentación de la API.
Véase también:
Definido en RFC 9110

Significado

El recurso está bloqueado, por ejemplo, porque alguien lo ha reservado en WebDAV para editarlo.

Cómo lo solucionas

  • Quita el bloqueo (UNLOCK) o espera a que termine el otro usuario.
Véase también:
Definido en RFC 4918

Significado

La solicitud ha fallado porque ha fallado otra solicitud de la que depende. Este código procede de WebDAV y también se utiliza en herramientas de orquestación.

Véase también:
Definido en RFC 4918

Significado

El servidor no quiere procesar una solicitud que podría repetirse (ataque de repetición). Ocurre con TLS 1.3 Early Data (0-RTT).

Definido en RFC 8470

Significado

El servidor exige otro protocolo, indicado en la cabecera «Upgrade». Por ejemplo, una solicitud mediante HTTP/1.1 cuando el servidor exige TLS o HTTP/2.

Causas habituales

  • Versión de TLS obsoleta
  • Solo se puede acceder a la API mediante WebSocket o HTTPS

Cómo lo solucionas

  • Actualiza el cliente y la biblioteca.
  • Envía la solicitud mediante el protocolo requerido.
Véase también:
Definido en RFC 9110

Significado

El servidor exige una condición (If-Match) para evitar que se sobrescriba por error una versión obsoleta.

Causas habituales

  • Una solicitud PUT sin If-Match a un recurso protegido

Cómo lo solucionas

  • Obtén el ETag del recurso e inclúyelo en el encabezado If-Match.
Véase también:
Definido en RFC 6585

Significado

El cliente envió demasiadas solicitudes en un tiempo determinado (Rate Limiting). El encabezado «Retry-After» indica cuándo puede volver a intentarlo.

Causas habituales

  • Se ha superado el límite de la API o de inicios de sesión, por ejemplo, debido a un bucle en el script
  • Un bot, crawler o scraper genera mucha carga
  • Se activa una protección contra ataques de fuerza bruta (Fail2ban, WAF)
  • Varios usuarios comparten una dirección IP (NAT, VPN) y se cuentan juntos

Cómo lo solucionas

  • Espera el tiempo indicado en Retry-After y vuelve a intentarlo con intervalos crecientes (retroceso exponencial).
  • Agrupa las solicitudes y guarda las respuestas en caché.
  • Si administras el servicio: establece límites por IP o API-Key y responde con 429; nginx utiliza 503 de forma predeterminada.
  • Permite el acceso a los rastreadores legítimos.

Configuración y comandos (ejemplos)

nginx
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}
Para la optimización en motores de búsqueda: Googlebot trata el código 429 como un error del servidor y rastrea más despacio. Configura los límites para que no afecten de forma permanente a los motores de búsqueda.
Véase también:
Definido en RFC 6585

Significado

Las cabeceras de la solicitud son demasiado grandes, en conjunto o por separado. La causa más habitual es que haya demasiadas cookies o que sean demasiado grandes.

Causas habituales

  • Cookies acumuladas (seguimiento, sesiones) en un dominio
  • Una cabecera Authorization muy larga, por ejemplo, un JWT grande
  • Un bucle de redirección añade cada vez más cookies

Cómo lo solucionas

  • Elimina las cookies del dominio.
  • Aumenta el tamaño de los búferes de encabezados del servidor.
  • Mantén los JWT y los encabezados pequeños.

Configuración y comandos (ejemplos)

nginx
large_client_header_buffers 4 16k;
Apache
LimitRequestFieldSize 16384
Véase también:
Definido en RFC 6585

Significado

Un código específico de nginx que nunca se envía al cliente: nginx cierra la conexión sin responder. Solo aparece en el registro de acceso. Los administradores usan return 444; para rechazar bots y solicitudes con un host no válido.

Causas habituales

  • return 444; en la configuración de nginx, por ejemplo, en el servidor predeterminado

Cómo lo solucionas

  • Si es intencionado, no tienes que hacer nada.
  • Si no es intencionado, comprueba la regla con nginx -T y busca return 444.

Configuración y comandos (ejemplos)

nginx
server {
    listen 80 default_server;
    return 444;
}
Véase también:
Definido en nginx

Significado

El recurso está bloqueado por motivos legales, como una orden judicial, censura o bloqueo geográfico. El código alude a la novela «Fahrenheit 451» de Ray Bradbury.

Causas habituales

  • Bloqueo por orden, por ejemplo, por derechos de autor o por una autoridad
  • El proveedor bloquea determinadas regiones por requisitos legales.

Cómo lo solucionas

  • El operador suele indicar el motivo en el cuerpo de la respuesta.
  • Consulta al operador; eludir el bloqueo puede ser ilegal.
Véase también:
Definido en RFC 7725

Significado

El cliente cerró la conexión antes de que nginx pudiera enviar la respuesta. El código solo aparece en el registro de nginx; no es un código HTTP real.

Causas habituales

  • Un usuario interrumpe la carga de la página o cierra la pestaña
  • El tiempo de espera del cliente es menor que el tiempo de respuesta del servidor
  • Un balanceador de carga o proxy situado delante interrumpe la conexión demasiado pronto

Cómo lo solucionas

  • Reduce el tiempo de respuesta de la aplicación, por ejemplo, si las consultas a la base de datos son lentas.
  • Coordina los tiempos de espera del cliente, el proxy y el servidor.
Véase también:
Definido en nginx

Significado

Un error general del servidor: el servidor encontró un problema inesperado y no pudo completar la solicitud. El código no indica qué falló; la causa figura en el registro de errores.

Causas habituales

  • Error en el código de la aplicación, por ejemplo, un error fatal de PHP o una excepción no capturada
  • Archivo .htaccess o configuración del servidor web incorrectos
  • Permisos de archivo o propietario incorrectos en los scripts
  • No se puede acceder a la base de datos o las credenciales son incorrectas
  • Se ha alcanzado el límite de memoria de PHP (memory_limit) o max_execution_time
  • Falta una extensión de PHP o la versión de PHP no es compatible con el plugin

Cómo lo solucionas

  • Consulta el registro de errores: allí figuran el archivo y la línea del error.
  • Deshaz los cambios de los últimos minutos (plugin, actualización, .htaccess).
  • Prueba la configuración con nginx -t o apachectl configtest.
  • Activa el modo de depuración (WP_DEBUG, APP_DEBUG) solo en local o durante poco tiempo; nunca de forma permanente en un sistema de producción.

Configuración y comandos (ejemplos)

nginx
tail -n 50 /var/log/nginx/error.log
Apache
tail -n 50 /var/log/apache2/error.log
Para la optimización en motores de búsqueda: Googlebot visita con menos frecuencia los sitios con errores 5xx persistentes. Si un error dura varios días, algunas URL pueden desaparecer del índice.
Véase también:
Definido en RFC 9110

Significado

El servidor no reconoce el método solicitado o no puede ejecutarlo. A diferencia de 405, no se trata de un recurso concreto, sino de una falta general de compatibilidad.

Causas habituales

  • Un método HTTP inusual o mal escrito
  • El servidor o el proxy no admiten la función, por ejemplo, debido a software antiguo

Cómo lo solucionas

  • Comprueba el método utilizado.
  • Actualiza el software del servidor.
Véase también:
Definido en RFC 9110

Significado

Un servidor que actúa como gateway o proxy (nginx, Apache, balanceador de carga o CDN) ha recibido una respuesta no válida, o ninguna respuesta, del servidor situado detrás. El error está entre los servidores, no en el dispositivo del visitante.

Causas habituales

  • El servicio backend (PHP-FPM, Node.js, Gunicorn, contenedor Docker) no está en ejecución o ha fallado.
  • Upstream incorrecto: el puerto o socket de proxy_pass o fastcgi_pass no coincide
  • El backend cierra la conexión antes de tiempo, por ejemplo, por problemas de memoria o un fallo
  • Un firewall o SELinux bloquea la conexión con el backend
  • Un CDN no puede acceder correctamente al servidor de origen

Cómo lo solucionas

  • Comprueba el estado del servicio de backend y reinícialo (systemctl status, docker ps).
  • Comprueba si hay algún servicio escuchando en la dirección del servidor de origen (ss -tlnp).
  • Consulta el registro de errores del servidor web: «connect() failed (111: Connection refused) while connecting to upstream» indica el destino.
  • Comprueba la ruta del socket y los permisos de PHP-FPM.
  • ¿Hay suficiente RAM? El OOM-Killer suele finalizar primero el proceso de backend.

Configuración y comandos (ejemplos)

Shell
ss -tlnp | grep :3000
nginx
tail -n 50 /var/log/nginx/error.log
Shell
dmesg | grep -i "out of memory"
Para la optimización en motores de búsqueda: Un error 502 breve apenas afecta a los buscadores. Si persiste, Googlebot trata la página como cualquier otro error 5xx y reduce el rastreo.
Véase también:
Definido en RFC 9110

Significado

El servidor no puede procesar la solicitud temporalmente, normalmente por sobrecarga o mantenimiento. Puede indicar cuándo volver a intentarlo mediante «Retry-After».

Causas habituales

  • Modo de mantenimiento, por ejemplo, de WordPress o Laravel, o mantenimiento programado
  • Sobrecarga: demasiadas solicitudes o procesos simultáneos; por ejemplo, se ha alcanzado pm.max_children en PHP-FPM
  • No se puede acceder a un servicio de backend situado detrás de un proxy o un balanceador de carga
  • nginx responde de forma predeterminada con 503 cuando se superan los límites de limit_req y limit_conn
  • Se han alcanzado los límites de recursos del hosting (CPU, RAM, procesos)

Cómo lo solucionas

  • Desactiva el modo de mantenimiento. Comprueba si existe un archivo .maintenance (WordPress) o si se ha ejecutado php artisan down (Laravel).
  • Comprueba el uso de recursos (top, free -m) y aumenta los límites de procesos, como pm.max_children.
  • Durante un mantenimiento programado, devuelve deliberadamente un 503 con Retry-After.
  • Revisa el registro del servidor web en busca de errores del servidor de origen.

Configuración y comandos (ejemplos)

nginx
error_page 503 /wartung.html;

location / {
    return 503;
}

location = /wartung.html {
    root /var/www/wartung;
    internal;
    add_header Retry-After 3600 always;
}
Apache
ErrorDocument 503 /wartung.html
Header always set Retry-After "3600"

RewriteEngine On
RewriteCond %{REQUEST_URI} !=/wartung.html
RewriteRule ^ - [R=503,L]
Para la optimización en motores de búsqueda: Un error 503 breve con Retry-After es la opción adecuada para indicar tareas de mantenimiento a los buscadores. Si dura días, las URL pueden desaparecer del índice.
Véase también:
Definido en RFC 9110

Significado

La puerta de enlace o el proxy no recibió a tiempo una respuesta del servidor de origen. A diferencia de un error 502, la respuesta no es inválida, sino demasiado lenta.

Causas habituales

  • Una aplicación lenta: consulta pesada a la base de datos, informe, importación o llamada a una API externa
  • El backend está sobrecargado; todos los procesos PHP-FPM están ocupados
  • Los valores de tiempo de espera del proxy son inferiores a la duración de la solicitud
  • Un problema de red entre el proxy y el backend

Cómo lo solucionas

  • Detecta consultas y scripts lentos y aceléralos (Slow Query Log, Profiler).
  • Traslada las tareas largas a procesos en segundo plano.
  • Aumenta los tiempos de espera de forma coordinada: proxy_read_timeout, fastcgi_read_timeout y max_execution_time en PHP.
  • Comprueba la capacidad del backend (procesos, memoria RAM).

Configuración y comandos (ejemplos)

nginx
proxy_read_timeout 120s;
fastcgi_read_timeout 120s;
Apache
ProxyTimeout 120
Véase también:
Definido en RFC 9110

Significado

El servidor no admite la versión de HTTP utilizada en la solicitud.

Causas habituales

  • Un cliente o proxy muy antiguo o defectuoso usa una versión de HTTP poco habitual
  • El sistema de destino solo admite una versión determinada

Cómo lo solucionas

  • Actualiza el cliente o fuerza HTTP/1.1; con curl, usa --http1.1.
Véase también:
Definido en RFC 9110

Significado

La configuración del servidor para la negociación de contenido es incorrecta: la variante elegida remite a otra negociación. En la práctica, solo ocurre cuando hay errores de configuración.

Véase también:
Definido en RFC 2295

Significado

El servidor no tiene suficiente espacio de almacenamiento para completar la solicitud.

Causas habituales

  • El disco duro, la cuota o los inodos están llenos
  • Ya no se puede guardar la subida

Cómo lo solucionas

  • Comprueba el almacenamiento con df -h y df -i y elimina registros, Backups y cachés antiguos.
  • Aumenta la cuota.

Configuración y comandos (ejemplos)

Shell
df -h && df -i
Véase también:
Definido en RFC 4918

Significado

El servidor ha detectado un bucle infinito al procesar la solicitud.

Causas habituales

  • Un enlace WebDAV circular
  • Una estructura de directorios con un bucle de enlaces simbólicos

Cómo lo solucionas

  • Comprueba los montajes y los enlaces simbólicos.
Véase también:
Definido en RFC 5842

Significado

La solicitud no incluye la extensión que exige el servidor según RFC 2774. Este código es histórico y prácticamente nunca aparece.

Definido en RFC 2774

Significado

El cliente debe iniciar sesión en la red antes de obtener acceso. Lo envía un portal cautivo, por ejemplo, en el Wi-Fi de un hotel, aeropuerto o cafetería.

Causas habituales

  • Un portal cautivo en la red WLAN exige iniciar sesión o dar el consentimiento

Cómo lo solucionas

  • Abre cualquier página mediante http, por ejemplo, http://neverssl.com, para que aparezca el portal.
  • Inicia sesión en el portal.
Véase también:
Definido en RFC 6585

Significado

Cloudflare recibió del servidor de origen una respuesta que no puede procesar: vacía, interrumpida o con encabezados no válidos. Es un error genérico de Cloudflare.

Causas habituales

  • El servidor de origen falla al procesar la solicitud, por ejemplo, debido a un error de PHP
  • Las cabeceras de respuesta superan los 32 KB, a menudo por un exceso de cookies
  • La respuesta está vacía o la conexión se cerró sin responder
  • Un firewall bloquea parcialmente las direcciones IP de Cloudflare

Cómo lo solucionas

  • Consulta el registro de errores del servidor de origen.
  • Permite los rangos de IP de Cloudflare en el firewall y Fail2ban.
  • Reduce el tamaño de los encabezados y las cookies.
Véase también:
Definido en Cloudflare

Significado

Cloudflare no pudo establecer una conexión con el servidor de origen: este rechazó la conexión. La página y Cloudflare son accesibles, pero tu servidor de origen no.

Causas habituales

  • El servidor web (nginx, Apache) no está en funcionamiento
  • Un firewall o el proveedor de alojamiento bloquea las direcciones IP de Cloudflare
  • IP de origen o puerto incorrectos en la configuración de Cloudflare

Cómo lo solucionas

  • Inicia el servidor web y comprueba que escucha en los puertos 80 y 443.
  • Permite los rangos de IP de Cloudflare.
  • Comprueba el registro A de DNS y el puerto del servidor de origen.

Configuración y comandos (ejemplos)

Shell
ss -tlnp | grep -E ':(80|443)\b'
Véase también:
Definido en Cloudflare

Significado

Cloudflare intentó conectarse al servidor de origen, pero el establecimiento de la conexión TCP no se completó a tiempo. Se agotó el tiempo de espera antes de enviar una solicitud.

Causas habituales

  • El servidor de origen está sobrecargado o fuera de línea
  • Un firewall descarta los paquetes de Cloudflare
  • Dirección IP incorrecta o problema de enrutamiento

Cómo lo solucionas

  • Comprueba la accesibilidad y la carga del servidor.
  • Permite los rangos de IP de Cloudflare en el firewall.
  • Comprueba la dirección IP del registro DNS.
Véase también:
Definido en Cloudflare

Significado

Cloudflare no puede acceder al servidor de origen, por ejemplo, debido a un error de DNS o a la falta de una ruta.

Causas habituales

  • Dirección IP incorrecta en el registro DNS
  • Servidor o centro de datos sin conexión; problema de enrutamiento

Cómo lo solucionas

  • Comprueba el registro DNS.
  • Consulta al proveedor de hosting y comprueba la red.
Véase también:
Definido en Cloudflare

Significado

Cloudflare pudo conectarse, pero el servidor de origen no proporcionó una respuesta HTTP en un plazo de 100 segundos.

Causas habituales

  • Scripts, exportaciones o importaciones de larga duración
  • Un servidor sobrecargado

Cómo lo solucionas

  • Traslada las tareas largas a procesos en segundo plano.
  • Reduce el tiempo de respuesta.
  • Para tareas largas, usa streaming o consultas de estado en lugar de una sola solicitud.
Véase también:
Definido en Cloudflare

Significado

Ha fallado el protocolo de enlace TLS entre Cloudflare y el servidor de origen.

Causas habituales

  • El servidor de origen no ofrece HTTPS en el puerto 443
  • No hay ninguna suite de cifrado ni versión de TLS en común
  • Falta SNI o el certificado no coincide

Cómo lo solucionas

  • Comprueba la configuración TLS del servidor de origen.
  • Selecciona en Cloudflare el modo SSL/TLS adecuado para el servidor de origen.
Véase también:
Definido en Cloudflare

Significado

Cloudflare no pudo verificar el certificado del servidor de origen. Ocurre en el modo «Full (strict)».

Causas habituales

  • Certificado caducado, autofirmado o no emitido para el dominio
  • Falta un certificado intermedio

Cómo lo solucionas

  • Instala un certificado válido (Let's Encrypt o un certificado Cloudflare Origin).
  • Envía la cadena de certificados completa.
Véase también:
Definido en Cloudflare

Resultado de ejemplo

Qué te muestra esta referencia de códigos de estado HTTP

Introduce un número o una palabra clave y obtendrás al instante los códigos de estado correspondientes, cada uno con su significado, causas habituales, solución y, cuando corresponda, un ejemplo listo para nginx o Apache. Tres ejemplos:

Ejemplo 1: consultar un número

Entrada:

502

Salida: una entrada con estos datos

Código de estado y nombre
502 Bad Gateway
Clase
5xx Error del servidor
Significado
Un servidor que actúa como gateway o proxy (nginx, Apache, balanceador de carga o CDN) ha recibido una respuesta no válida, o ninguna respuesta, del servidor situado detrás. El error está entre los servidores, no en el dispositivo del visitante.
Primera causa habitual
El servicio backend (PHP-FPM, Node.js, Gunicorn, contenedor Docker) no está en ejecución o ha fallado.
Primer paso para resolverlo
Comprueba el estado del servicio de backend y reinícialo (systemctl status, docker ps).
Ejemplo para copiar (nginx)
tail -n 50 /var/log/nginx/error.log

Resultado en palabras: con 502 Bad Gateway, el servidor detrás del proxy no responde o devuelve una respuesta no válida. La entrada enumera 5 causas habituales y 5 pasos para resolverlo, como comprobar el servicio backend y consultar el registro de errores. El problema está entre los servidores, no en el visitante.

Ejemplo 2: buscar una clase

Entrada:

3xx

Salida: todos los códigos de la clase 3xx de la lista

Coincidencias de la búsqueda de 3xx
Código de estadoNombre
300Multiple Choices
301Moved Permanently
302Found
303See Other
304Not Modified
307Temporary Redirect
308Permanent Redirect

Resultado en palabras: la lista contiene 7 códigos de la clase 3xx; faltan los obsoletos 305 y 306. No todos redirigen: 304, por ejemplo, remite a la caché. Las más importantes son 301 (traslado permanente), 302 (redirección temporal) y 304 (sin cambios; usar la caché). Cada entrada explica cuándo aparece y cómo puedes utilizarla correctamente.

Ejemplo 3: buscar una palabra clave

Entrada:

timeout

Salida: primero los mejores resultados

  1. 408 Request Timeout
  2. 504 Gateway Timeout
  3. 524 A Timeout Occurred

Resultado en palabras: 3 entradas contienen el término de búsqueda. Los resultados que coinciden en el nombre aparecen primero: 408 Request Timeout, 504 Gateway Timeout, 524 A Timeout Occurred. Después figuran las entradas en las que «timeout» solo aparece en explicaciones, causas o ejemplos de configuración.

Cómo funciona

Cómo consultas un código de estado

Cuatro pasos del número al ejemplo terminado, sin cuenta ni descargas.

Paso 1

Introduce un código de estado o una palabra clave

Escribe en el buscador un número como 502, un nombre como «bad gateway» o una palabra clave como «timeout» o «redirección». Los resultados aparecen al instante con cada carácter.

Paso 2

Filtrar por clase

Usa los filtros para limitar los resultados a una clase: 3xx para redirecciones, 4xx para errores del cliente y 5xx para errores del servidor. «Más buscados» muestra los códigos más habituales.

Paso 3

Desplegar entrada

Haz clic en un código para ver su significado y, según el caso, causas habituales, pasos para solucionarlo y su efecto en el SEO. «Ver también» te lleva a códigos relacionados.

Paso 4

Copiar y adaptar el ejemplo

Cuando resulta útil, se incluye un ejemplo para nginx, Apache o la shell. Cópialo, adapta las rutas y los valores a tu servidor y vuelve a cargar el servidor web.

Errores frecuentes

404, 403, 500, 502 y 503: explicación breve de los errores HTTP más frecuentes

Respuesta breve sobre cada código de error. Con «Todas las causas y soluciones» puedes abrir la entrada completa en la referencia anterior.

400

Bad Request

El servidor no entiende la solicitud. Las causas habituales son una dirección incorrecta, cookies demasiado grandes o dañadas y una cabecera de solicitud no válida. Borra las cookies del sitio y comprueba la dirección.

Todas las causas y soluciones

401

Unauthorized

La página requiere iniciar sesión, pero tú no lo has hecho o tus credenciales no son válidas. Podrás acceder con las credenciales correctas, por ejemplo, si hay protección por contraseña mediante .htaccess o una API con token.

Todas las causas y soluciones

403

Forbidden

El servidor reconoce la dirección, pero te deniega el acceso. Entre las causas habituales están los permisos de archivo incorrectos, la ausencia de un documento de índice, un bloqueo de IP o una regla del firewall.

Todas las causas y soluciones

404

Not Found

No hay nada en esta dirección: puede haber un error tipográfico, la página puede haberse eliminado o trasladado, o puede haber un problema con las mayúsculas y minúsculas. Redirige las páginas trasladadas mediante una redirección 301. Los errores 404 aislados no perjudican el posicionamiento.

Todas las causas y soluciones

429

Too Many Requests

Has enviado demasiadas solicitudes en poco tiempo. Espera el plazo indicado en el encabezado Retry-After y vuelve a intentarlo, aumentando el intervalo entre intentos.

Todas las causas y soluciones

500

Internal Server Error

Un error general del servidor. La causa figura en el registro de errores del servidor web. Suele deberse a un error de código, un archivo .htaccess defectuoso, permisos incorrectos o una base de datos inaccesible.

Todas las causas y soluciones

502

Bad Gateway

El proxy o balanceador de carga no recibe una respuesta válida del backend, normalmente porque PHP-FPM, Node.js o el servidor de aplicaciones no está en funcionamiento o ha fallado. Comprueba el servicio y su registro.

Todas las causas y soluciones

503

Service Unavailable

El servidor está sobrecargado o en mantenimiento e indica que es algo temporal. Para los trabajos de mantenimiento, el código adecuado es 503 con la cabecera Retry-After.

Todas las causas y soluciones

504

Gateway Timeout

El backend tarda demasiado en responder y el proxy deja de esperar. Busca consultas o scripts lentos y, si es necesario, aumenta el tiempo de espera; en nginx, proxy_read_timeout.

Todas las causas y soluciones

Vista general

Las cinco clases de códigos de respuesta HTTP

El primer dígito indica de qué se trata. Así puedes saber sin consultar nada si el error está en el visitante o en el servidor.

1xx

Información

La solicitud se ha recibido y sigue procesándose. Es un aviso provisional, todavía no un resultado.

Frecuente:

4 códigos en esta referencia

2xx

Éxito

La solicitud se entendió y procesó correctamente. 200 es el caso habitual.

Frecuente: 200, 201, 204

10 códigos en esta referencia

3xx

Redirección

El cliente debe realizar otro paso, normalmente seguir una nueva dirección o usar la caché.

Frecuente: 301, 302, 304, 307, 308

7 códigos en esta referencia

4xx

Error del cliente

La solicitud es incorrecta o no está permitida. Desde el punto de vista del servidor, el error corresponde al cliente, como un 404 por una dirección desconocida.

Frecuente: 400, 401, 403, 404, 405, 410, 413, 422, 429

31 códigos en esta referencia

5xx

Error del servidor

La solicitud era válida, pero el servidor no pudo atenderla. El error está del lado del operador, por ejemplo, 500, 502 o 503.

Frecuente: 500, 502, 503, 504

18 códigos en esta referencia

Redirecciones

¿301 o 302? Comparación de los códigos de redirección

Cinco códigos redirigen. Se diferencian en dos aspectos: si la redirección es permanente y si el cliente conserva el método HTTP.

Comparación de los códigos de estado de redirección 301, 302, 303, 307 y 308
Código de estadoDuraciónEl método se mantiene
301 Moved PermanentlyTraslado de una página o dominio, de http a https o de www al dominio principal. El estándar para SEO.permanenteno garantizado
302 FoundRedirección temporal, por ejemplo, para campañas, inicio de sesión o selección de idioma.temporalmenteno garantizado
303 See OtherRedirigir a una página de resultados después de un POST (Post/Redirect/Get). El navegador accede a ella mediante GET.temporalmenteno garantizado
307 Temporary RedirectRedirección temporal de una API o un formulario en la que debe conservarse el método.temporalmentesí
308 Permanent RedirectTraslado permanente de una API o del destino de un formulario en el que debe conservarse el método.permanentesí

Regla general: 301 para páginas normales que se trasladan permanentemente; 302 para cambios temporales. Si una API o un formulario debe conservar el método POST, usa 308 en lugar de 301 y 307 en lugar de 302. «No garantizado» significa que los navegadores suelen convertir una solicitud POST en GET.

Práctica

Cómo encuentras el código de estado de una página

En el navegador, abre las herramientas de desarrollo (F12). En la pestaña «Red» verás el código de cada solicitud. En el servidor o en la consola, te ayudarán estos cuatro comandos:

Muestra solo las cabeceras de respuesta; la primera línea contiene el código de estado.

curl -I https://example.com/seite

Muestra únicamente el código de estado, útil para scripts y monitorización.

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/seite

Sigue las redirecciones y muestra cada paso con su código de estado y destino.

curl -sIL https://example.com/alt | grep -iE '^(HTTP|location)'

Cuenta los códigos de estado del registro de acceso de nginx o Apache (formato combined) y los ordena por frecuencia.

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

Descubrir más

Más herramientas

Comprobador de disponibilidad de sitios web

Comprueba si un sitio web está disponible, va lento o está caído: estado HTTP, tiempo de respuesta y causa de errores como problemas de DNS, tiempos de espera agotados, errores de TLS o errores 5xx.

Creado por Eric Mager

Comprobador SSL

Consulta de un vistazo el estado, el emisor, el período de validez y la fecha de caducidad de un certificado SSL/TLS.

Creado por Sebastian Rademacher

Verificador de redirecciones

Comprueba las cadenas de redirecciones de una URL salto a salto: códigos de estado (301/302/307/308), cabeceras HTTP, IP del servidor y tiempo de respuesta de cada redirección.

Creado por Luca Stanek

Comprobador de puertos

Comprueba si determinados puertos están abiertos en una IP o un nombre de host. Selecciona un protocolo o juego en lugar de escanear todos los puertos a la vez.

Creado por Sebastian Rademacher

Calculadora CHMOD

Configura permisos de archivos Unix/Linux mediante casillas para obtener el valor octal y la notación simbólica, o decodifícalos a la inversa. Incluye setuid/setgid/sticky bit y un comando chmod listo para copiar.

Creado por Justin Schuessler

Generador de .htaccess y generador de htpasswd

Crea archivos .htaccess y .htpasswd para Apache en línea: redirecciones 301, HTTPS, protección con contraseña bcrypt, reglas de WordPress, páginas de error, caché, GZIP y protección contra hotlinking. Funciona íntegramente en el navegador.

Creado por Dimitri Heissler

FAQ

Preguntas frecuentes

Respuestas breves sobre los códigos HTTP más frecuentes, sus causas y esta referencia.

Un código de estado HTTP es un número de tres cifras que un servidor devuelve por cada solicitud. Indica si se ha procesado correctamente y, si no, por qué. La primera cifra señala la clase: 1xx información, 2xx éxito, 3xx redirección, 4xx error del cliente y 5xx error del servidor. Los códigos de error HTTP que encontrarás con más frecuencia son 400, 401, 403, 404 y 429 del lado del cliente, y 500, 502, 503 y 504 del lado del servidor. El filtro «Más buscados» de la referencia los muestra junto con otros códigos habituales.

200 OK significa que la solicitud se ha procesado correctamente y el servidor devuelve la página o los datos. Es lo normal para las páginas que deben ver los visitantes y los motores de búsqueda. Asegúrate de que las páginas de error no devuelvan 200, porque eso genera «soft 404». Códigos relacionados: 201 Created indica que se ha creado un recurso; 204 No Content, una respuesta correcta sin cuerpo; y 304 Not Modified, que el archivo no ha cambiado y el navegador usa su copia.

El servidor no entiende la solicitud y la rechaza antes de procesarla. Las causas habituales son una dirección mal formada con caracteres no válidos, cookies demasiado grandes o dañadas, una cabecera demasiado grande o un cuerpo de solicitud con un formato incorrecto en una API. Si visitas la página, borra sus cookies. Si la administras, comprueba la solicitud, las cabeceras y el registro. Si el formato es correcto pero algún valor no es válido, como un campo obligatorio ausente, muchas API responden con 422 Unprocessable Content (antes «Unprocessable Entity»).

Se puede acceder al servidor, pero no reconoce la dirección. Comprueba primero si hay errores tipográficos y si el nombre del archivo respeta las mayúsculas y minúsculas, ya que Linux las distingue. Después, comprueba la ruta en el servidor web y, en WordPress o una aplicación de página única, las reglas de reescritura (try_files en nginx). Redirige las páginas trasladadas con 301. Unos pocos errores 404 no perjudican el posicionamiento, pero sí las páginas importantes con enlaces entrantes que ya no llevan a ninguna parte.

401 Unauthorized significa «no autenticado»: el acceso funciona con credenciales válidas. 403 Forbidden significa «autenticado o no, el acceso no está permitido»: el servidor lo deniega. Entre las causas habituales de 403 están los permisos o propietarios incorrectos de los archivos, la falta de un archivo de índice, los bloqueos de IP y las reglas del WAF. La calculadora CHMOD convierte permisos como 755 para directorios y 644 para archivos. Ir a la calculadora CHMOD

El código no revela la causa; esta figura en el registro de errores del servidor web (en nginx, /var/log/nginx/error.log; en Apache, /var/log/apache2/error.log) o en el registro de PHP. Entre las causas habituales están un error en el código, un archivo .htaccess incorrecto, permisos de archivo erróneos, una base de datos inaccesible o el agotamiento del límite de memoria de PHP. Deshaz el último cambio (Plugin, Update o regla) y comprueba la configuración con nginx -t o apachectl configtest.

502 Bad Gateway: el proxy recibe una respuesta no válida del backend o no recibe ninguna, normalmente porque el servicio (PHP-FPM, Node.js) no se está ejecutando. 503 Service Unavailable: el servidor está sobrecargado o en mantenimiento y lo comunica directamente. 504 Gateway Timeout: el backend responde, pero demasiado tarde, normalmente por una consulta pesada o una sobrecarga. Primer paso en los tres casos: lee el registro de errores y comprueba el servicio backend. Para un mantenimiento programado, el código correcto es 503 con la cabecera «Retry-After», no una página de mantenimiento con 200.

301 indica un traslado permanente: los motores de búsqueda adoptan la nueva dirección y transfieren el posicionamiento. 302 indica una redirección temporal: la dirección antigua permanece en el índice. Usa 301 para trasladar dominios y páginas, y 302 para situaciones temporales, como campañas. Si necesitas conservar el método (POST) en un formulario o una API, usa 308 en lugar de 301 y 307 en lugar de 302.

Estos códigos no forman parte del estándar HTTP. Los códigos del 520 al 526 son de Cloudflare e indican que Cloudflare, no tu visitante, tiene un problema con tu servidor de origen: 520 error desconocido, 521 conexión rechazada, 522 no se pudo establecer la conexión, 523 servidor de origen inaccesible, 524 sin respuesta en 100 segundos, 525 fallo en el protocolo de enlace TLS y 526 certificado no válido. Normalmente ayuda permitir los rangos de IP de Cloudflare en el firewall y comprobar el servidor web y el certificado. Los códigos 444 y 499 solo aparecen en el registro de nginx: con 444, nginx cierra la conexión deliberadamente sin responder; con 499, el cliente cerró la conexión antes de recibir la respuesta.

En el navegador, pulsa F12 para abrir las herramientas de desarrollo y consulta la columna «Estado» de la pestaña «Red». En la terminal, curl -I https://example.com muestra las cabeceras y el código de estado, mientras que curl -s -o /dev/null -w "%{http_code}" https://example.com muestra solo el número. Con curl -sIL también puedes ver cada redirección de la cadena. Esta referencia no consulta ninguna dirección: funciona por completo en tu navegador. Solo el término de búsqueda y el filtro de categorías aparecen en la URL para que puedas compartir una búsqueda. Puedes comprobar una cadena de redirecciones con Redirect Checker. Ir a Redirect Checker

¿Tienes más preguntas?

Contactar con soporte
¿Estás gestionando algo propio?

Código de estado 200 en vez de 502: hosting que entrega tu aplicación de forma fiable

Un VPS de ZAP-Hosting pone tu aplicación o proyecto en línea de forma fiable.

4,4/5 Trustpilot32.000+ Servidores activosDesde 2010
Ver hosting

Sin configuración. Sin riesgos. En línea en segundos.

Duración flexibleCancelable en cualquier momentoEn línea en 60 segundos

¿Buscas más herramientas? Ver todas las herramientas para desarrolladores