Contenido del artículo

La frase "el proxy no funciona" para un ingeniero de soporte suena más o menos como "me duele algo por dentro" para un médico. La dirección es clara, pero sin análisis ni síntomas no se puede dar un diagnóstico. En esta guía aprenderás a recopilar exactamente el conjunto de datos que convierte una queja difusa en una tarea concreta con una única respuesta clara.

Introducción: por qué "no funciona" es imposible de diagnosticar

Imagina dos solicitudes al soporte de Proxeon. La primera: "Compré un proxy, no funciona nada, ayúdenme". La segunda: "El proxy con identificador PX-48213 a las 14:32 MSK (UTC+3) devuelve un error de conexión al solicitar api.example.com vía HTTP, mientras que con otro sitio el mismo proxy sí funciona, la conexión directa sin proxy también funciona, adjunto la salida de curl". La primera solicitud desencadena una cadena de cinco o seis correos de aclaración, cada uno con horas de espera. La segunda se cierra con una sola respuesta.

La diferencia no está en la cortesía ni en la suerte. La diferencia está en los datos. El ingeniero no ve tu pantalla, no conoce tu sistema operativo, no puede reproducir tu solicitud sin los parámetros de origen. Todo lo que tiene es el texto de tu correo. Si en ese texto no hay hechos, lo primero que hará será pedir hechos. Esa es precisamente la cadena de correos que alarga la solución de un problema simple a varios días.

Qué obtendrá el lector al final

Después de esta guía podrás recopilar en 15-20 minutos un paquete de diagnóstico que contiene todo lo necesario para resolver el problema en la primera respuesta. Tendrás un script listo que recopila los datos técnicos en un solo archivo de texto, una plantilla de solicitud para copiar y una comprensión clara de qué verificaciones debes realizar antes de escribir al soporte.

Para quién es esta guía

La guía está pensada para usuarios de proxy de nivel intermedio: aquellos que saben abrir un terminal o una línea de comandos, entienden qué es una URL y han configurado un proxy en alguna aplicación al menos una vez. Los usuarios avanzados encontrarán aquí un script de diagnóstico listo y una tabla de aislamiento del problema. A los principiantes les explicaremos cada término con detalle.

Qué necesitas saber de antemano

Basta con entender tres cosas. Proxy: es un intermediario por el que pasa tu solicitud de red. Dirección de destino: el sitio o servicio al que te diriges. Cliente: el programa que realiza la solicitud a través del proxy (navegador, parser, script). Todo lo demás lo iremos viendo sobre la marcha.

Cuánto tiempo tomará

La primera pasada por la guía con la configuración del script tomará unos 30 minutos. Después, recopilar el diagnóstico con la plantilla lista tomará 10-15 minutos. Esto es incomparablemente menos que varios días de correspondencia con aclaraciones.

Consejo: guarda esta guía y el script en marcadores. Los problemas con el proxy surgen rara vez, y cuando aparecen, es difícil recordar todo el procedimiento. Una lista de verificación a mano ahorra nervios.

Preparación previa: herramientas y accesos

Antes de recopilar datos, asegúrate de tener las herramientas básicas. Todas son gratuitas y en la mayoría de los sistemas ya están instaladas.

Herramientas necesarias

  • curl: utilidad de línea de comandos para enviar solicitudes de red. Es nuestra herramienta principal para reproducir el problema. En macOS y la mayoría de distribuciones de Linux viene preinstalada. En Windows 10 y 11 también forma parte del sistema.
  • Terminal o línea de comandos: la ventana donde ingresas comandos. En Windows es PowerShell o la línea de comandos (cmd), en macOS y Linux es Terminal.
  • Editor de texto: Bloc de notas, TextEdit o cualquier otro para ver el archivo recopilado y eliminar secretos.
  • Datos de tu proxy de Proxeon: identificador, dirección, puerto, usuario y contraseña. Te los entregaron en tu panel de control.

Verificar la disponibilidad de curl

Abre el terminal y ejecuta una verificación sencilla.

  1. En Windows presiona la tecla Win, escribe PowerShell y abre la aplicación.
  2. En macOS abre Spotlight con Cmd+Espacio, escribe Terminal y presiona Enter.
  3. En Linux abre el terminal desde el menú de aplicaciones o con Ctrl+Alt+T.
  4. Ingresa el comando 
    curl --version
    y presiona Enter.

Si ves una línea como "curl 8.x.x" con una lista de protocolos compatibles, la herramienta está lista. Si el sistema indica que el comando no se encuentra, instala curl: en Windows actualiza el sistema a la versión más reciente, en Linux realiza la instalación a través del gestor de paquetes de tu distribución.

✅ Verificación: el comando 

curl --version
mostró el número de versión y la lista de protocolos, incluyendo http y https. Entonces todo está listo para trabajar.

Qué preparar de los datos de Proxeon

Entra al panel de control de Proxeon en proxeon.net y abre la tarjeta de tu proxy. Anota o copia en un archivo aparte los siguientes campos: identificador del proxy, host (dirección), puerto, tipo (HTTP, HTTPS o SOCKS5), usuario y contraseña. Estos datos serán necesarios para formar el comando de reproducción.

⚠️ Atención: el usuario y la contraseña del proxy son datos secretos. Trabajaremos con ellos de forma local, pero NO debes incluirlos en la solicitud al soporte. Más abajo hay una sección aparte sobre cómo limpiar los logs de forma segura antes de enviarlos.

Conceptos básicos: la frontera cliente — proxy — servidor

Para entender qué datos son importantes, hay que imaginar el recorrido de la solicitud. Pasa por tres tramos, y el problema puede surgir en cualquiera de ellos.

Tres eslabones de una misma cadena

Cuando te diriges a un sitio a través de un proxy, la solicitud va así: tu cliente envía la solicitud al servidor proxy, este la redirige al servidor de destino, recibe la respuesta y te la devuelve. Tres eslabones, dos fronteras. Entender en qué frontera se atascó es la mitad del diagnóstico.

  • Frontera cliente — proxy. Si la solicitud ni siquiera llegó al proxy, el problema está de tu lado: dirección de proxy incorrecta, puerto cerrado, filtro corporativo, error en la configuración del cliente.
  • Frontera proxy — servidor. Si el proxy recibió la solicitud pero no pudo llegar al sitio de destino, el problema está entre el proxy y el objetivo: el sitio no está disponible, rechaza la conexión o responde con error.

La tarea del diagnóstico es determinar en qué frontera se rompió todo. El ingeniero de soporte de Proxeon verá de inmediato por tu salida dónde se detuvo la solicitud, y eso reducirá drásticamente el círculo de causas.

Por qué la hora exacta es tan importante

La infraestructura de proxy mantiene logs. Para encontrar tu solicitud concreta en ellos, el ingeniero necesita la hora exacta del evento con indicación de la zona horaria. "Hoy en la mañana" no se busca en los logs. "14:32 MSK, UTC+3" se busca en segundos. La diferencia de hora entre tu formulación y el registro en el log es una causa frecuente de que el evento ni siquiera se encuentre.

Consejo: indica siempre la zona horaria de forma explícita. El formato "UTC+3" o "MSK" se entiende sin suposiciones. Si estás en otra zona, indica la tuya; el servidor hará la conversión.

Paso 1: Recopilar el conjunto mínimo de datos

Objetivo de la etapa: fijar cinco hechos sin los cuales cualquier solicitud quedará incompleta. Es la base sobre la que se construye todo lo demás.

Cinco hechos obligatorios

  1. Identificador del proxy. El nombre o número exacto del panel de control de Proxeon, por ejemplo PX-48213. No "el proxy que compré ayer", sino un identificador concreto. Si tienes un paquete de varios proxies, indica de cuál se trata.
  2. Hora exacta con zona horaria. Cuándo surgió exactamente el problema. Formato: fecha, hora, zona. Por ejemplo: 12 de marzo de 2026, 14:32, UTC+3. Si el problema se repite, indica varias marcas de tiempo.
  3. Dirección de destino. La URL o el host completo al que te dirigiste. Por ejemplo: https://api.example.com/v2/data. No "un sitio", sino la dirección exacta.
  4. Qué hiciste exactamente. Una o dos frases sobre la acción. "Envié una solicitud GET desde mi script" o "abrí el sitio en el navegador con el proxy configurado". El contexto ayuda a entender la naturaleza de la solicitud.
  5. Qué esperabas y qué obtuviste. Esperabas el código 200 y datos, obtuviste un error de conexión. Esperabas que la página cargara, obtuviste una carga infinita. La diferencia entre la expectativa y la realidad es la esencia del problema.

⚠️ Atención: no sustituyas lo concreto por emociones. "Todo va lento y es horrible" no aporta información técnica. "La respuesta llega en 40 segundos en lugar de los 2 habituales" sí la aporta.

Cómo fijar la hora correctamente

Si el problema ocurre ahora mismo, mira el reloj y anota la hora de inmediato. Si fue en el pasado, reconstruye la hora a partir de los logs de tu aplicación o del historial del navegador. Cuanto más precisa sea la marca, más rápido se encontrará el registro del lado del servidor.

✅ Verificación: tienes cinco hechos anotados. Léelos en voz alta. Si una persona que no ve tu pantalla entiende qué ocurrió, dónde y cuándo, el conjunto mínimo está recopilado.

Paso 2: Reproducir el problema con un solo comando curl

Objetivo de la etapa: reducir el problema a un único comando que el ingeniero pueda repetir mentalmente o literalmente, y obtener una salida técnica detallada.

El navegador y un script complejo realizan decenas de acciones ocultas. Aislar el problema en ellos es difícil. La utilidad curl hace exactamente una solicitud y muestra cada una de sus etapas. Es la herramienta ideal de reproducción.

Comando básico a través del proxy de Proxeon

Arma el comando con tus datos. La forma general es así:

curl -v -x http://ЛОГИН:ПАРОЛЬ@ХОСТ:ПОРТ https://ЦЕЛЕВОЙ-АДРЕС

Analicemos las banderas. -v activa el modo detallado (verbose): curl mostrará todo el recorrido de la conexión línea por línea. -x especifica el proxy a través del cual va la solicitud. Después va la dirección del proxy con autorización. Al final, la dirección de destino.

Ejemplo con valores sustituidos (datos ficticios):

curl -v -x http://user123:secretpass@proxy.proxeon.net:8080 https://api.example.com/v2/data

Agregamos medición de tiempo y escritura en archivo

Para que la salida sea lo más informativa posible, ampliemos el comando. La bandera -w agregará un resumen de tiempos al final.

curl -v -x http://user123:secretpass@proxy.proxeon.net:8080 -w "Итоговый код: %{http_code}, общее время: %{time_total}s" https://api.example.com/v2/data

Ahora, al final de la salida, verás el código HTTP final y el tiempo total de la solicitud. Son las cifras clave para diagnosticar la velocidad.

Consejo: si el problema es la lentitud y no un error, agrega tiempos detallados con 

-w "dns: %{time_namelookup} connect: %{time_connect} start: %{time_starttransfer} total: %{time_total}"
Esto mostrará en qué etapa se pierde el tiempo.

Para proxy SOCKS5

Si tu proxy es de tipo SOCKS5, cambia el esquema en la dirección:

curl -v -x socks5://user123:secretpass@proxy.proxeon.net:1080 https://api.example.com/v2/data

⚠️ Atención: el comando contiene tu usuario y contraseña reales. Ejecútalo en tu terminal, pero NO copies el comando con los secretos en el correo. En la solicitud, el usuario y la contraseña se reemplazan por marcadores: sobre esto trata el paso 5.

Orden de ejecución

  1. Abre el terminal.
  2. Pega el comando armado, sustituyendo tus datos reales.
  3. Presiona Enter y espera a que termine.
  4. Selecciona toda la salida desde la primera hasta la última línea y cópiala en un archivo de texto.

✅ Verificación: obtuviste una salida de varias líneas donde se ven líneas que comienzan con los símbolos "*", ">" y "<". Si hay salida, la reproducción fue exitosa, incluso si la solicitud terminó con error; el error también es información valiosa.

Paso 3: Leer la salida línea por línea y encontrar la frontera del problema

Objetivo de la etapa: aprender a entender qué muestra la salida de curl y determinar en qué eslabón se detuvo la solicitud. La decodificación de códigos de error concretos no la duplicamos aquí: para eso hay un artículo aparte en la base de conocimientos de Proxeon; enlázalo en la solicitud si es necesario.

Tres tipos de líneas en la salida

La salida detallada de curl usa prefijos con los que es fácil orientarse.

  • Líneas con asterisco (*): mensajes de servicio del propio curl sobre el recorrido de la conexión: resolución de nombre, establecimiento de enlace con el proxy, handshake de cifrado. Es la cocina interna.
  • Líneas con flecha a la derecha (>): es lo que tu cliente ENVÍA. Encabezados de solicitud, método, ruta.
  • Líneas con flecha a la izquierda (<): es lo que te RESPONDEN. Código de respuesta, encabezados del servidor.

Dónde pasa la frontera cliente — proxy

Al inicio de la salida, curl informa que establece conexión con el proxy. Verás una línea como "Connected to proxy.proxeon.net port 8080". Si esa línea no está y en su lugar hay un error de conexión, significa que la solicitud no llegó al proxy. El problema está en la frontera cliente — proxy: quizá el puerto está cerrado, la dirección es incorrecta o hay un filtro local interfiriendo.

Si la línea de conexión al proxy está, pero después hay un error de autorización, significa que el proxy está disponible pero no aceptó tu usuario y contraseña. También es la frontera cliente — proxy, pero ya a nivel de autenticación.

Dónde pasa la frontera proxy — servidor

Tras la conexión exitosa al proxy, curl muestra el establecimiento de la conexión con el servidor de destino a través del proxy. Si aquí surge un error, significa que el proxy recibió la solicitud pero no pudo llegar al objetivo. El problema está en la frontera proxy — servidor: el sitio de destino no está disponible, rechaza la conexión o responde lentamente.

Si ves una línea de respuesta con flecha a la izquierda, por ejemplo "< HTTP/1.1 200" u otro código, significa que toda la cadena funcionó y recibiste una respuesta. Después ya es cuestión del contenido de la respuesta, no del funcionamiento del proxy.

Líneas clave que le importan al ingeniero

  1. La línea de conexión al proxy: confirma que el primer eslabón funciona.
  2. La línea sobre la autorización en el proxy: muestra si se aceptaron las credenciales.
  3. La línea sobre el handshake de cifrado (TLS): importante para destinos HTTPS.
  4. La primera línea de respuesta con flecha a la izquierda: el veredicto final de la cadena.
  5. El resumen final con código y tiempo de la bandera -w.

Consejo: no intentes dar un diagnóstico por tu cuenta basándote en el código de error si no estás seguro. Tu tarea es adjuntar la salida completa. El ingeniero de Proxeon la leerá con más precisión. La decodificación completa de códigos está en un artículo aparte de la base de conocimientos; enlázalo si quieres profundizar.

✅ Verificación: puedes señalar con el dedo la línea tras la cual se rompió la solicitud y decir en qué frontera está: cliente-proxy o proxy-servidor. Si puedes, has superado esta etapa.

Paso 4: Realizar verificaciones antes de contactar al soporte

Objetivo de la etapa: por eliminación, reducir el círculo de causas antes de escribir al soporte. Cada verificación descarta toda una clase de problemas.

El principio es simple: cambiamos un parámetro a la vez y observamos si el comportamiento cambió. Es el enfoque clásico de ingeniería para aislar una falla.

Cuatro verificaciones clave

  1. Otro sitio de destino. Repite la misma solicitud a través del mismo proxy, pero hacia otra dirección. Toma un sitio público que sea estable. Si el proxy funciona hacia él pero no hacia tu objetivo, el problema está relacionado con el sitio de destino o su relación con el proxy, no con el proxy en sí.
  2. Otro protocolo. Si usaste HTTP, prueba un destino HTTPS, y viceversa. A veces el problema se manifiesta solo en un protocolo, y es una señal importante.
  3. Otro proxy. Si tienes un segundo proxy de Proxeon, repite la solicitud a través de él. Si el segundo funciona y el primero no, el problema está en el proxy concreto. Si ambos se comportan igual, el problema es más sistémico.
  4. Conexión directa. Realiza la solicitud al objetivo SIN proxy, directamente. Quita la bandera -x. Si directamente el sitio tampoco está disponible, el problema no es del proxy en absoluto, sino del propio sitio de destino o de tu red.

Comando para la verificación directa

curl -v https://api.example.com/v2/data

El mismo comando, pero sin la parte del proxy. Compara el resultado con la solicitud a través del proxy.

Tabla: qué descarta cada verificación

Abajo, cómo interpretar los resultados de las verificaciones.

  • Otro sitio funciona, el tuyo no. Descarta una avería general del proxy. Indica la especificidad de la interacción del objetivo concreto con el proxy.
  • Otro protocolo funciona, el tuyo no. Descarta la indisponibilidad total. Localiza el problema a nivel de un protocolo o puerto concreto.
  • Otro proxy funciona, el tuyo no. Descarta un problema de tu lado y de la red. Indica el proxy concreto.
  • La conexión directa tampoco funciona. Descarta la culpa del proxy. El problema está en el sitio de destino o en tu red.
  • La conexión directa funciona, a través del proxy no. Confirma que se trata precisamente de la combinación con el proxy, y esto es justo con lo que ayudará el soporte.

Consejo: los resultados de estas cuatro verificaciones son la parte más valiosa de la solicitud. Le ahorran al ingeniero la mitad del trabajo, porque ya descartaste lo innecesario. Enuméralos obligatoriamente en el correo.

⚠️ Atención: usa estos proxies exclusivamente para tareas legales: probar tus propios servicios, recopilar datos públicos dentro de las reglas, trabajar con API. Las verificaciones no están destinadas a acciones que violen las reglas de los sitios o la legislación.

✅ Verificación: tienes los resultados de las cuatro verificaciones y puedes decir en una frase qué descartan en conjunto. Por ejemplo: "la conexión directa y otro proxy funcionan, así que el problema está en el proxy concreto PX-48213 al dirigirse a este objetivo".

Paso 5: Recopilar datos sobre tu lado

Objetivo de la etapa: describir el entorno en el que surge el problema. La mitad de los casos incomprensibles se explican por particularidades del cliente o de la red local.

Qué indicar sobre el entorno

  1. Sistema operativo y su versión. Windows 11, macOS 15, Ubuntu 24.04. La versión exacta ayuda a reproducir las condiciones.
  2. Cliente y su versión. Con qué trabajas el proxy: navegador y su versión, nombre y versión del parser o la biblioteca, versión de curl. Distintos clientes procesan el proxy de forma diferente.
  3. Método de configuración del proxy. Configurado en el sistema, en el navegador, pasado en el código, definido en variables de entorno. Esto influye en cómo se aplica exactamente el proxy.
  4. Presencia de filtro corporativo o local. Si trabajas desde una red corporativa, si hay antivirus con firewall, si hay un firewall local. Tales filtros pueden interceptar o bloquear conexiones incluso antes del proxy.
  5. Tipo de conexión a internet. Proveedor doméstico, internet móvil, red de trabajo. A veces el proveedor influye en la disponibilidad.

Cómo averiguar la versión del cliente

Para curl usa el ya conocido comando 

curl --version
Para el navegador, abre la sección "Acerca de" en el menú. Para la biblioteca en el código, mira su versión en el archivo de dependencias de tu proyecto.

Verificación del filtro corporativo

Si estás en una red corporativa y sospechas de un filtro, es fácil comprobarlo. Realiza una solicitud directa al proxy sin objetivo y observa si se establece la conexión. Si incluso la conexión directa al puerto del proxy no pasa, pero desde otra red sí pasa, es probable un filtro corporativo en las conexiones salientes.

Consejo: las redes corporativas a menudo permiten solo los puertos 80 y 443. Si tu proxy está en un puerto no estándar, averigua con tu administrador de red si ese puerto está abierto hacia afuera. Es una causa frecuente y fácil de resolver.

✅ Verificación: tienes una lista completa de cinco puntos sobre el entorno. El ingeniero, al leerla, sabe en qué condiciones reproducir el problema.

Paso 6: Automatizar la recopilación del diagnóstico con un solo script

Objetivo de la etapa: reunir toda la información técnica en un solo archivo de texto, sin reescribirla a mano. El script hace lo mismo que hacías manualmente, pero en una sola ejecución.

Script para macOS y Linux

Crea el archivo diag.sh con el siguiente contenido. Reemplaza los valores de las variables por los tuyos.

#!/bin/bash
PROXY="http://ЛОГИН:ПАРОЛЬ@ХОСТ:ПОРТ"
TARGET="https://ЦЕЛЕВОЙ-АДРЕС"
ALT="https://СТАБИЛЬНЫЙ-САЙТ"
OUT="diag_result.txt"
echo "=== Дата и время ===" > $OUT
date >> $OUT
echo "=== Версия curl ===" >> $OUT
curl --version >> $OUT 2>&1
echo "=== Запрос через прокси к цели ===" >> $OUT
curl -v -x $PROXY -w "code:%{http_code} total:%{time_total}s" $TARGET >> $OUT 2>&1
echo "=== Запрос через прокси к альтернативному сайту ===" >> $OUT
curl -v -x $PROXY -w "code:%{http_code} total:%{time_total}s" $ALT >> $OUT 2>&1
echo "=== Прямой запрос к цели без прокси ===" >> $OUT
curl -v -w "code:%{http_code} total:%{time_total}s" $TARGET >> $OUT 2>&1
echo "Готово. Файл: $OUT"

Cómo ejecutar el script

  1. Guarda el archivo con el nombre diag.sh.
  2. Escribe tus valores en las variables PROXY, TARGET y ALT.
  3. En el terminal, ve a la carpeta con el archivo.
  4. Haz el archivo ejecutable con el comando 
    chmod +x diag.sh
  5. Ejecútalo con el comando 
    ./diag.sh
  6. Al terminar, abre el archivo diag_result.txt.

Script para Windows (PowerShell)

Crea el archivo diag.ps1 con una lógica similar.

$Proxy = "http://ЛОГИН:ПАРОЛЬ@ХОСТ:ПОРТ"
$Target = "https://ЦЕЛЕВОЙ-АДРЕС"
$Alt = "https://СТАБИЛЬНЫЙ-САЙТ"
$Out = "diag_result.txt"
"=== Дата и время ===" | Out-File $Out
Get-Date | Out-File $Out -Append
"=== Версия curl ===" | Out-File $Out -Append
curl --version 2>&1 | Out-File $Out -Append
"=== Через прокси к цели ===" | Out-File $Out -Append
curl -v -x $Proxy -w "code:%{http_code} total:%{time_total}s" $Target 2>&1 | Out-File $Out -Append
"=== Через прокси к альтернативе ===" | Out-File $Out -Append
curl -v -x $Proxy $Alt 2>&1 | Out-File $Out -Append
"=== Прямой запрос ===" | Out-File $Out -Append
curl -v $Target 2>&1 | Out-File $Out -Append

Ejecútalo en PowerShell con el comando 

.\diag.ps1
y abre el archivo resultante.

⚠️ Atención: el archivo diag_result.txt contiene tu usuario y contraseña en texto plano, porque estaban en la variable PROXY. Antes de enviarlo al soporte, OBLIGATORIAMENTE límpialo según las instrucciones del paso 7.

Consejo: guarda el script con las variables vacías y pega los valores solo antes de ejecutarlo. Así no corres el riesgo de compartir accidentalmente un archivo con secretos dentro.

✅ Verificación: el archivo diag_result.txt está creado y contiene varios bloques: la versión de curl, las solicitudes a través del proxy a dos sitios y la solicitud directa. Es el paquete completo de diagnóstico técnico.

Paso 7: Limpiar los logs de forma segura antes de enviarlos

Objetivo de la etapa: eliminar de los datos recopilados todo lo secreto, conservando su valor diagnóstico. Enviar logs con contraseñas no se puede bajo ninguna circunstancia.

Qué recortar obligatoriamente

  • La contraseña del proxy. En la salida pudo haber caído en la línea de conexión. Búscala y reemplázala.
  • El usuario, si está vinculado a datos de pago. Normalmente el usuario se puede dejar, pero si es parte de una combinación sensible, reemplázalo también.
  • Tokens de autorización. Si en los encabezados de la solicitud hay Authorization, tokens Bearer, claves API, cookies de sesión, recorta todo eso.
  • Datos personales. Cualquier nombre, dirección, teléfono, si cayeron por accidente en el cuerpo de la solicitud o la respuesta.

Con qué reemplazar

No elimines la línea entera: así se pierde la estructura. Reemplaza el secreto por un marcador claro, conservando la longitud y el formato en lo posible. Ejemplos de reemplazo:

  • La contraseña reemplázala por [CONTRASEÑA_OCULTA].
  • El usuario por [USUARIO_OCULTO].
  • El token por [TOKEN_OCULTO].

Así el ingeniero ve que en ese lugar había un token, pero no ve su valor. La estructura se conserva, la seguridad también.

Orden de limpieza

  1. Abre el archivo diag_result.txt en un editor de texto.
  2. Usa la búsqueda (Ctrl+F) por tu contraseña y reemplaza todas las apariciones por el marcador.
  3. Haz lo mismo con el usuario, si decidiste ocultarlo.
  4. Revisa las líneas con encabezados Authorization, Cookie, api-key. Reemplaza los valores por marcadores.
  5. Guarda el archivo con un nuevo nombre, por ejemplo diag_clean.txt, para no confundirlo con el original.

⚠️ Atención: revisa el archivo dos veces antes de enviarlo. La contraseña pudo aparecer no solo en el comando, sino también en las líneas de salida de curl. Un secreto omitido es una fuga que puede llevar a la compromisión de tu proxy.

Consejo: guarda el original diag_result.txt de forma local y envía solo la copia limpia. Si el ingeniero pide alguna aclaración, tendrás los datos completos a mano.

✅ Verificación: abre el archivo limpio y realiza una búsqueda por tu contraseña. Cero resultados significa que la limpieza fue exitosa. La estructura de la salida se conserva.

Paso 8: Completar la plantilla de solicitud lista

Objetivo de la etapa: reunir todo en un correo que el ingeniero leerá y entenderá la tarea de inmediato. Abajo, una plantilla para copiar.

Plantilla de solicitud al soporte de Proxeon

Тема: Проблема с прокси [ИДЕНТИФИКАТОР] при обращении к [ЦЕЛЬ]

1. Идентификатор прокси: [например PX-48213]
2. Тип прокси: [HTTP / HTTPS / SOCKS5]
3. Время проблемы: [12.03.2026, 14:32, UTC+3]
4. Целевой адрес: [https://api.example.com/v2/data]
5. Что делал: [отправлял GET-запрос из curl]
6. Ожидал: [код 200 и данные]
7. Получил: [ошибку соединения / медленный ответ / код ошибки]

Результаты проверок:
- Другой сайт через этот прокси: [работает / не работает]
- Прямое соединение без прокси: [работает / не работает]
- Другой прокси к той же цели: [работает / не работает / нет второго прокси]

Окружение:
- ОС: [Windows 11]
- Клиент: [curl 8.6.0]
- Настройка прокси: [флаг -x в curl]
- Корпоративный фильтр: [нет / есть, порты 80 и 443]

Вывод диагностики (логин и пароль скрыты) прилагаю в файле diag_clean.txt.

Краткий вывод: по моим проверкам проблема на границе [клиент-прокси / прокси-сервер], потому что [прямое соединение работает, а через прокси нет].

Cómo completar correctamente

  1. Copia la plantilla en el cuerpo del correo o del ticket.
  2. Reemplaza cada campo entre corchetes con tus datos.
  3. Adjunta el archivo limpio diag_clean.txt.
  4. Relee el correo completo: ¿es comprensible para una persona ajena?
  5. Envíalo.

Consejo: la línea "Conclusión breve" al final es la más útil. En ella formulas tu propia hipótesis basada en las verificaciones. Aunque la hipótesis sea imprecisa, le muestra al ingeniero el hilo de tus pensamientos y ahorra tiempo.

✅ Verificación: en el correo no queda ningún campo entre corchetes: todos están completados. Se adjunta el archivo limpio. Hay una conclusión breve con la hipótesis. La solicitud está lista para enviarse.

Verificación del resultado: lista de verificación de la solicitud

Antes de enviar, repasa una breve lista de verificación. Garantiza que no omitiste nada.

  • Se indica el identificador exacto del proxy, no una descripción.
  • Está la hora del evento con zona horaria explícita.
  • Se indica la dirección de destino completa.
  • Se describe qué hiciste, qué esperabas y qué obtuviste.
  • Se adjunta la salida completa de curl en modo detallado.
  • Se realizaron y describieron al menos dos verificaciones de exclusión.
  • Se indican el sistema operativo, el cliente y su versión.
  • Se eliminaron de los logs la contraseña y todos los tokens.
  • El archivo de diagnóstico está adjunto y con un nombre claro.
  • Hay una conclusión breve con tu hipótesis.

Si todos los puntos están marcados, tu solicitud pertenece a las que se resuelven en la primera respuesta. El ingeniero no necesita aclarar nada: tiene el panorama completo.

✅ Verificación: los diez puntos de la lista de verificación están cumplidos. Ese es el indicador de éxito: la solicitud es autosuficiente.

Errores típicos y sus soluciones

Analicemos problemas frecuentes al recopilar el diagnóstico y formas de resolverlos.

Problema 1: curl da error de inmediato, sin conectarse al proxy

Causa: formato incorrecto de la dirección del proxy o error de tipeo en el esquema (http en lugar de socks5 o al revés).

Solución: verifica el tipo de proxy en el panel de control de Proxeon y coloca el esquema correcto. Asegúrate de que el puerto esté indicado correctamente y separado por dos puntos.

Problema 2: error de autorización en el proxy

Causa: usuario o contraseña incorrectos, o caracteres especiales en la contraseña sin escapar.

Solución: revisa las credenciales. Si en la contraseña hay caracteres @, :, /, pueden romper la cadena. En tal caso, pasa la autorización con la bandera aparte 

--proxy-user ЛОГИН:ПАРОЛЬ
en lugar de insertarla en la URL.

Problema 3: el script no se ejecuta en Windows

Causa: la política de ejecución de PowerShell bloquea los scripts locales.

Solución: ejecuta PowerShell como administrador y permite la ejecución para la sesión actual con el comando de política RemoteSigned a nivel de proceso. Después de recopilar los datos, devuelve la política original.

Problema 4: en la salida no hay detalles, solo la línea final

Causa: se olvidó la bandera -v, que activa el modo detallado.

Solución: agrega -v justo después de curl. Es la que muestra el recorrido de la conexión línea por línea, sin la cual el diagnóstico es inútil.

Problema 5: la contraseña quedó por accidente en el archivo enviado

Causa: la limpieza se hizo sin cuidado, la contraseña apareció en una línea de salida, no solo en el comando.

Solución: cambia de inmediato la contraseña del proxy en el panel de control de Proxeon. En adelante, realiza siempre una búsqueda por la contraseña en el archivo limpio antes de enviarlo.

Problema 6: el problema no se reproduce en curl, pero sí en el navegador

Causa: el navegador agrega encabezados, cookies o usa otra forma de configurar el proxy.

Solución: en la solicitud indica honestamente que en curl el problema no se repite, pero en el navegador sí. Adjunta el nombre y la versión del navegador y el método de configuración del proxy en él. Esto ya es información diagnóstica en sí misma.

Problema 7: la hora en los logs no coincide con la tuya

Causa: indicaste la hora local sin zona horaria, y el servidor trabaja en UTC.

Solución: indica siempre la zona de forma explícita. Si dudas, adjunta ambas marcas: tu hora local y su equivalente en UTC.

Capacidades adicionales: diagnóstico avanzado

Si el conjunto básico no es suficiente, aquí hay varias herramientas para un análisis más profundo. Le servirán a los usuarios avanzados.

Tiempos detallados para problemas de velocidad

Cuando el proxy funciona pero lento, es importante entender en qué etapa se pierde el tiempo. La bandera -w ampliada mostrará el desglose.

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" -x http://ЛОГИН:ПАРОЛЬ@ХОСТ:ПОРТ https://ЦЕЛЬ

Estas cifras muestran cuánto se fue en la resolución del nombre, el establecimiento de la conexión, el cifrado y la obtención del primer byte. Si el ttfb es alto, la demora está del lado del objetivo. Si el connect es alto, el problema está en la red hasta el proxy.

Repetibilidad del problema

Si el problema es intermitente, recopila una serie de solicitudes y muestra que una parte pasa y otra no. Un ciclo simple de varias solicitudes con registro de los códigos de respuesta dará estadísticas. La estabilidad o su ausencia es un hecho importante para el soporte.

Verificación de varios objetivos a la vez

Arma una lista de tres o cuatro direcciones y pásalas por el proxy en una sola serie. Así verás de inmediato si el problema es específico de un objetivo o es general.

Consejo: adjunta los datos avanzados solo si el diagnóstico básico no fue suficiente. El exceso de información sin estructura es tan dañino como su falta. Empieza por el mínimo, profundiza a pedido del ingeniero.

FAQ: preguntas frecuentes sobre la recopilación de diagnóstico

¿Es obligatorio usar precisamente curl?

No, pero curl es la herramienta más universal y comprensible para el ingeniero. Su salida es igual en todos los sistemas. Si trabajas a través de una biblioteca en el código, adjunta también su salida, pero la verificación con curl sigue siendo valiosa como referencia.

¿Qué hacer si el problema ya pasó y no se repite?

Fija todo lo que recuerdes: la hora aproximada, el objetivo, la naturaleza del error. Adjunta los logs de tu aplicación de ese período. Incluso datos incompletos con la hora exacta ayudarán a encontrar el registro en el servidor.

¿Hay que adjuntar logs si el error es obvio por la descripción?

Sí. Lo que a ti te parece obvio requiere confirmación con hechos. Los logs eliminan las suposiciones y permiten dar una respuesta precisa, no una conjetura.

¿Se puede enviar el usuario y la contraseña para que el soporte lo verifique todo?

No. Los secretos no se transmiten en la correspondencia. El soporte de Proxeon tiene acceso a tu cuenta por el identificador, sin contraseña. El identificador es suficiente para la verificación del lado del servidor.

¿Qué tan rápido llega la respuesta si todo está recopilado correctamente?

Una solicitud completa reduce el tiempo hasta la solución varias veces, porque elimina el ciclo de aclaraciones. Los plazos exactos dependen de la carga del soporte, pero definitivamente evitas varios rondas de correspondencia.

¿Y si curl muestra éxito, pero la aplicación sigue sin funcionar?

Es un hecho valioso: el problema no está en el proxy como tal, sino en cómo lo usa la aplicación. Indícalo en la solicitud, adjunta la configuración del proxy en la aplicación y su versión.

¿Hay que indicar la dirección de destino si es pública?

Sí, obligatoriamente. El comportamiento del proxy puede depender del objetivo concreto. Sin la dirección, el ingeniero no podrá reproducir precisamente tu caso.

¿Cómo entender si es mi puerto o se requiere otro?

El puerto está indicado en la tarjeta del proxy en el panel de control. Distintos tipos de proxy usan distintos puertos. Verifica con el panel de control y no pongas el puerto al azar.

¿Se puede automatizar la limpieza de los logs de secretos?

Sobre el autor

Roman Melnikov

Roman Melnikov

Technical Writer and System Administrator

Experiencia laboral: Technical writer and DevOps engineer with 9 years of experience. Created over 50 detailed guides on system configuration and administration. His instructions helped thousands of professionals successfully solve technical tasks. Popular author on Habr and YouTube.
Formación académica: Bauman Moscow State Technical University. Information Systems and Technologies
Especialización:
Technical Documentation DevOps System Administration Linux Docker and Kubernetes CI/CD Infrastructure Automation Cloud Technologies System Monitoring Bash and Python Scripting

Comparte el artículo: