Sommaire de l'article

La phrase « le proxy ne fonctionne pas » ressemble pour un ingénieur support à « j'ai mal quelque part à l'intérieur » pour un médecin. La direction est claire, mais sans analyses ni symptômes, impossible de poser un diagnostic. Dans ce guide, vous allez apprendre à rassembler exactement l'ensemble de données qui transforme une plainte vague en une tâche précise avec une réponse claire et unique.

Introduction : pourquoi « ça ne marche pas » est indiagnosticable

Imaginez deux demandes au support Proxeon. La première : « J'ai acheté un proxy, rien ne marche, aidez-moi ». La seconde : « Le proxy avec l'identifiant PX-48213 à 14h32 heure de Moscou (UTC+3) renvoie une erreur de connexion lors d'une requête vers api.example.com en HTTP, alors que le même proxy fonctionne vers un autre site, la connexion directe sans proxy fonctionne aussi, je joins la sortie curl ». La première demande déclenche une chaîne de cinq ou six e-mails de clarification, chacun coûtant des heures d'attente. La seconde se règle en une seule réponse.

La différence n'est ni dans la politesse ni dans la chance. Elle est dans les données. L'ingénieur ne voit pas votre écran, ne connaît pas votre système d'exploitation, ne peut pas reproduire votre requête sans les paramètres de départ. Tout ce qu'il a, c'est le texte de votre message. Si ce texte ne contient pas de faits, la première chose qu'il fera sera de demander des faits. C'est exactement cette chaîne d'e-mails qui étire la résolution d'un problème simple sur plusieurs jours.

Ce que le lecteur obtiendra au final

Après ce guide, vous saurez rassembler en 15-20 minutes un dossier de diagnostic contenant tout le nécessaire pour résoudre le problème dès la première réponse. Vous aurez un script prêt à l'emploi qui collecte les données techniques dans un seul fichier texte, un modèle de demande à copier et une compréhension claire des vérifications à effectuer avant d'écrire au support.

À qui s'adresse ce guide

Ce guide est destiné aux utilisateurs de proxy de niveau intermédiaire : ceux qui savent ouvrir un terminal ou une invite de commandes, qui connaissent la notion d'URL et qui ont configuré un proxy dans une application au moins une fois. Les utilisateurs avancés trouveront ici un script de diagnostic prêt à l'emploi et un tableau d'isolation du problème. Pour les débutants, nous expliquerons chaque terme en détail.

Ce qu'il faut savoir au préalable

Il suffit de comprendre trois choses. Un proxy est un intermédiaire par lequel passe votre requête réseau. L'adresse cible est le site ou le service que vous contactez. Le client est le programme qui envoie la requête via le proxy (navigateur, scraper, script). Tout le reste sera expliqué en cours de route.

Combien de temps cela prendra

La première lecture du guide avec la configuration du script prendra environ 30 minutes. Ensuite, la collecte du diagnostic à partir du modèle prêt à l'emploi prendra 10-15 minutes. C'est incomparablement moins que plusieurs jours d'échanges avec des clarifications.

Conseil : mettez ce guide et le script en favoris. Les problèmes de proxy surviennent rarement, et quand ils apparaissent, il est difficile de se rappeler toute la procédure. Une checklist prête à portée de main économise les nerfs.

Préparation préalable : outils et accès

Avant de collecter les données, assurez-vous de disposer des outils de base. Tous sont gratuits et déjà installés sur la plupart des systèmes.

Outils nécessaires

  • curl — un utilitaire en ligne de commande pour envoyer des requêtes réseau. C'est notre outil principal pour reproduire le problème. Il est préinstallé sur macOS et la plupart des distributions Linux. Sur Windows 10 et 11, il fait également partie du système.
  • Terminal ou invite de commandes — la fenêtre où vous saisissez les commandes. Sur Windows, c'est PowerShell ou l'invite de commandes (cmd), sur macOS et Linux, c'est le Terminal.
  • Éditeur de texte — Bloc-notes, TextEdit ou tout autre pour consulter le fichier collecté et supprimer les secrets.
  • Vos données proxy Proxeon — identifiant, adresse, port, identifiant de connexion et mot de passe. Ils vous sont fournis dans votre espace client.

Vérifier la présence de curl

Ouvrez le terminal et effectuez une vérification simple.

  1. Sous Windows, appuyez sur la touche Win, tapez PowerShell et ouvrez l'application.
  2. Sous macOS, ouvrez Spotlight avec Cmd+Espace, tapez Terminal et appuyez sur Entrée.
  3. Sous Linux, ouvrez le terminal via le menu des applications ou avec Ctrl+Alt+T.
  4. Saisissez la commande 
    curl --version
    et appuyez sur Entrée.

Si vous voyez une ligne du type « curl 8.x.x » avec une liste des protocoles pris en charge, l'outil est prêt. Si le système indique que la commande est introuvable, installez curl : sous Windows, mettez le système à jour vers la version actuelle ; sous Linux, effectuez l'installation via le gestionnaire de paquets de votre distribution.

✅ Vérification : la commande 

curl --version
a affiché le numéro de version et la liste des protocoles, y compris http et https. Tout est donc prêt.

Quelles données Proxeon préparer

Connectez-vous à votre espace client Proxeon sur proxeon.net et ouvrez la fiche de votre proxy. Notez ou copiez dans un fichier séparé les champs suivants : identifiant du proxy, hôte (adresse), port, type (HTTP, HTTPS ou SOCKS5), identifiant de connexion et mot de passe. Ces données seront nécessaires pour construire la commande de reproduction.

⚠️ Attention : l'identifiant et le mot de passe du proxy sont des données secrètes. Nous allons les utiliser localement, mais il ne faut PAS les insérer dans la demande au support. Une section dédiée ci-dessous explique comment nettoyer les logs en toute sécurité avant l'envoi.

Notions de base : la frontière client — proxy — serveur

Pour comprendre quelles données sont importantes, il faut se représenter le chemin de la requête. Il traverse trois segments, et le problème peut surgir sur n'importe lequel d'entre eux.

Trois maillons d'une même chaîne

Quand vous accédez à un site via un proxy, la requête suit ce chemin : votre client envoie une requête au serveur proxy, celui-ci la redirige vers le serveur cible, reçoit la réponse et vous la renvoie. Trois maillons, deux frontières. Comprendre à quelle frontière ça bloque, c'est déjà la moitié du diagnostic.

  • Frontière client — proxy. Si la requête n'a même pas atteint le proxy, le problème est de votre côté : mauvaise adresse proxy, port fermé, filtre d'entreprise, erreur dans les paramètres du client.
  • Frontière proxy — serveur. Si le proxy a accepté la requête mais n'a pas pu joindre le site cible, le problème se situe entre le proxy et la cible : site inaccessible, connexion refusée ou réponse en erreur.

La tâche du diagnostic est de déterminer à quelle frontière tout s'est cassé. L'ingénieur support Proxeon verra immédiatement, d'après votre sortie, où la requête s'est arrêtée, et cela réduira fortement le champ des causes possibles.

Pourquoi l'heure exacte est si importante

L'infrastructure proxy conserve des logs. Pour y trouver votre requête précise, l'ingénieur a besoin de l'heure exacte de l'événement avec le fuseau horaire. « Ce matin » ne se recherche pas dans les logs. « 14h32 heure de Moscou, UTC+3 » se trouve en quelques secondes. Un décalage entre votre formulation et l'enregistrement dans le log est une cause fréquente de non-localisation de l'événement.

Conseil : indiquez toujours explicitement le fuseau horaire. Le format « UTC+3 » ou « MSK » est compréhensible sans ambiguïté. Si vous êtes dans un autre fuseau, indiquez le vôtre — le serveur fera la conversion lui-même.

Étape 1 : rassembler l'ensemble minimal de données

Objectif de l'étape : fixer cinq faits sans lesquels toute demande sera incomplète. C'est la fondation, tout le reste se construit par-dessus.

Cinq faits obligatoires

  1. Identifiant du proxy. Le nom ou numéro exact depuis l'espace client Proxeon, par exemple PX-48213. Pas « le proxy que j'ai acheté hier », mais un identifiant précis. Si vous avez un lot de plusieurs proxys, précisez duquel il s'agit exactement.
  2. L'heure exacte avec le fuseau horaire. Quand exactement le problème est apparu. Format : date, heure, fuseau. Par exemple : 12 mars 2026, 14h32, UTC+3. Si le problème se répète, indiquez plusieurs horodatages.
  3. L'adresse cible. L'URL ou l'hôte complet que vous avez contacté. Par exemple : https://api.example.com/v2/data. Pas « un site », mais l'adresse exacte.
  4. Ce que vous faisiez exactement. Une ou deux phrases sur l'action. « J'envoyais une requête GET depuis mon script » ou « j'ouvrais le site dans le navigateur avec le proxy configuré ». Le contexte aide à comprendre la nature de la requête.
  5. Ce que vous attendiez et ce que vous avez obtenu. Vous attendiez un code 200 et des données, vous avez eu une erreur de connexion. Vous attendiez le chargement de la page, vous avez eu un chargement infini. La différence entre attente et réalité, c'est l'essence du problème.

⚠️ Attention : ne remplacez pas le concret par l'émotion. « Tout rame et c'est horrible » ne porte aucune information technique. « La réponse arrive en 40 secondes au lieu des 2 habituelles » en porte.

Comment fixer l'heure correctement

Si le problème se produit en ce moment même, regardez l'horloge et notez l'heure immédiatement. S'il s'est produit dans le passé, reconstituez l'heure à partir des logs de votre application ou de l'historique du navigateur. Plus le marqueur est précis, plus vite l'enregistrement sera trouvé côté serveur.

✅ Vérification : vous avez cinq faits notés. Lisez-les à voix haute. Si une personne qui ne voit pas votre écran comprend ce qui s'est passé, où et quand, l'ensemble minimal est rassemblé.

Étape 2 : reproduire le problème avec une seule commande curl

Objectif de l'étape : réduire le problème à une seule commande que l'ingénieur pourra mentalement ou littéralement répéter, et obtenir une sortie technique détaillée.

Le navigateur et un script complexe effectuent des dizaines d'actions cachées. Il est difficile d'y isoler le problème. L'utilitaire curl effectue exactement une requête et montre chaque étape. C'est l'outil de reproduction idéal.

Commande de base via le proxy Proxeon

Construisez la commande à partir de vos données. La forme générale est la suivante :

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

Détaillons les options. -v active le mode détaillé (verbose) : curl affichera tout le déroulement de la connexion ligne par ligne. -x définit le proxy par lequel passe la requête. Après lui, l'adresse du proxy avec authentification. À la fin, l'adresse cible.

Exemple avec les valeurs insérées (données fictives) :

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

Ajouter la mesure du temps et l'écriture dans un fichier

Pour rendre la sortie la plus informative possible, élargissons la commande. L'option -w ajoutera un récapitulatif des timings à la fin.

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

Maintenant, tout à la fin de la sortie, vous verrez le code HTTP final et le temps total de la requête. Ce sont les chiffres clés pour diagnostiquer la vitesse.

Conseil : si le problème concerne la lenteur plutôt qu'une erreur, ajoutez des timings détaillés via 

-w "dns: %{time_namelookup} connect: %{time_connect} start: %{time_starttransfer} total: %{time_total}"
Cela montrera à quelle étape le temps se perd.

Pour un proxy SOCKS5

Si votre proxy est de type SOCKS5, changez le schéma dans l'adresse :

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

⚠️ Attention : la commande contient votre identifiant et votre mot de passe réels. Exécutez-la dans votre terminal, mais NE copiez PAS la commande avec les secrets dans le message. Dans la demande, l'identifiant et le mot de passe sont remplacés par des espaces réservés — voir l'étape 5.

Ordre d'exécution

  1. Ouvrez le terminal.
  2. Collez la commande construite en insérant vos données réelles.
  3. Appuyez sur Entrée et attendez la fin.
  4. Sélectionnez toute la sortie, de la première à la dernière ligne, et copiez-la dans un fichier texte.

✅ Vérification : vous avez obtenu une sortie multi-lignes où l'on voit des lignes commençant par les caractères « * », « > » et « < ». Si la sortie existe, la reproduction a réussi, même si la requête s'est terminée par une erreur — l'erreur est aussi une information précieuse.

Étape 3 : lire la sortie ligne par ligne et trouver la frontière du problème

Objectif de l'étape : apprendre à comprendre ce que montre la sortie curl et à déterminer à quel maillon la requête s'est arrêtée. Nous ne dupliquons pas ici le décodage des codes d'erreur spécifiques — un article dédié existe dans la base de connaissances Proxeon, mettez-y un lien dans la demande si nécessaire.

Trois types de lignes dans la sortie

La sortie détaillée de curl utilise des préfixes qui facilitent l'orientation.

  • Les lignes avec astérisque (*) — messages de service de curl lui-même sur le déroulement de la connexion : résolution du nom, établissement de la liaison avec le proxy, poignée de main de chiffrement. C'est la cuisine interne.
  • Les lignes avec flèche vers la droite (>) — ce que votre client ENVOIE. En-têtes de requête, méthode, chemin.
  • Les lignes avec flèche vers la gauche (<) — ce qu'on vous RÉPOND. Code de réponse, en-têtes du serveur.

Où se situe la frontière client — proxy

Au début de la sortie, curl indique qu'il établit une connexion avec le proxy. Vous verrez une ligne du type « Connected to proxy.proxeon.net port 8080 ». Si cette ligne est absente et remplacée par une erreur de connexion, cela signifie que la requête n'a pas atteint le proxy. Le problème est à la frontière client — proxy : peut-être un port fermé, une adresse erronée ou un filtre local qui interfère.

Si la ligne sur la connexion au proxy est présente, mais qu'ensuite vient une erreur d'autorisation, cela signifie que le proxy est accessible mais n'a pas accepté votre identifiant et mot de passe. C'est aussi la frontière client — proxy, mais au niveau de l'authentification.

Où se situe la frontière proxy — serveur

Après une connexion réussie au proxy, curl montre l'établissement de la connexion avec le serveur cible via le proxy. Si une erreur survient ici, cela signifie que le proxy a accepté la requête mais n'a pas pu joindre la cible. Le problème est à la frontière proxy — serveur : le site cible est inaccessible, refuse la connexion ou répond lentement.

Si en revanche vous voyez une ligne de réponse avec flèche vers la gauche, par exemple « < HTTP/1.1 200 » ou un autre code, cela signifie que toute la chaîne a fonctionné et que vous avez reçu une réponse. Ensuite, c'est une question de contenu de la réponse, plus de fonctionnement du proxy.

Les lignes clés importantes pour l'ingénieur

  1. La ligne de connexion au proxy — confirme que le premier maillon fonctionne.
  2. La ligne sur l'autorisation au proxy — montre si les identifiants sont acceptés.
  3. La ligne sur la poignée de main de chiffrement (TLS) — importante pour les cibles HTTPS.
  4. La première ligne de réponse avec flèche vers la gauche — le verdict final de la chaîne.
  5. Le récapitulatif final avec le code et le temps de l'option -w.

Conseil : n'essayez pas de poser un diagnostic vous-même à partir du code d'erreur si vous n'êtes pas sûr. Votre tâche est de joindre la sortie complète. L'ingénieur Proxeon la lira plus précisément. Le décodage complet des codes se trouve dans un article dédié de la base de connaissances — citez-le si vous voulez aller plus loin.

✅ Vérification : vous pouvez pointer du doigt la ligne après laquelle la requête s'est cassée et dire à quelle frontière cela se situe — client-proxy ou proxy-serveur. Si vous pouvez le faire, vous avez passé cette étape.

Étape 4 : effectuer les vérifications avant la demande

Objectif de l'étape : par élimination, réduire le champ des causes avant même d'écrire au support. Chaque vérification élimine toute une classe de problèmes.

Le principe est simple : on change un paramètre à la fois et on regarde si le comportement change. C'est l'approche d'ingénierie classique pour isoler une panne.

Quatre vérifications clés

  1. Un autre site cible. Répétez la même requête via le même proxy, mais vers une autre adresse. Prenez un site public réputé stable. S'il fonctionne via le proxy mais que votre cible non, le problème est lié au site cible ou à sa relation avec le proxy, pas au proxy lui-même.
  2. Un autre protocole. Si vous utilisiez HTTP, essayez une cible HTTPS, et inversement. Parfois le problème ne se manifeste que sur un protocole, et c'est un signal important.
  3. Un autre proxy. Si vous avez un second proxy Proxeon, répétez la requête via celui-ci. Si le second fonctionne et pas le premier, le problème vient d'un proxy précis. Si les deux se comportent pareil, le problème est plus systémique.
  4. Connexion directe. Effectuez la requête vers la cible SANS proxy, directement. Retirez l'option -x. Si le site est aussi inaccessible en direct, le problème ne vient pas du proxy du tout, mais du site cible lui-même ou de votre réseau.

Commande pour la vérification directe

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

La même commande, mais sans la partie proxy. Comparez le résultat avec la requête via le proxy.

Tableau : ce que chaque vérification élimine

Voici comment interpréter les résultats des vérifications.

  • Un autre site fonctionne, le vôtre non. Élimine une panne globale du proxy. Indique une spécificité de l'interaction entre la cible précise et le proxy.
  • Un autre protocole fonctionne, le vôtre non. Élimine une indisponibilité totale. Localise le problème au niveau d'un protocole ou d'un port précis.
  • Un autre proxy fonctionne, le vôtre non. Élimine un problème de votre côté et côté réseau. Indique un proxy précis.
  • La connexion directe ne fonctionne pas non plus. Élimine la responsabilité du proxy. Le problème vient du site cible ou de votre réseau.
  • Le direct fonctionne, via le proxy non. Confirme que le problème vient bien du lien avec le proxy, et c'est justement là que le support aidera.

Conseil : les résultats de ces quatre vérifications sont la partie la plus précieuse de la demande. Ils font gagner à l'ingénieur la moitié du travail, car vous avez déjà éliminé le superflu. Listez-les impérativement dans votre message.

⚠️ Attention : utilisez ces proxys exclusivement pour des tâches légales : tester vos propres services, collecter des données publiques dans le respect des règles, travailler avec des API. Les vérifications ne sont pas destinées à des actions violant les règles des sites ou la législation.

✅ Vérification : vous avez les résultats des quatre vérifications, et vous pouvez dire en une phrase ce qu'elles éliminent ensemble. Par exemple : « la connexion directe et un autre proxy fonctionnent, donc le problème vient précisément du proxy PX-48213 lors de l'accès à cette cible ».

Étape 5 : rassembler les données de votre côté

Objectif de l'étape : décrire l'environnement dans lequel le problème survient. La moitié des cas incompréhensibles s'explique par des particularités du client ou du réseau local.

Ce qu'il faut indiquer sur l'environnement

  1. Le système d'exploitation et sa version. Windows 11, macOS 15, Ubuntu 24.04. La version exacte aide à reproduire les conditions.
  2. Le client et sa version. Avec quoi vous travaillez avec le proxy : navigateur et sa version, nom et version du scraper ou de la bibliothèque, version de curl. Les différents clients traitent le proxy différemment.
  3. La méthode de configuration du proxy. Configuré dans le système, dans le navigateur, transmis dans le code, défini dans les variables d'environnement. Cela influence la manière dont le proxy est appliqué.
  4. La présence d'un filtre d'entreprise ou local. Travaillez-vous depuis un réseau d'entreprise, y a-t-il un antivirus avec pare-feu réseau, un pare-feu local. De tels filtres peuvent intercepter ou bloquer les connexions avant même le proxy.
  5. Le type de connexion à Internet. Fournisseur domestique, internet mobile, réseau professionnel. Parfois le fournisseur influence l'accessibilité.

Comment connaître la version du client

Pour curl, utilisez la commande déjà familière 

curl --version
Pour le navigateur, ouvrez la section « À propos » dans le menu. Pour une bibliothèque dans le code, consultez sa version dans le fichier de dépendances de votre projet.

Vérification du filtre d'entreprise

Si vous êtes sur un réseau d'entreprise et soupçonnez un filtre, c'est facile à vérifier. Effectuez une requête directement vers le proxy sans cible et regardez si la connexion s'établit. Si même la connexion directe au port du proxy ne passe pas, alors qu'elle passe depuis un autre réseau, un filtre d'entreprise sur les connexions sortantes est probable.

Conseil : les réseaux d'entreprise n'autorisent souvent que les ports 80 et 443. Si votre proxy est sur un port non standard, demandez à votre administrateur réseau si ce port est ouvert vers l'extérieur. C'est une cause fréquente et facile à résoudre.

✅ Vérification : vous avez une liste remplie de cinq points sur l'environnement. L'ingénieur, en la lisant, sait dans quelles conditions reproduire le problème.

Étape 6 : automatiser la collecte du diagnostic avec un seul script

Objectif de l'étape : rassembler toute l'information technique dans un seul fichier texte, sans la recopier à la main. Le script fait ce que vous faisiez manuellement, mais en un seul lancement.

Script pour macOS et Linux

Créez un fichier diag.sh avec le contenu suivant. Remplacez les valeurs des variables par les vôtres.

#!/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"

Comment lancer le script

  1. Enregistrez le fichier sous le nom diag.sh.
  2. Inscrivez vos valeurs dans les variables PROXY, TARGET et ALT.
  3. Dans le terminal, placez-vous dans le dossier contenant le fichier.
  4. Rendez le fichier exécutable avec la commande 
    chmod +x diag.sh
  5. Lancez-le avec la commande 
    ./diag.sh
  6. Une fois terminé, ouvrez le fichier diag_result.txt.

Script pour Windows (PowerShell)

Créez un fichier diag.ps1 avec une logique similaire.

$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

Lancez-le dans PowerShell avec la commande 

.\diag.ps1
et ouvrez le fichier obtenu.

⚠️ Attention : le fichier diag_result.txt contient votre identifiant et votre mot de passe en clair, car ils étaient dans la variable PROXY. Avant l'envoi au support, nettoyez-le OBLIGATOIREMENT selon les instructions de l'étape 7.

Conseil : conservez le script avec des variables vides, et insérez les valeurs juste avant le lancement. Ainsi, vous ne risquez pas de partager accidentellement un fichier contenant des secrets.

✅ Vérification : le fichier diag_result.txt est créé et contient plusieurs blocs : la version de curl, les requêtes via le proxy vers deux sites et la requête directe. C'est un dossier de diagnostic technique prêt à l'emploi.

Étape 7 : nettoyer en toute sécurité les logs avant l'envoi

Objectif de l'étape : supprimer des données collectées tout ce qui est secret, tout en préservant leur valeur diagnostique. Envoyer des logs avec des mots de passe est absolument à proscrire.

Ce qu'il faut impérativement retirer

  • Le mot de passe du proxy. Dans la sortie, il a pu se retrouver dans la ligne de connexion. Trouvez-le et remplacez-le.
  • L'identifiant de connexion, s'il est lié à des données de paiement. En général, l'identifiant peut rester, mais s'il fait partie d'une combinaison sensible, remplacez-le aussi.
  • Les jetons d'autorisation. Si dans les en-têtes de requête il y a Authorization, des jetons Bearer, des clés API, des cookies de session — tout cela est à retirer.
  • Les données personnelles. Tout nom, adresse, téléphone, s'ils se sont retrouvés par hasard dans le corps de la requête ou de la réponse.

Par quoi remplacer

Ne supprimez pas la ligne entière — la structure serait perdue. Remplacez le secret par un espace réservé compréhensible, en conservant si possible la longueur et le format. Exemples de remplacement :

  • Le mot de passe par [ПАРОЛЬ_СКРЫТ].
  • L'identifiant par [ЛОГИН_СКРЫТ].
  • Le jeton par [ТОКЕН_СКРЫТ].

Ainsi, l'ingénieur voit qu'il y avait un jeton à cet endroit, mais pas sa valeur. La structure est préservée, la sécurité aussi.

Ordre du nettoyage

  1. Ouvrez le fichier diag_result.txt dans un éditeur de texte.
  2. Utilisez la recherche (Ctrl+F) sur votre mot de passe et remplacez toutes les occurrences par l'espace réservé.
  3. Faites de même avec l'identifiant, si vous avez décidé de le masquer.
  4. Parcourez les lignes avec les en-têtes Authorization, Cookie, api-key. Remplacez les valeurs par des espaces réservés.
  5. Enregistrez le fichier sous un nouveau nom, par exemple diag_clean.txt, pour ne pas le confondre avec l'original.

⚠️ Attention : vérifiez le fichier deux fois avant l'envoi. Le mot de passe a pu apparaître non seulement dans la commande, mais aussi dans les lignes de sortie de curl. Un secret oublié est une fuite qui peut mener à la compromission de votre proxy.

Conseil : gardez l'original diag_result.txt en local et n'envoyez qu'une copie nettoyée. Si l'ingénieur demande une précision, vous avez les données complètes sous la main.

✅ Vérification : ouvrez le fichier nettoyé et effectuez une recherche sur votre mot de passe. Zéro résultat — le nettoyage a réussi. La structure de la sortie est préservée.

Étape 8 : remplir le modèle de demande prêt à l'emploi

Objectif de l'étape : tout rassembler dans un message que l'ingénieur lira et comprendra immédiatement. Ci-dessous, un modèle à copier.

Modèle de demande au support 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.

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

Comment remplir correctement

  1. Copiez le modèle dans le corps du message ou du ticket.
  2. Remplacez chaque champ entre crochets par vos données.
  3. Joignez le fichier nettoyé diag_clean.txt.
  4. Relisez le message en entier : est-il compréhensible pour une personne extérieure.
  5. Envoyez.

Conseil : la ligne « Conclusion brève » à la fin est la plus utile. Vous y formulez vous-même une hypothèse à partir des vérifications. Même si l'hypothèse est imprécise, elle montre à l'ingénieur votre raisonnement et fait gagner du temps.

✅ Vérification : le message ne contient aucun champ entre crochets — tous sont remplis. Le fichier nettoyé est joint. Il y a une conclusion brève avec une hypothèse. La demande est prête à l'envoi.

Vérification du résultat : checklist de préparation de la demande

Avant l'envoi, parcourez une courte checklist. Elle garantit que vous n'avez rien oublié.

  • L'identifiant exact du proxy est indiqué, pas une description.
  • L'heure de l'événement est présente avec un fuseau horaire explicite.
  • L'adresse cible complète est indiquée.
  • Ce que vous faisiez, ce que vous attendiez et ce que vous avez obtenu est décrit.
  • La sortie curl complète en mode détaillé est jointe.
  • Au moins deux vérifications d'élimination ont été effectuées et décrites.
  • Le système d'exploitation, le client et sa version sont indiqués.
  • Le mot de passe et tous les jetons ont été supprimés des logs.
  • Le fichier de diagnostic est joint et nommé clairement.
  • Il y a une conclusion brève avec votre hypothèse.

Si tous les points sont cochés, votre demande fait partie de celles qui sont résolues dès la première réponse. L'ingénieur n'a rien à préciser — il a une image complète.

✅ Vérification : les dix points de la checklist sont remplis. C'est l'indicateur de réussite : la demande est autosuffisante.

Erreurs typiques et leurs solutions

Détaillons les problèmes fréquents lors de la collecte du diagnostic et les moyens de les résoudre.

Problème 1 : curl renvoie une erreur immédiatement, sans connexion au proxy

Cause : format d'adresse proxy erroné ou faute de frappe dans le schéma (http au lieu de socks5 ou inversement).

Solution : vérifiez le type de proxy dans l'espace client Proxeon et mettez le bon schéma. Assurez-vous que le port est correct et séparé par deux-points.

Problème 2 : erreur d'autorisation sur le proxy

Cause : identifiant ou mot de passe erroné, ou caractères spéciaux dans le mot de passe non échappés.

Solution : revérifiez les identifiants. Si le mot de passe contient les caractères @, :, / — ils peuvent casser la ligne. Dans ce cas, transmettez l'autorisation via une option séparée 

--proxy-user ЛОГИН:ПАРОЛЬ
au lieu de l'insérer dans l'URL.

Problème 3 : le script ne se lance pas sous Windows

Cause : la politique d'exécution PowerShell bloque les scripts locaux.

Solution : lancez PowerShell en tant qu'administrateur et autorisez l'exécution pour la session en cours avec la commande de définition de politique RemoteSigned au niveau du processus. Après la collecte des données, rétablissez la politique d'origine.

Problème 4 : la sortie ne contient pas de détails, seulement la ligne finale

Cause : l'option -v, qui active le mode détaillé, a été oubliée.

Solution : ajoutez -v juste après curl. C'est elle qui montre le déroulement ligne par ligne de la connexion, sans lequel le diagnostic est inutile.

Problème 5 : le mot de passe est resté par accident dans le fichier envoyé

Cause : le nettoyage a été fait sans attention, le mot de passe est apparu dans une ligne de sortie, pas seulement dans la commande.

Solution : changez immédiatement le mot de passe du proxy dans l'espace client Proxeon. À l'avenir, effectuez toujours une recherche sur le mot de passe dans le fichier nettoyé avant l'envoi.

Problème 6 : le problème ne se reproduit pas dans curl, mais existe dans le navigateur

Cause : le navigateur ajoute des en-têtes, des cookies ou utilise une autre méthode de configuration du proxy.

Solution : dans la demande, indiquez honnêtement que dans curl le problème ne se répète pas, mais qu'il existe dans le navigateur. Joignez le nom et la version du navigateur et la méthode de configuration du proxy dans celui-ci. C'est en soi une information diagnostique.

Problème 7 : l'heure dans les logs ne correspond pas à la vôtre

Cause : vous avez indiqué l'heure locale sans fuseau horaire, alors que le serveur fonctionne en UTC.

Solution : indiquez toujours le fuseau explicitement. En cas de doute, joignez les deux marqueurs : votre heure locale et son équivalent en UTC.

Fonctionnalités supplémentaires : diagnostic avancé

Si l'ensemble de base ne suffit pas, voici quelques outils pour une analyse plus approfondie. Ils seront utiles aux utilisateurs avancés.

Timings détaillés pour les problèmes de vitesse

Quand le proxy fonctionne mais lentement, il est important de comprendre à quelle étape le temps se perd. L'option -w étendue montrera la répartition.

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://ЦЕЛЬ

Ces chiffres montrent combien de temps a été consacré à la résolution du nom, à l'établissement de la connexion, au chiffrement et à la réception du premier octet. Si ttfb est élevé, la latence est côté cible. Si connect est élevé, le problème est dans le réseau jusqu'au proxy.

Répétabilité du problème

Si le problème est intermittent, collectez une série de requêtes et montrez qu'une partie passe et une autre non. Une simple boucle de plusieurs requêtes avec enregistrement des codes de réponse donnera des statistiques. La stabilité ou son absence est un fait important pour le support.

Vérification de plusieurs cibles à la fois

Établissez une liste de trois ou quatre adresses et faites-les passer via le proxy en une seule série. Vous verrez ainsi immédiatement si le problème est spécifique à une cible ou général.

Conseil : ne joignez des données avancées que si le diagnostic de base n'a pas suffi. Un excès d'informations sans structure est aussi nuisible que leur manque. Commencez par le minimum, approfondissez à la demande de l'ingénieur.

FAQ : questions fréquentes sur la collecte du diagnostic

Est-il obligatoire d'utiliser curl ?

Non, mais curl est l'outil le plus universel et le plus compréhensible pour l'ingénieur. Sa sortie est identique sur tous les systèmes. Si vous travaillez via une bibliothèque dans le code, joignez aussi sa sortie, mais la vérification curl reste précieuse comme référence.

Que faire si le problème est déjà passé et ne se reproduit pas ?

Fixez tout ce dont vous vous souvenez : l'heure approximative, la cible, la nature de l'erreur. Joignez les logs de votre application pour cette période. Même des données incomplètes avec une heure précise aideront à trouver l'enregistrement sur le serveur.

Faut-il joindre les logs si l'erreur est évidente d'après la description ?

Oui. Ce qui vous semble évident nécessite une confirmation par des faits. Les logs écartent les suppositions et permettent de donner une réponse précise, pas une hypothèse.

Peut-on envoyer l'identifiant et le mot de passe pour que le support vérifie tout lui-même ?

Non. Les secrets ne se transmettent pas par messagerie. Le support Proxeon a accès à votre compte par l'identifiant, sans mot de passe. L'identifiant suffit pour la vérification côté serveur.

Dans quel délai arrive la réponse si tout est correctement rassemblé ?

Une demande complète réduit le temps de résolution de plusieurs fois, car elle supprime le cycle de clarifications. Les délais exacts dépendent de la charge du support, mais vous évitez à coup sûr plusieurs tours d'échanges.

Et si curl montre un succès, mais que l'application ne fonctionne toujours pas ?

C'est un fait précieux : le problème ne vient pas du proxy en tant que tel, mais de la façon dont l'application l'utilise. Indiquez-le dans la demande, joignez les paramètres proxy dans l'application et sa version.

Faut-il indiquer l'adresse cible si elle est publique ?

Oui, impérativement. Le comportement du proxy peut dépendre de la cible précise. Sans l'adresse, l'ingénieur ne pourra pas reproduire votre cas.

Comment savoir si c'est mon port ou s'il en faut un autre ?

Le port est indiqué dans la fiche du proxy dans l'espace client. Différents types de proxy utilisent différents ports. Vérifiez dans l'espace client et ne mettez pas un port au hasard.

Peut-on automatiser le nettoyage des logs des secrets ?

À propos de l'auteur

Roman Melnikov

Roman Melnikov

Technical Writer and System Administrator

Expérience professionnelle : 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.
Formation : Bauman Moscow State Technical University. Information Systems and Technologies
Expertise :
Technical Documentation DevOps System Administration Linux Docker and Kubernetes CI/CD Infrastructure Automation Cloud Technologies System Monitoring Bash and Python Scripting

Partagez cet article :