Contenido del artículo

Envías una solicitud con método POST, con cuerpo y cabecera de autorización, pero al servidor llega un GET vacío sin ninguna cabecera personalizada. ¿Te suena familiar? Si trabajas con proxies y solicitudes automatizadas, tarde o temprano te encontrarás con este comportamiento. No es un error de tu código ni una falla del proxy Proxeon. Es una mecánica normal de las redirecciones HTTP, prevista por la especificación, que simplemente hay que entender y saber controlar.

En esta guía analizaremos por qué al seguir una redirección el método de la solicitud puede cambiar y las cabeceras pueden desaparecer. Aprenderás a distinguir entre los códigos 301, 302, 307 y 308, conocerás cómo se comportan los diferentes clientes HTTP por defecto y obtendrás ejemplos prácticos para desactivar los saltos automáticos y procesarlos manualmente. Todo con código real, sin rodeos.

Introducción: la solicitud sale con método POST y llega GET, ¿quién tiene la culpa?

Imagina una tarea de ingeniería. Haces una solicitud POST a un endpoint de autenticación a través de un proxy. El servidor responde con un código de redirección y te indica una nueva dirección. Tu cliente HTTP sigue automáticamente esa dirección. Pero lo hace ya con método GET, sin el cuerpo de la solicitud y sin la cabecera Authorization. El resultado es que el servidor de destino no recibe lo que enviaste y la lógica se rompe.

¿Quién tiene la culpa? Formalmente, nadie. Este comportamiento está incorporado en la implementación histórica de los códigos 301 y 302. Antes, los navegadores y las bibliotecas casi siempre cambiaban el método a GET al recibir estos códigos. Esto se convirtió en un estándar de facto y se consolidó. Posteriormente, para dar a los desarrolladores la posibilidad de conservar el método y el cuerpo, se introdujeron los códigos 307 y 308. Hablaremos de ellos en detalle más adelante.

Qué obtendrás al final

Después de leer esta guía, podrás manejar con confianza las redirecciones en cualquier cliente HTTP popular. Podrás predecir qué pasará con el método y el cuerpo de la solicitud. Aprenderás a conservar las cabeceras críticas durante los saltos. Y podrás depurar cadenas complejas de redirecciones que pasan a través de un proxy.

Para quién es esta guía

  • Para desarrolladores que escriben parsers, integraciones y automatizaciones sobre proxies.
  • Para ingenieros de QA que prueban APIs y escenarios web.
  • Para DevOps que configuran el proxy de tráfico.
  • Para todos los que alguna vez se preguntaron por qué POST se convirtió en GET.

Qué necesitas saber de antemano

Comprensión básica del protocolo HTTP: qué es el método de solicitud, las cabeceras, el cuerpo y el código de estado de la respuesta. Saber ejecutar comandos en la terminal. Idealmente, un conocimiento mínimo de algún lenguaje: Python o JavaScript. Si te falta algo de esto, no te preocupes: explicaremos los términos clave en un apartado especial con palabras sencillas.

Cuánto tiempo necesitarás

Para una lectura detallada y la repetición de todos los ejemplos, necesitarás unos 60 minutos. Si solo necesitas resolver un problema concreto, usa el índice y ve directamente a la sección correspondiente.

Preparación previa: herramientas y accesos

Antes de trabajar con los ejemplos, prepara tu entorno de trabajo. Esto tomará unos minutos, pero luego todo irá sobre ruedas.

Herramientas necesarias

  1. Instala curl versión 7.88 o posterior. Verifícalo con el comando curl --version en la terminal.
  2. Instala Python versión 3.10 o posterior. Verifícalo con el comando python --version.
  3. Instala las bibliotecas de Python: ejecuta pip install requests httpx.
  4. Instala Node.js versión 20 o posterior, si planeas probar axios y fetch. Verifícalo con el comando node --version.
  5. Instala axios con npm install axios en la carpeta de pruebas de tu proyecto.

Acceso al proxy

Para practicar, necesitarás proxies Proxeon activos. Prepara los datos de conexión: dirección del servidor, puerto, usuario y contraseña. Tenlos a mano en un lugar seguro. Los iremos usando en los ejemplos de código.

Consejo: Nunca guardes el usuario y la contraseña del proxy directamente en el código. Usa variables de entorno. Por ejemplo, en la terminal define export PROXY_URL=http://user:pass@host:port, y en el código lee ese valor del entorno. Así no enviarás accidentalmente secretos al repositorio.

Requisitos del sistema

Cualquier computadora moderna con Windows 10 o posterior, macOS 12 o posterior, o una distribución Linux actualizada servirá. No hay requisitos especiales de hardware: trabajar con solicitudes HTTP no sobrecarga el sistema.

⚠️ Atención: Si pruebas en un servidor de producción, primero crea una rama de código separada o un script de prueba. No experimentes con la lógica de redirecciones directamente en producción: cambiar el comportamiento de los saltos puede romper la autenticación y hacer que las solicitudes vayan a donde no deben.

✅ Verificación: En esta etapa, los comandos de verificación de versiones de curl, Python y Node.js deben ejecutarse correctamente, y los datos del proxy Proxeon deben estar guardados en una variable de entorno.

Conceptos básicos en palabras sencillas

Para que lo que sigue sea claro, repasemos los términos clave. Aunque los conozcas, no está de más refrescarlos.

Qué es una redirección

Una redirección, o reenvío, es una respuesta del servidor que le dice al cliente: el recurso que buscas no está aquí, ve a otra dirección. El servidor devuelve un código de estado de la familia 3xx y una cabecera Location con la nueva dirección. El cliente lee esa cabecera y envía una nueva solicitud allí.

Qué es el método de solicitud y el cuerpo

El método es el tipo de acción. GET solicita datos, POST envía datos al servidor, PUT actualiza, DELETE elimina. El cuerpo de la solicitud es la carga útil que envías junto con POST o PUT. Por ejemplo, un JSON con usuario y contraseña al autenticarte.

Qué son las cabeceras

Las cabeceras son metadatos de la solicitud. Transmiten información adicional: el formato de los datos (Content-Type), la autorización (Authorization), el agente de usuario (User-Agent), tus propios campos de servicio. En una redirección, parte de las cabeceras puede conservarse y parte puede perderse. Esto es precisamente lo que suele romper la lógica.

Qué es el auto-seguimiento

Auto-seguimiento es cuando tu cliente HTTP, por sí solo y sin tu intervención, sigue la dirección de la cabecera Location. La mayoría de los clientes lo hacen por defecto. Es cómodo, pero peligroso: pierdes el control sobre lo que sucede con el método, el cuerpo y las cabeceras entre pasos.

Cómo encaja el proxy en todo esto

El proxy Proxeon se sitúa entre tu cliente y el servidor de destino. Transmite tu solicitud y devuelve la respuesta. En una redirección, el proxy simplemente reenvía el código de estado y la cabecera Location. La decisión de saltar la toma tu cliente. Un detalle importante: si usas un pool de proxies con rotación, los diferentes pasos de la cadena de redirecciones pueden salir por IPs distintas. Volveremos a esto en un apartado específico.

Consejo: Recuerda esta regla simple: el proxy no cambia el método de la solicitud en una redirección. El método lo cambia tu cliente HTTP según las reglas de procesamiento del código de estado. Por lo tanto, la causa debe buscarse en la configuración del cliente, no en el proxy.

Paso 1: Entendiendo los cuatro códigos: 301 y 302 frente a 307 y 308

Objetivo de esta etapa: aprender a determinar sin error qué pasará con el método y el cuerpo de la solicitud al recibir cada uno de los cuatro códigos de redirección.

Esta es la base de toda la guía. Si asimilas la diferencia entre estos códigos, la mitad de los problemas con las redirecciones desaparecerán por sí solos.

Código 301: redirección permanente

Significa que el recurso se ha movido de forma permanente. Históricamente, al recibir un 301, los clientes cambian el método POST a GET y descartan el cuerpo de la solicitud. Formalmente, la especificación no lo exige, pero así se ha hecho en la práctica y casi todos los clientes lo hacen por compatibilidad con versiones anteriores.

Código 302: redirección temporal

Significa que el recurso está disponible temporalmente en otra dirección. El comportamiento es similar al 301: en la práctica, POST se convierte en GET y el cuerpo se pierde. Este código 302 es el culpable más frecuente de la situación descrita en la introducción.

Código 307: redirección temporal con conservación del método

Este código se introdujo específicamente para resolver el problema del cambio de método. Con el 307, el cliente está obligado a conservar el método y el cuerpo originales. Si enviaste POST, irá POST. Si enviaste un cuerpo, se transmitirá. Es un análogo temporal del 302, pero sin sorpresas con el método.

Código 308: redirección permanente con conservación del método

Es el análogo permanente del 301, pero conservando el método y el cuerpo. Si enviaste POST, llegará POST. Es el código más predecible para redirigir solicitudes POST.

Tabla resumen de comportamiento

A continuación, una descripción verbal de la tabla para que tengas el panorama claro.

  • 301: permanente. El método POST, en la práctica, cambia a GET. El cuerpo se descarta. GET sigue siendo GET.
  • 302: temporal. El método POST, en la práctica, cambia a GET. El cuerpo se descarta. GET sigue siendo GET.
  • 307: temporal. El método se conserva por completo. El cuerpo se conserva. POST sigue siendo POST.
  • 308: permanente. El método se conserva por completo. El cuerpo se conserva. POST sigue siendo POST.

⚠️ Atención: No confíes en que todos los servidores siguen estrictamente la especificación. Algunos sistemas antiguos devuelven 302 donde lógicamente deberían devolver 307, esperando que se conserve el método. Verifica siempre el comportamiento real, no solo el código. Prueba en un endpoint real.

Consejo: Si desarrollas tu propio servidor y quieres que las solicitudes POST sigan siendo POST después de una redirección, usa los códigos 307 o 308. Esto evitará sorpresas desagradables a tus clientes y ahorrará tiempo de depuración.

✅ Verificación: Puedes decir de inmediato, al ver el código de respuesta, si se conservarán el método y el cuerpo. Para 307 y 308, sí. Para 301 y 302, en la práctica, no.

Paso 2: Qué se pierde en el salto: Authorization, cabeceras personalizadas, cookies

Objetivo de esta etapa: entender qué datos desaparecen en una redirección y por qué, para prever su conservación.

El cambio de método no es el único problema. Incluso con los códigos 307 y 308, cuando el método se conserva, parte de las cabeceras puede perderse. Analicemos las tres pérdidas principales.

Pérdida de la cabecera Authorization al cambiar de dominio

Este es el problema más común y más traicionero. Por razones de seguridad, la mayoría de los clientes HTTP eliminan la cabecera Authorization en una redirección a otro dominio. La lógica es simple: si te autenticas en el sitio A, tu token secreto no debe enviarse automáticamente al sitio B, al que te redirigieron. De lo contrario, un atacante podría configurar una redirección y robar tus credenciales.

El resultado: envías una solicitud con un token correcto, el cliente sigue la redirección a otro dominio, pero sin Authorization. El servidor de destino responde que no estás autorizado. Todo es lógico, pero no es obvio.

Consejo: Si realmente necesitas enviar la autorización a otro dominio, hazlo de forma consciente y manual. Desactiva el auto-seguimiento, verifica a dónde lleva exactamente Location, asegúrate de que sea una dirección de confianza y solo entonces agrega la cabecera Authorization a la nueva solicitud con tus propias manos.

Pérdida de cabeceras personalizadas

Tus propias cabeceras, por ejemplo, campos de servicio como X-Request-Id o X-Client-Version, se comportan de manera diferente en cada cliente durante el auto-seguimiento. Algunas bibliotecas las reenvían, otras las eliminan. No puedes confiar en esto. Si la cabecera es crítica para la lógica, controla su transmisión manualmente.

Pérdida de cookies con atributos

Las cookies tienen atributos que restringen su envío. El atributo Secure permite el envío solo a través de conexiones seguras. El atributo Domain limita el conjunto de dominios a los que se envía la cookie. El atributo SameSite regula el envío en los saltos entre sitios. Si la redirección te lleva a un dominio o protocolo que no cumple con los atributos de la cookie, esta cookie simplemente no se enviará.

Por ejemplo, una cookie con el atributo Secure no se enviará si la redirección lleva a una dirección no segura. Una cookie con restricción de dominio no se enviará a un dominio ajeno. Es un comportamiento correcto desde el punto de vista de la seguridad, pero debes tenerlo en cuenta.

⚠️ Atención: Nunca intentes eliminar forzosamente los atributos de seguridad de cookies ajenas ni transmitir Authorization a dominios no confiables por comodidad. Estos mecanismos protegen tus credenciales. Rodéalos solo en infraestructura que controles por completo y con plena comprensión de las consecuencias.

✅ Verificación: Comprendes las tres clases de pérdidas en una redirección: la cabecera Authorization en otro dominio, las cabeceras personalizadas y las cookies con atributos restrictivos. Sabes que cada una solo puede restaurarse con un procesamiento manual consciente.

Paso 3: Comportamiento por defecto en diferentes clientes

Objetivo de esta etapa: conocer cómo se comporta exactamente cada cliente HTTP popular, para no sorprenderte con las diferencias.

La trampa principal es que el comportamiento por defecto de todos los clientes es diferente. Analicemos los cinco más comunes.

curl

Por defecto, curl no sigue las redirecciones en absoluto. Simplemente te mostrará la respuesta con el código 3xx y la cabecera Location. Para activar el auto-seguimiento, necesitas agregar explícitamente la bandera -L. Esto hace que curl sea muy predecible: siempre sabes que sin la bandera no habrá saltos ocultos.

Ejemplo de solicitud sin salto:

curl -i -x $PROXY_URL https://example.com/redirect

La bandera -i mostrará las cabeceras de la respuesta, la bandera -x define el proxy. Verás el código y Location, pero no se producirá ningún salto.

requests (Python)

La biblioteca requests sigue las redirecciones automáticamente por defecto. Además, para los códigos 301, 302 y 303, cambia el método POST a GET. Para 307 y 308, conserva el método. Puedes desactivar el auto-seguimiento con el parámetro allow_redirects=False.

httpx (Python)

Dato interesante: httpx no sigue las redirecciones por defecto, a diferencia de requests. Esto se hizo deliberadamente para que el desarrollador tome una decisión explícita. Para activar los saltos, pasa follow_redirects=True. Este comportamiento está más cerca de la filosofía de curl.

axios (JavaScript, Node.js)

En el entorno Node.js, axios sigue las redirecciones automáticamente por defecto. Puedes limitarlo o desactivarlo con el parámetro maxRedirects. Si defines maxRedirects: 0, el auto-seguimiento se desactiva y axios devolverá un error o una respuesta con el código de redirección, según la configuración.

fetch (navegador y Node.js)

El fetch estándar sigue las redirecciones automáticamente por defecto. Puedes controlarlo con el parámetro redirect, que acepta tres valores: follow para saltar, manual para no saltar y devolver una respuesta opaca, error para considerar la redirección un error.

Consejo: Recuerda los dos grupos. curl y httpx, por defecto, NO saltan: tú decides. requests, axios y fetch saltan por defecto. Si migras código entre estas herramientas, verifica siempre la configuración de redirecciones, o la lógica se romperá silenciosamente.

⚠️ Atención: El comportamiento diferente por defecto es la causa número uno de errores misteriosos al reescribir scripts de un cliente a otro. El script funcionaba con requests, lo migraste a httpx y de repente, en lugar de la respuesta final, recibes un código 302. La causa es que httpx no salta automáticamente. Siempre especifica explícitamente la configuración de redirecciones.

✅ Verificación: Puedes decir de memoria el comportamiento por defecto de curl, requests, httpx, axios y fetch, y conoces el parámetro para controlar las redirecciones en cada uno.

Paso 4: Manejo manual de redirecciones: cuándo es el único camino correcto

Objetivo de esta etapa: aprender a desactivar el auto-seguimiento y procesar cada paso de la redirección manualmente, con control total del método, el cuerpo y las cabeceras.

El auto-seguimiento es cómodo, pero en tres situaciones es perjudicial y se necesita control manual:

  1. Cuando necesitas conservar Authorization al saltar a otro dominio.
  2. Cuando es importante saber exactamente a través de qué proxy e IP fue cada paso de la cadena.
  3. Cuando el servidor responde con 302 donde lógicamente se necesita 307, y quieres conservar manualmente el método POST.

Desactivar el auto-seguimiento: curl

En curl es simple: no agregues la bandera -L. El cliente te mostrará la primera respuesta. Luego, tú mismo tomas Location y haces una nueva solicitud:

curl -i -x $PROXY_URL "https://example.com/login"

Lee la cabecera Location de la salida y luego ejecuta la siguiente solicitud manualmente, agregando las cabeceras necesarias:

curl -i -x $PROXY_URL -H "Authorization: Bearer TOKEN" "https://example.com/next"

Desactivar el auto-seguimiento: requests

Aquí usamos el parámetro allow_redirects=False y procesamos la cadena en un bucle:

import os, requests; proxies = {"http": os.environ["PROXY_URL"], "https": os.environ["PROXY_URL"]}; url = "https://example.com/login"; method = "POST"; body = {"user": "a", "pass": "b"}; headers = {"Authorization": "Bearer TOKEN"}; 
for _ in range(5): 
r = requests.request(method, url, json=body, headers=headers, proxies=proxies, allow_redirects=False); 
if r.status_code not in (301, 302, 303, 307, 308): break; 
loc = r.headers["Location"]; 
if r.status_code in (301, 302, 303): method = "GET"; body = None; 
url = loc

Observa: en este bucle, tú decides si cambiar el método o no, y tú decides si conservar la cabecera Authorization. Ahí está la fuerza del manejo manual.

Desactivar el auto-seguimiento: httpx

Como httpx no salta por defecto, basta con no activar follow_redirects. La lógica del bucle es análoga a requests: verificas el código, lees Location, tomas decisiones sobre el método y las cabeceras, y haces la siguiente solicitud.

Desactivar el auto-seguimiento: axios

En axios, define maxRedirects: 0. Al recibir el código de redirección, axios en Node.js lanzará un error, en cuyo objeto response tendrás acceso al estado y a las cabeceras. De la cabecera Location tomas la nueva dirección y formas la siguiente solicitud tú mismo.

Desactivar el auto-seguimiento: fetch

En fetch, pasa redirect: "manual". Entonces fetch no saltará y devolverá una respuesta de la que podrás leer los datos necesarios para el siguiente paso.

Consejo: En el manejo manual, registra siempre en cada paso cuatro cosas: la URL original, el código recibido, el valor de Location y el método de la siguiente solicitud. Esto convertirá una cadena incomprensible en una secuencia transparente, fácil de leer y depurar.

⚠️ Atención: En el manejo manual, tú eres responsable de la seguridad. Antes de transferir Authorization a una nueva dirección de Location, verifica que el dominio pertenezca a una infraestructura de confianza. Copiar secretos a ciegas a cualquier dirección de Location es una vulnerabilidad grave.

✅ Verificación: Tienes un bucle de manejo manual funcional en al menos un cliente que recorre correctamente una cadena de redirecciones y conserva las cabeceras necesarias solo para dominios de confianza.

Paso 5: Límite de profundidad y protección contra bucles

Objetivo de esta etapa: proteger tu código contra redirecciones infinitas y evitar que el bucle de saltos cuelgue la aplicación.

A veces los servidores están mal configurados y la dirección A lleva a la B, y la B lleva de vuelta a la A. Si tu cliente salta sin límites, entrará en un bucle. En el manejo manual ocurre lo mismo: un bucle sin contador girará para siempre.

Límite del número de saltos

Define siempre una profundidad máxima. Un valor razonable es de cinco a diez saltos. Más, en escenarios normales, casi no se encuentra.

  • En curl: la bandera --max-redirs 10 junto con -L.
  • En requests: la biblioteca limita sola la profundidad, pero en un bucle manual usa range(10).
  • En httpx: el parámetro max_redirects con los saltos activados.
  • En axios: el parámetro maxRedirects con el número deseado.
  • En fetch: en el manejo manual, cuenta los saltos tú mismo en el bucle.

Protección contra bucles mediante el seguimiento de direcciones visitadas

Un truco fiable: guarda un conjunto de URLs ya visitadas. Antes de cada salto, verifica si ya has estado en esa dirección. Si es así, interrumpe la cadena con un error. Esto detecta incluso bucles complejos de varias direcciones.

seen = set(); 
while url and url not in seen: 
seen.add(url); 
r = requests.request(method, url, headers=headers, proxies=proxies, allow_redirects=False); 
if r.status_code not in (301,302,303,307,308): break; 
url = r.headers["Location"]

Consejo: Combina ambas técnicas: el límite duro de cantidad y el conjunto de direcciones visitadas. El límite protege contra cadenas largas, el conjunto contra bucles. Juntos ofrecen una protección completa.

✅ Verificación: Tu código termina garantizado en cualquier cadena de redirecciones, incluso si el servidor crea un bucle infinito. O llega a la respuesta final o se interrumpe con un error claro sobre el límite de profundidad o la detección de un bucle.

Paso 6: Redirecciones y cambio de IP: por qué la cadena sale por otro proxy

Objetivo de esta etapa: entender cómo interactúa la rotación de proxies con las redirecciones y evitar que los pasos de la cadena salgan por IPs diferentes.

Este es un punto sutil y a menudo subestimado. Si usas un pool de proxies Proxeon con rotación de IP, es importante entender a qué nivel ocurre el cambio de dirección.

Por qué los pasos pueden salir por IPs diferentes

Imagina que tu rotación está configurada para cambiar de IP en cada nueva conexión. En el auto-seguimiento, el cliente puede abrir una nueva conexión para el siguiente paso de la redirección. Si entre pasos la rotación asigna una nueva IP, la primera solicitud saldrá desde una dirección y el salto por Location desde otra. Para muchos servidores, esto parece sospechoso: la autenticación la empezó un cliente y la continuó otro.

Qué se rompe con esto

  • Las sesiones vinculadas a la IP se interrumpen. El servidor ve que la continuación llegó desde otra dirección y restablece la sesión.
  • Las cookies emitidas para una sesión concreta dejan de aceptarse.
  • La lógica que espera una única fuente dentro de la cadena comienza a comportarse de forma inestable.

Cómo mantener una sola sesión en una sola IP

La clave está en fijar la IP durante toda la cadena. Proxeon admite el modo de sesión persistente, donde la misma IP se mantiene durante un período determinado. Úsalo para escenarios donde la integridad de la cadena de redirecciones es importante.

  1. Elige en la configuración de conexión el modo de sesión persistente en lugar de la rotación por solicitud.
  2. Define un tiempo de retención de IP con margen para toda la cadena de saltos.
  3. En el código, usa una sola sesión de cliente para todos los pasos: en requests es el objeto requests.Session(), en httpx es httpx.Client().
  4. Asegúrate de reutilizar la conexión y no crear una nueva en cada paso.

Consejo: Para la integridad de una cadena de redirecciones, crea siempre un único objeto de sesión de cliente y ejecuta todos los pasos a través de él. Esto reutiliza la conexión, conserva las cookies entre solicitudes y reduce la probabilidad de cambiar de IP a mitad de la cadena.

⚠️ Atención: No confundas la sesión persistente con la retención infinita de IP. Define un tiempo de retención razonable, justo para la duración de la operación. Recuerda que todo el trabajo con el proxy debe realizarse dentro del marco legal y de las reglas de los recursos con los que interactúas.

✅ Verificación: Toda la cadena de redirecciones pasa por la misma IP, la sesión no se interrumpe y las cookies se aceptan en cada paso. Puedes verificarlo consultando en cada paso un servicio que muestre tu IP actual y confirmando que no cambia.

Paso 7: Depuración: cómo ver toda la cadena y los códigos paso a paso

Objetivo de esta etapa: obtener una imagen completa de la cadena de redirecciones para saber exactamente dónde se pierde el método o la cabecera.

Depurar a ciegas es lo peor que se puede hacer con las redirecciones. A continuación, las herramientas que hacen visible la cadena.

Registro completo en curl

La bandera -v activa el modo detallado. Verás cada solicitud, cada respuesta, todas las cabeceras y todos los saltos. Con la bandera -L, curl mostrará toda la cadena completa.

curl -v -L --max-redirs 10 -x $PROXY_URL "https://example.com/login"

Lee la salida de arriba a abajo. Las líneas que comienzan con el símbolo mayor son lo que va al servidor. Las líneas con el símbolo menor son lo que llega como respuesta. Así verás en qué paso desapareció la cabecera.

Historial de redirecciones en requests

Si dejas el auto-seguimiento activado, la respuesta final tendrá el atributo history: una lista de todas las respuestas intermedias. Recórrela y muestra el código y la URL de cada paso:

r = requests.post(url, json=body, proxies=proxies); 
for h in r.history: print(h.status_code, h.url); 
print("final", r.status_code, r.url)

Historial de redirecciones en httpx

Con follow_redirects activado, la respuesta de httpx también tiene la propiedad history. La lógica es la misma: recorres e imprimes el código y la URL de cada respuesta intermedia.

Depuración de axios y fetch

En axios, con el manejo manual, registra cada respuesta en el bucle tú mismo. En fetch con modo manual, imprime el estado y la cabecera Location en cada paso. No hay una lista integrada de historial aquí, así que el registro manual es tu herramienta principal.

Consejo: Establece un formato único de línea de registro para un paso: número de paso, método, URL, código de respuesta, Location, presencia de Authorization. Ese registro tabular muestra al instante dónde exactamente el método cambió a GET o desapareció el token. Esto ahorra horas de depuración.

Qué buscar en los registros

  • El momento en que el método en la solicitud saliente se convirtió en GET en lugar de POST. Es señal de un código 301, 302 o 303.
  • El paso donde desapareció la cabecera Authorization. Normalmente es un salto a otro dominio.
  • El cambio de dominio o protocolo en el valor de Location: ahí es donde se pierden las cookies con atributos.
  • Direcciones repetidas: señal de un bucle.

✅ Verificación: Puedes mostrar la cadena completa de saltos con códigos y URLs para cualquier cliente, e indicar con precisión el paso donde cambió el método o desapareció la cabecera.

Verificación del resultado: lista de verificación

Repasa esta lista. Si todos los puntos están cumplidos, controlas completamente las redirecciones.

  1. Conoces el comportamiento del método y del cuerpo para los códigos 301, 302, 307 y 308.
  2. Entiendes por qué Authorization desaparece al cambiar de dominio.
  3. Conoces el comportamiento por defecto de curl, requests, httpx, axios y fetch.
  4. Tienes un ejemplo funcional para desactivar el auto-seguimiento.
  5. Tienes un bucle funcional de manejo manual de la cadena.
  6. Tu código está protegido contra bucles infinitos con un límite y un conjunto de direcciones visitadas.
  7. Usas la sesión persistente de Proxeon para la integridad de la cadena donde sea necesario.
  8. Sabes mostrar la cadena completa de saltos en los registros.

Cómo probar

Toma un endpoint de prueba que responda con el código 302 a una solicitud POST. Ejecútalo con auto-seguimiento y verifica que el método se convierta en GET. Luego ejecútalo con manejo manual conservando el método y verifica que POST llegue a la dirección final. La diferencia de comportamiento será la prueba de que controlas todo.

✅ Verificación: Ambos escenarios (auto-seguimiento y manejo manual) dan un resultado predecible y explicable, no aleatorio.

Errores típicos y soluciones

Analicemos los problemas más comunes y cómo evitarlos.

Error 1: POST se convirtió en GET

Causa: el servidor devolvió un código 301 o 302, y el cliente, por la regla histórica, cambió el método. Solución: si controlas el servidor, devuelve 307 o 308. Si no, desactiva el auto-seguimiento y repite la solicitud con el método necesario manualmente.

Error 2: desapareció la cabecera Authorization

Causa: la redirección llevó a otro dominio y el cliente eliminó el secreto por razones de seguridad. Solución: verifica el dominio de Location y, si es de confianza, agrega Authorization a la siguiente solicitud manualmente.

Error 3: el script funcionaba con requests pero se rompió con httpx

Causa: httpx no salta por defecto, mientras que requests sí. Solución: define explícitamente follow_redirects=True en httpx, o pasa a manejo manual en todos lados para uniformidad.

Error 4: la aplicación se colgó en una cadena

Causa: bucle infinito de redirecciones sin límite de profundidad. Solución: agrega un límite de saltos y un conjunto de direcciones visitadas, como se muestra en el paso 5.

Error 5: la sesión se interrumpe a mitad de la cadena

Causa: los pasos de la cadena salieron por IPs diferentes debido a la rotación del proxy. Solución: activa la sesión persistente de Proxeon y usa un único objeto de sesión de cliente para todos los pasos.

Error 6: la cookie no se envía después de la redirección

Causa: los atributos Secure, Domain o SameSite no coinciden con la nueva dirección. Solución: verifica el protocolo y el dominio en Location y asegúrate de que cumplan con los atributos de la cookie. No elimines los atributos de seguridad por comodidad.

Error 7: curl no sigue la redirección

Causa: olvidaste la bandera -L. Solución: agrega -L para el auto-seguimiento o déjala sin ella para el control manual, según la tarea.

Oportunidades adicionales y optimización

Una vez dominada la base, vale la pena poner orden y aumentar la fiabilidad.

Módulo único de procesamiento de redirecciones

No disperses la lógica por el código. Reúne el procesamiento de la cadena en una sola función con parámetros: lista de dominios de confianza, profundidad máxima, conjunto de códigos para conservar el método. Así el comportamiento será uniforme en todo el proyecto.

Lista blanca de dominios para Authorization

Crea una lista explícita de dominios a los que se permite transmitir Authorization en una redirección. Todo lo que esté fuera de la lista nunca recibirá el secreto. Esto hace que la seguridad sea gestionable, no accidental.

Métricas de cadenas

Recopila estadísticas: longitud media de la cadena, proporción de solicitudes con redirecciones, códigos que aparecen con más frecuencia. Un crecimiento anómalo de la longitud de las cadenas es una señal temprana de problemas en el servidor de destino.

Consejo: Configura una alerta si la cadena supera los tres saltos. En la mayoría de los escenarios correctos, bastan uno o dos. Un aumento brusco es motivo para investigar qué cambió en el recurso de destino.

FAQ: preguntas frecuentes sobre el manejo de redirecciones

¿Por qué POST se convierte en GET si yo no cambié nada?

Porque el servidor devolvió un código 301 o 302, y tu cliente, por la regla histórica, cambió el método a GET. Para evitarlo, necesitas el código 307 o 308, o manejo manual.

¿El proxy cambia el método de la solicitud en una redirección?

No. Proxeon y cualquier proxy correcto solo reenvían el estado y Location. La decisión de cambiar el método la toma tu cliente HTTP. La causa debe buscarse en la configuración del cliente.

¿Cómo conservo Authorization al saltar a otro dominio?

Solo manualmente. Desactiva el auto-seguimiento, verifica el dominio de Location, asegúrate de que sea de confianza y agrega la cabecera Authorization a la siguiente solicitud tú mismo.

¿Qué código es mejor usar para redirigir POST?

El código 307 para redirección temporal y 308 para permanente. Ambos conservan el método y el cuerpo de la solicitud, evitando sorpresas a los clientes.

¿Por qué el mismo script se comporta diferente en requests y httpx?

Porque requests salta por defecto y httpx no. Define explícitamente la configuración de saltos para que el comportamiento coincida.

¿Cómo me protejo de un bucle infinito de redirecciones?

Define un límite duro de saltos y lleva un conjunto de direcciones ya visitadas. Si la dirección se repite o se supera el límite, interrumpe la cadena con un error.

¿Por qué la sesión se rompe a mitad de la cadena de redirecciones?

Probablemente los pasos salieron por IPs diferentes debido a la rotación. Activa la sesión persistente de Proxeon y usa un único objeto de sesión de cliente para todos los pasos.

¿Por qué la cookie no se envía después del salto?

Porque los atributos Secure, Domain o SameSite no coinciden con la nueva dirección. Verifica el protocolo y el dominio en Location. No puedes eliminar los atributos de seguridad.

¿Cómo veo toda la cadena de saltos?

En curl, usa -v -L. En requests y httpx, mira el atributo history de la respuesta final. En axios y fetch, registra cada paso manualmente.

¿Puedo prohibir completamente las redirecciones?

Sí. En curl, no agregues -L; en requests, define allow_redirects=False; en httpx, no actives follow_redirects; en axios, pon maxRedirects: 0; en fetch, indica redirect: "manual".

Conclusión

Ahora tienes una imagen completa y práctica del trabajo con redirecciones a través de un proxy. Entendiste por qué POST se convierte en GET y sabes que la culpa no es del proxy, sino de las reglas históricas de procesamiento de los códigos 301 y 302. Comprendes la diferencia entre 301, 302, 307 y 308, y sabes elegir el código correcto. Sabes qué datos se pierden en el salto: Authorization en otro dominio, cabeceras personalizadas y cookies con atributos de seguridad.

Estudiaste el comportamiento por defecto de curl, requests, httpx, axios y fetch, y ya no te sorprenderán las diferencias al migrar código. Tienes ejemplos prácticos para desactivar el auto-seguimiento y procesar manualmente la cadena con control total del método y las cabeceras. Sabes protegerte contra bucles y mantener una sola sesión en una sola IP mediante la sesión persistente de Proxeon. Y, por último, sabes depurar cadenas y ver cada paso.

¿Qué hacer ahora? Crea un módulo único de procesamiento de redirecciones con una lista blanca de dominios para Authorization y profundidad configurable. Agrega métricas de longitud de cadenas. Ejecuta tus escenarios reales con manejo manual y compáralos con el auto-seguimiento: así encontrarás los lugares ocultos donde se perdían datos.

Sigue avanzando en el estudio de la pila de red: profundiza en el ciclo de vida de las cookies, en los detalles de las conexiones TLS y en la reutilización de conexiones. Cada una de estas habilidades hará tu trabajo con el proxy Proxeon aún más fiable y predecible. ¡Buena suerte en tu trabajo de ingeniería y que tengas cadenas de solicitudes limpias y transparentes!