--- title: "¿Qué son las cabeceras HTTP? Las más comunes, explicadas" description: "Las cabeceras HTTP son líneas nombre: valor que van antes del cuerpo de cada solicitud y respuesta. Qué hacen, las más comunes y cómo verlas en Chrome y curl." url: https://proxynet.io/es/blog/what-are-http-headers date: 2026-11-15 author: "Acar Diveroli" category: "Proxy 101, Tutoriales" lang: es --- # ¿Qué son las cabeceras HTTP? Las más comunes, explicadas Abres una tienda online y aparece en tu idioma, mantiene tu sesión iniciada y carga rápido desde una caché. Nada de eso lo decidió la propia página. Antes de que llegue su primera línea, tu navegador y el servidor intercambian una docena de líneas cortas sobre quién pregunta, qué acepta y qué va a volver. Esas líneas son las cabeceras HTTP. Este artículo muestra una solicitud y una respuesta reales capturadas con `curl`, las cabeceras que más vas a encontrar, si los nombres distinguen entre mayúsculas y minúsculas, y cómo leer las cabeceras en Chrome y con curl. Al final verás las cabeceras de seguridad para propietarios de sitios, las cabeceras que un proxy añade o lee y seis preguntas frecuentes. > **Nota: Respuesta breve** > > Las cabeceras HTTP son líneas con la forma `Nombre: valor` que se envían al principio de cada solicitud y de cada respuesta HTTP, antes del cuerpo. Las cabeceras de solicitud le dicen al servidor qué sitio quieres (`Host`), qué navegador usas (`User-Agent`) y qué formatos e idiomas aceptas, y además llevan tus cookies y tus tokens de inicio de sesión. Las cabeceras de respuesta le dicen al navegador qué tipo de archivo llega (`Content-Type`), cuánto tiempo puede guardarse en caché, qué cookies debe almacenar y adónde ir después. Los nombres de las cabeceras no distinguen entre mayúsculas y minúsculas. Puedes leerlas en Chrome en Herramientas para desarrolladores > Red > Encabezados, o con `curl -I` y `curl -v`. ## ¿Qué son las cabeceras HTTP? Las cabeceras HTTP son datos adicionales, cada uno con su nombre, que se envían con una solicitud o una respuesta antes del propio contenido. El RFC 9110, el estándar que define HTTP, llama a los campos enviados antes del contenido «header fields», o simplemente headers (cabeceras). Cada cabecera es una línea con un nombre, dos puntos y un valor, como `Accept-Language: es-ES`. Todo mensaje HTTP tiene la misma forma: una primera línea, las cabeceras, una línea vacía y, si lo hay, el cuerpo. En una solicitud, la primera línea indica el método y la ruta (`GET /`); en una respuesta, el código de estado (`200 OK`). El cuerpo es la página, la imagen o los datos; las cabeceras describen ese cuerpo y a las dos partes del intercambio. Las cabeceras de solicitud van de tu navegador o tu app al servidor, y las de respuesta hacen el camino inverso. La [referencia de cabeceras HTTP de MDN](https://developer.mozilla.org/es/docs/Web/HTTP/Reference/Headers) recoge todas las cabeceras estándar ordenadas por grupos. Los nombres que empiezan por `X-` son extensiones caseras; esa costumbre de nombrarlas así se desaconsejó oficialmente en 2012, pero muchos de esos nombres siguen en uso. ## ¿Cómo funcionan las cabeceras en una solicitud y una respuesta? Cargar una página consiste en una solicitud y una respuesta, cada una con sus propias cabeceras: 1. **Tu navegador se conecta al servidor.** Si la dirección empieza por `https://`, primero establece el cifrado. 1. **Envía la línea de solicitud y las cabeceras de solicitud:** `GET /`, y después `Host`, `User-Agent`, `Accept`, `Accept-Language` y las cookies que tenga guardadas para ese sitio. 1. **Una línea vacía cierra las cabeceras.** Un formulario o una llamada a una API añade un cuerpo detrás. 1. **El servidor lee las cabeceras:** `Host` elige el sitio, `Accept-Language` el idioma, `Cookie` el usuario que tiene la sesión iniciada. 1. **Responde con una línea de estado y cabeceras de respuesta,** como `200 OK` y `Content-Type`, seguidas de una línea vacía y del cuerpo. 1. **El navegador actúa en consecuencia:** muestra la página, guarda las cookies, almacena una copia en caché o sigue una redirección. ## ¿Cómo son una solicitud y una respuesta HTTP reales? Aquí tienes un intercambio con example.com hecho con `curl -v`. curl es una herramienta de línea de comandos que descarga direcciones web y viene incluida en Windows 10 y 11, en macOS y en la mayoría de los sistemas Linux; `-v` (verbose, detallado) imprime los dos lados. Lo ejecutamos en Windows 11 el 15 de noviembre de 2026 y recortamos la salida para dejar solo las cabeceras: ```text > GET / HTTP/1.1 > Host: example.com > User-Agent: curl/8.22.0 > Accept: */* > < HTTP/1.1 200 OK < Date: Sun, 15 Nov 2026 15:40:29 GMT < Content-Type: text/html; charset=utf-8 < Transfer-Encoding: chunked < Connection: keep-alive < Server: cloudflare < last-modified: Thu, 12 Nov 2026 21:56:22 GMT < allow: GET, HEAD < Accept-Ranges: bytes < Age: 6679 < cf-cache-status: HIT < alt-svc: h3=":443"; ma=86400 ``` Las líneas que empiezan por `>` son lo que envió curl, y las que empiezan por `<`, lo que respondió el servidor; el `>` solitario es la línea vacía que cierra las cabeceras de solicitud. curl envía tres cabeceras de solicitud; un navegador, más de diez. - **`Content-Type: text/html; charset=utf-8`:** el cuerpo es una página web en texto UTF-8. - **`Age: 6679`:** la red de distribución de contenidos (CDN) que está delante del sitio guarda esta copia desde hace 6.679 segundos, alrededor de 1 hora y 51 minutos. - **`cf-cache-status: HIT`:** no es una cabecera estándar, sino una nota propia de esa red que indica que la copia salió de su caché. - **`alt-svc: h3=":443"`:** el sitio también habla HTTP/3 en el puerto 443. Fíjate en `Content-Type` junto a `last-modified`: una sola respuesta, dos maneras de escribir los nombres. ## ¿Las cabeceras HTTP distinguen entre mayúsculas y minúsculas? No, los nombres de las cabeceras no distinguen entre mayúsculas y minúsculas: `Content-Type`, `content-type` y `CONTENT-TYPE` son la misma cabecera. El [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-field-names) lo dice en una línea: «Field names are case-insensitive.» Cuando pedimos la misma página por `http://` sin cifrar, el servidor llegó a escribir `Last-Modified` y `Allow` con mayúscula inicial. Los valores siguen las reglas de cada cabecera. `text/html` y `TEXT/HTML` designan el mismo tipo de archivo, pero el valor de una cookie o un token de inicio de sesión tiene que volver exactamente como lo envió el servidor. HTTP/2 y HTTP/3, las versiones más recientes del protocolo, exigen nombres en minúsculas, y por eso las Herramientas para desarrolladores de Chrome muestran `content-type`. En nuestra prueba, Chromium cargó example.com por HTTP/3, y su solicitud empezaba con `:method`, `:path`, `:scheme` y `:authority`. Estas pseudocabeceras llevan lo que HTTP/1.1 pone en la primera línea y en la cabecera `Host`. En tu código, compara los nombres de las cabeceras sin tener en cuenta mayúsculas ni minúsculas. El objeto `Headers` de JavaScript y la biblioteca requests de Python ya lo hacen; un diccionario normal, no. ## ¿Cuáles son las cabeceras de solicitud más comunes? Las cabeceras de solicitud describen quién pregunta y qué acepta: | Cabecera | Qué le dice al servidor | Valor de ejemplo | |---|---|---| | `Host` | Qué sitio quieres | `example.com` | | `User-Agent` | Navegador o app y su versión | `curl/8.22.0` | | `Accept` | Tipos de archivo que puedes usar | `text/html` | | `Accept-Language` | Idiomas que prefieres | `es-ES,es;q=0.9` | | `Cookie` | Cookies guardadas para este sitio | `theme=dark` | | `Authorization` | Inicio de sesión en el sitio o en la API | `Bearer ` | | `Referer` | Página de la que vienes | `https://example.com/` | Gracias a **Host**, un servidor con una sola dirección IP puede alojar muchos sitios web: lee el nombre y elige el sitio correspondiente. Con **Accept-Language** un sitio elige un idioma antes de que tú elijas uno; los números `q` son pesos de 0 a 1, así que `es-ES,es;q=0.9` significa primero español de España y, en segundo lugar, cualquier variante de español. **Cookie** devuelve los pequeños valores que un sitio guardó antes con `Set-Cookie`, como el ID de una sesión iniciada. [¿Qué son las cookies y para qué sirven?](/es/blog/what-are-cookies) recorre ese intercambio paso a paso. **Authorization** lleva credenciales para el propio sitio, a menudo después de una respuesta 401 Unauthorized; el estándar prohíbe que un proxy la modifique. **Referer**, mal escrita en el estándar, indica la página cuyo enlace te trajo hasta aquí; en un enlace hacia otro sitio, los navegadores envían por defecto solo el origen, como `https://example.com/`. Chrome también envía cabeceras propias, como `sec-ch-ua`, una lista breve de marcas y versiones del navegador. ## ¿Cuáles son las cabeceras de respuesta más comunes? Las cabeceras de respuesta le dicen al navegador qué ha recibido y qué debe hacer con ello: | Cabecera | Qué le dice al navegador | Valor de ejemplo | |---|---|---| | `Content-Type` | Tipo de archivo que va en el cuerpo | `application/json` | | `Cache-Control` | Si se guarda en caché y durante cuánto tiempo | `max-age=3600` | | `Set-Cookie` | Una cookie que hay que guardar | `theme=dark; Secure` | | `Location` | Dirección a la que ir después | `/login` | | `Retry-After` | Cuánto tiempo esperar | `120` | | `Strict-Transport-Security` | Usar solo HTTPS a partir de ahora | `max-age=31536000` | **Content-Type** decide qué hace el navegador con el cuerpo: mostrar `text/html` como página, enseñar `image/png` como imagen, pasar `application/json` a un script. Un valor equivocado es el motivo por el que una página a veces muestra código en bruto. `Content-Disposition: attachment`, en cambio, pide al navegador que descargue el archivo. **Cache-Control** fija las reglas de caché: `max-age=3600` permite reutilizar la copia durante una hora, y `no-store` prohíbe guardar ninguna copia. **Set-Cookie** puede aparecer muchas veces en una misma respuesta, una línea por cookie. **Location** acompaña a las redirecciones (los códigos 3xx) e indica la nueva dirección. **Retry-After** acompaña a 503 Service Unavailable y a 429 Too Many Requests e indica cuánto esperar, en segundos o como fecha. `Retry-After: 120` significa dos minutos; un cliente bien hecho espera ese tiempo. ## ¿Cómo ver las cabeceras HTTP en Chrome? Chrome muestra todas las cabeceras de cada solicitud en sus Herramientas para desarrolladores (DevTools), en el panel Red. Con los nombres de la interfaz en español: 1. Abre la página y pulsa **F12**, o **Ctrl + Mayús + I** en Windows (**Cmd + Opción + I** en un Mac). También puedes hacer clic derecho en la página y elegir **Inspeccionar**. 1. Haz clic en la pestaña **Red**. Las herramientas solo registran mientras están abiertas, así que vuelve a cargar la página. 1. En la columna **Nombre**, haz clic en la primera fila, que es la propia página. 1. Abre la pestaña **Encabezados**, que es como Chrome llama a las cabeceras. **General** muestra la dirección, el método y el código de estado; debajo aparecen **Encabezados de respuesta** y **Encabezados de solicitud**. 1. Marca **Sin procesar** junto a una sección para ver las líneas tal como llegaron, en su orden original. Si ves el aviso «Se muestran los encabezados provisionales», lo más probable es que el archivo saliera de la caché del navegador; marca **Inhabilitar caché** en la parte superior del panel y vuelve a cargar. La [referencia del panel Red de Chrome](https://developer.chrome.com/docs/devtools/network/reference?hl=es-419#headers) explica las demás opciones, como mostrar una cabecera en su propia columna. Para repetir una solicitud fuera del navegador, haz clic derecho sobre ella y elige **Copiar** > **Copiar como cURL (cmd)** en Windows, o **Copiar como cURL** en un Mac. El comando incluye tus cookies y cualquier cabecera de inicio de sesión, así que nunca lo pegues en un foro ni en un chat públicos. ## ¿Cómo ver las cabeceras HTTP con curl? curl muestra las cabeceras desde la línea de comandos, algo práctico para revisar tu propio sitio. Escribe los comandos en el Símbolo del sistema; en Windows PowerShell, escribe `curl.exe`, porque ahí `curl` es el nombre de otro comando. ```cmd curl -I https://example.com ``` `-I` pide solo las cabeceras de respuesta, mediante una solicitud `HEAD`; en nuestra prueba imprimió las mismas cabeceras de respuesta que vimos arriba. Otras dos opciones: - **`curl -v https://example.com`** muestra las cabeceras de solicitud, las de respuesta y los detalles de la conexión. - **`curl -I -H "Accept-Language: de" https://example.com`** añade una cabecera tuya, por ejemplo para probar cómo responde tu sitio a un navegador configurado en alemán. El curl incluido en Windows habla HTTP/1.1 (su salida detallada dice `ALPN: curl offers http/1.1`), así que ves los nombres tal como los escribió el servidor. Una versión de curl compilada con soporte para HTTP/2 los imprime en minúsculas en los sitios que hablan HTTP/2. ## ¿Qué cabeceras de seguridad debe enviar un sitio web? Las cabeceras de seguridad son cabeceras de respuesta que activan protecciones adicionales del navegador para tu sitio. Se configuran en el servidor web, en la red de distribución de contenidos o en la propia aplicación: - **Strict-Transport-Security (HSTS):** usar solo HTTPS en este sitio durante `max-age` segundos. Los navegadores la ignoran si llega por HTTP sin cifrar. Añade `includeSubDomains` únicamente cuando todos tus subdominios funcionen con HTTPS. - **Content-Security-Policy (CSP):** enumera desde dónde puede cargar la página scripts, estilos e imágenes, lo que limita lo que puede hacer un script inyectado. - **X-Content-Type-Options: nosniff:** el navegador confía en `Content-Type` en lugar de adivinar el tipo de archivo. - **X-Frame-Options**, o `frame-ancestors` en la CSP: si otros sitios pueden mostrar tu página dentro de un marco, una defensa contra el clickjacking (engañar a los visitantes para que hagan clic en una página oculta). - **Referrer-Policy:** qué parte de la dirección de tu página va en `Referer` cuando los visitantes se marchan. Revisa tu sitio con `curl -I` o en **Encabezados de respuesta** en DevTools. En las cookies de inicio de sesión, los atributos `Secure`, `HttpOnly` y `SameSite` dentro de `Set-Cookie` importan tanto como estas cabeceras. ## ¿Qué cabeceras añade o lee un proxy? Un proxy trabaja con unas pocas cabeceras propias: algunas las lee de tu solicitud y otras puede añadirlas antes de reenviarla. - **`Proxy-Authorization`** lleva al proxy tus datos de acceso, como `user:pass`; el proxy los usa él mismo en lugar de pasarlos al sitio. - **`Proxy-Authenticate`** llega con la respuesta `407 Proxy Authentication Required` del proxy cuando faltan los datos de acceso o son incorrectos. - **`Via`** deja constancia de que un intermediario gestionó el mensaje; el estándar HTTP dice que un proxy debe añadirla. - **`X-Forwarded-For`** y su forma estándar, **`Forwarded`**, llevan la dirección IP original del cliente. El [RFC 7239](https://www.rfc-editor.org/rfc/rfc7239), que define `Forwarded`, dice que un proxy pensado para ofrecer anonimato no la usará. Que un proxy añada o no `Via` o `X-Forwarded-For` es lo que clasifica los proxies en transparentes, anónimos y élite; [Proxy transparente, anónimo y élite: ¿qué los diferencia?](/es/blog/anonymous-proxy-levels) muestra la misma solicitud en los tres niveles. Con HTTPS, casi todo esto desaparece. Para una dirección `https://`, tu app pide al proxy que abra un túnel con `CONNECT`, y desde ese momento el proxy reenvía bytes cifrados sin leerlos. Ejecutamos curl a través de un pequeño proxy de prueba en nuestro propio equipo, con los datos de acceso de ejemplo `user:pass`: ```text > CONNECT example.com:443 HTTP/1.1 > Host: example.com:443 > Proxy-Authorization: Basic dXNlcjpwYXNz > User-Agent: curl/8.22.0 > Proxy-Connection: Keep-Alive > < HTTP/1.1 200 Connection established < > GET / HTTP/1.1 > Host: example.com > User-Agent: curl/8.22.0 > Accept: */* ``` El registro del proxy solo recogió el primer bloque. La solicitud `GET` y sus cabeceras viajaron dentro del túnel cifrado, de modo que el proxy no pudo leerlas ni añadirles líneas. `dXNlcjpwYXNz` es simplemente `user:pass` en Base64, una codificación, no un cifrado. Así transportan tu tráfico los [Proxies HTTPS](https://proxynet.io/es/https-proxy): el gateway de Proxynet retransmite el túnel sin descifrarlo, por lo que no instalas ningún certificado nuestro. Un proxy cambia la dirección IP que ve el sitio; no es motivo para reescribir tus propias cabeceras. No modifiques `User-Agent`, `Referer` ni `X-Forwarded-For` para hacerte pasar por otro navegador u otro visitante; los scripts que ejecutes deben enviar un `User-Agent` honesto que nombre tu herramienta. ## Dónde te encuentras con las cabeceras HTTP - **Versiones por idioma:** un sitio lee `Accept-Language` para elegir la primera página que ves. - **Inicio de sesión:** la cabecera `Cookie` lleva tu sesión en cada solicitud. - **API:** un token en `Authorization`, `Content-Type: application/json` para el cuerpo. - **Caché:** `Cache-Control` y `Age` deciden si una copia guardada sigue vigente. - **Descargas:** `Content-Disposition` decide si un archivo se abre o se guarda. ## Errores frecuentes - **Leer los nombres de las cabeceras distinguiendo mayúsculas y minúsculas en el código.** `headers["Content-Type"]` en un diccionario normal no encuentra el `content-type` que manda un servidor HTTP/2. - **Compartir un comando «Copiar como cURL».** Lleva tus cookies, así que cualquiera que lo tenga puede actuar como si fuera tú. - **Fiarte de un `X-Forwarded-For` que llega de internet.** Un cliente puede enviar cualquier valor; solo son fiables las entradas que añadió tu propio proxy o tu balanceador de carga (el servidor que reparte el tráfico entre tus servidores). - **Activar HSTS con `includeSubDomains` demasiado pronto.** Un subdominio sin HTTPS queda inaccesible para los visitantes que ya vieron la cabecera. - **Dejar que se acumulen las cookies.** Las cookies grandes llevan la solicitud por encima del límite de cabeceras del servidor, y el sitio responde 400 o 431. ## Guía de decisión | Lo que quieres | Dónde mirar o qué usar | |---|---| | Ver lo que envía tu navegador | DevTools > Red > Encabezados | | Revisar rápido la respuesta de un sitio | `curl -I` | | Saber adónde lleva una redirección | `Location` en la respuesta | | Averiguar por qué una página sale en otro idioma | `Accept-Language` en la solicitud | | Reforzar la seguridad de tu propio sitio | HSTS, CSP, nosniff, Referrer-Policy | | Autenticarte en un proxy | `Proxy-Authorization`, que añade tu app | ## Preguntas frecuentes ### ¿Qué es la cabecera User-Agent? Es la cabecera de solicitud que nombra el navegador o el programa que hace la solicitud, con su versión y normalmente el sistema operativo; curl envía `curl/8.22.0`. Los sitios la usan para sus estadísticas y para adaptarse a las rarezas de cada navegador. [¿Qué es el User-Agent? Cómo verlo y cambiarlo](/es/blog/what-is-user-agent) muestra cómo leer el tuyo. ### ¿Qué significa X-Forwarded-For? Es una cabecera en la que un proxy o un balanceador de carga escribe la dirección IP del cliente que le envió la solicitud, para que el servidor que está detrás vea la dirección del visitante. Nunca se estandarizó formalmente; `Forwarded` (RFC 7239) es la versión estándar. Cualquiera puede enviarla, así que un servidor solo debe fiarse de las entradas que añadió su propio proxy. ### ¿Las cabeceras HTTP se cifran con HTTPS? Sí. Con HTTPS, las cabeceras viajan dentro del cifrado junto con el cuerpo, así que las redes y los proxies del camino no pueden leerlas. La dirección IP del servidor sigue siendo visible y, en la mayoría de los casos, también el nombre de dominio, que se envía mientras se establece la conexión. ### ¿Qué son las cabeceras HTTP en una API? Son las mismas cabeceras, usadas de forma más deliberada. Una llamada a una API suele enviar una clave o un token en `Authorization` (algunas API usan una cabecera propia, como `X-API-Key`), declara el cuerpo con `Content-Type: application/json` y pide JSON con `Accept`. Cuando se envían demasiadas solicitudes, la respuesta suele ser un 429 con `Retry-After`. ### ¿Qué significa «HTTP header is larger than 8192 bytes»? Significa que una solicitud o una respuesta llevaba más datos de cabecera de los que acepta el software que la procesa. El mensaje procede de Netty, una biblioteca de red para Java con un límite predeterminado de 8.192 bytes; otras cifras, como 10.240, son límites configurados a propósito. HTTP en sí no fija ningún máximo. Si eres visitante, borra las cookies de ese sitio; si eres desarrollador, reduce las cookies o los tokens, o sube el límite. ### ¿Por qué la cabecera Referer está mal escrita? Porque el nombre con la errata ya figuraba en la especificación de HTTP/1.0 de 1996, y el software de todo el mundo lee la cabecera con ese nombre. El estándar actual conserva `Referer` con una nota «[sic]»; la cabecera más reciente, `Referrer-Policy`, sí está bien escrita. ## En resumen Las cabeceras HTTP son las líneas `Nombre: valor` del principio de cada solicitud y de cada respuesta. Las cabeceras de solicitud indican el sitio, el navegador, los idiomas, las cookies y las credenciales; las de respuesta dicen qué es el cuerpo, cuánto tiempo guardarlo en caché, qué cookies almacenar y adónde ir después. Los nombres no distinguen entre mayúsculas y minúsculas, y HTTP/2 y HTTP/3 los escriben en minúsculas. Léelas en DevTools o con curl, y envía cabeceras de seguridad desde tu propio sitio. Con HTTPS, un proxy solo ve la breve solicitud `CONNECT` con el nombre del sitio y tus datos de acceso al proxy; para enviar tu propio tráfico a través de uno, empieza por nuestros [servicios de proxy](/es/proxy).