Fiddler pour déboguer le trafic HTTP des applications Windows et UWP : guide complet de configuration du proxy

Installation et configuration initiale

L'installation de Fiddler Classic prend environ deux minutes. Téléchargez l'installateur depuis le site officiel telerik.com/fiddler et lancez-le. Après l'installation, Fiddler s'enregistre automatiquement comme proxy système Windows sur le port 127.0.0.1:8888.

Dès le lancement, vous verrez la fenêtre principale avec trois zones :

• Panneau gauche (Sessions) - liste de toutes les requêtes interceptées en temps réel
• Panneau supérieur droit - détails de la requête sélectionnée (en-têtes, corps, paramètres)
• Panneau inférieur droit - réponse du serveur

La première chose à faire est de configurer le filtrage, sinon la liste contiendra tout le trafic système Windows (mises à jour, télémétrie, OneDrive, etc.), et il sera difficile de trouver les requêtes nécessaires. Allez dans l'onglet Filters à droite et activez Use Filters. Dans le champ Show only the following Hosts, indiquez les domaines qui vous intéressent.

Nous vous recommandons également de configurer l'enregistrement automatique des sessions : File → Capture Traffic et File → Save → All Sessions. Cela vous permettra de revenir au trafic enregistré plus tard et de l'analyser hors ligne.

Interception du trafic HTTPS : configuration du certificat

Par défaut, Fiddler n'intercepte que le trafic HTTP. Pour travailler avec HTTPS (qui représente plus de 95 % du trafic moderne), il est nécessaire de configurer le déchiffrement SSL. Fiddler agit comme un homme du milieu : il génère son propre certificat racine et signe toutes les connexions HTTPS avec.

Configuration étape par étape de l'interception HTTPS :

1. Ouvrez Tools → Options → HTTPS
2. Cochez Capture HTTPS CONNECTs
3. Cochez Decrypt HTTPS traffic
4. Dans le menu déroulant, sélectionnez ...from all processes
5. Cliquez sur le bouton Actions → Trust Root Certificate
6. Confirmez l'installation du certificat dans le magasin de certificats Windows
7. Redémarrez Fiddler

Après cela, dans la colonne Protocol, vous verrez HTTPS au lieu de CONNECT, et vous pourrez visualiser le contenu déchiffré des requêtes et des réponses.

Certaines applications utilisent le Certificate Pinning - elles vérifient un certificat de serveur spécifique et refuseront de fonctionner via Fiddler. Dans ce cas, vous verrez une erreur de connexion dans l'application. Contourner le pinning est un sujet distinct, qui dépasse le cadre de cet article.

Comment intercepter le trafic des applications UWP

UWP (Universal Windows Platform) désigne les applications du Microsoft Store : Mail, Cartes, Films et TV, Spotify, Netflix et bien d'autres. Leur particularité est qu'elles fonctionnent dans un conteneur isolé (App Container) pour des raisons de sécurité et n'utilisent pas le proxy système. C'est pourquoi la configuration standard de Fiddler n'intercepte pas leur trafic.

Pour résoudre ce problème, Fiddler fournit un outil spécial - AppContainer Loopback Exemption Utility. Il ajoute l'application UWP à la liste des exceptions, lui permettant d'accéder au proxy local de Fiddler.

Méthode 1 - via l'interface de Fiddler :

1. Dans le menu, sélectionnez WinConfig (bouton dans la barre d'outils ou Tools → Win8 Loopback Exemptions)
2. Une liste de toutes les applications UWP installées s'ouvrira
3. Trouvez l'application souhaitée et cochez la case à côté
4. Cliquez sur Save Changes
5. Redémarrez l'application UWP

Méthode 2 - via l'invite de commande (pour automatisation) :

CheckNetIsolation LoopbackExempt -a -n="Microsoft.WindowsMaps_8wekyb3d8bbwe"

Remplacez Microsoft.WindowsMaps_8wekyb3d8bbwe par le nom de la famille de packages de l'application souhaitée. Vous pouvez le trouver dans PowerShell avec la commande :

Get-AppxPackage | Select-Object Name, PackageFamilyName | Sort-Object Name

Après avoir ajouté l'exception, l'application UWP commencera à envoyer du trafic via Fiddler. Vous verrez ses requêtes dans la liste des sessions - elles sont généralement facilement identifiables par l'User-Agent ou par l'hôte de destination.

Filtres, points d'arrêt et modification des requêtes

Les trois fonctionnalités les plus puissantes de Fiddler pour le débogage sont le filtrage des sessions, les points d'arrêt et l'AutoResponder. Examinons chacune d'elles.

Filtrage des sessions

L'onglet Filters permet d'afficher uniquement les requêtes nécessaires. Options principales :

• Show only the following Hosts - filtre par domaine (par exemple, api.example.com)
• Show only if URL contains - filtre par partie de l'URL
• Show only if response Content-Type - uniquement JSON, XML, images, etc.
• Hide if URL contains - exclure les requêtes de bruit (par exemple, telemetry, analytics)

Vous pouvez également utiliser la ligne QuickExec en bas de la fenêtre pour des commandes rapides. Par exemple, select status 404 mettra en surbrillance toutes les requêtes avec une erreur 404, tandis que bold api mettra en gras toutes les sessions contenant "api" dans l'URL.

Points d'arrêt (Breakpoints)

Les points d'arrêt permettent d'arrêter une requête ou une réponse avant son envoi/réception et de modifier le contenu manuellement. C'est l'équivalent d'un point d'arrêt dans un débogueur de code, mais pour HTTP.

• Rules → Automatic Breakpoints → Before Requests - arrête chaque requête avant l'envoi
• Rules → Automatic Breakpoints → After Responses - arrête chaque réponse avant de la transmettre à l'application
• Clic droit sur la session → Breakpoint → Break on Request - point d'arrêt ponctuel sur une URL spécifique

Lorsque la requête est arrêtée, vous pouvez modifier n'importe quel en-tête, le corps de la requête, l'URL et cliquer sur Run to Completion pour continuer. Cela est particulièrement utile pour tester le comportement de l'application avec des données modifiées.

AutoResponder

AutoResponder est un outil pour remplacer les réponses du serveur. Vous créez une règle : "si l'URL correspond au modèle - renvoyer ce fichier/réponse". Applications :

• Tester l'application avec des mocks d'API sans backend réel
• Simuler des erreurs de serveur (500, 503, délais d'attente)
• Remplacer des ressources - charger une version locale de JS/CSS au lieu de la version serveur
• Accélérer le développement - mettre en cache des requêtes lentes vers des API externes

Connexion à un proxy externe via Fiddler

L'une des fonctionnalités importantes de Fiddler est de fonctionner en mode "proxy via proxy" (upstream proxy). Fiddler intercepte le trafic localement, puis le redirige via un serveur proxy externe. Cela permet de déboguer simultanément les requêtes et de changer l'adresse IP ou la géolocalisation.

Quand cela est-il nécessaire :

• Tester le comportement de l'application lorsqu'elle fonctionne via un proxy d'entreprise
• Vérifier le contenu géo-dépendant - comment l'application fonctionne depuis un autre pays
• Déboguer une application qui utilise elle-même un proxy
• Tester des API avec des restrictions IP (whitelist par IP)

Configuration du proxy upstream dans Fiddler Classic :

1. Ouvrez Tools → Options → Gateway
2. Sélectionnez Manual Proxy Configuration
3. Dans le champ Proxy, entrez l'adresse du proxy au format host:port
4. Si le proxy nécessite une authentification, indiquez le nom d'utilisateur et le mot de passe
5. Cliquez sur OK et redémarrez la capture de trafic

Fiddler prend en charge les proxies HTTP, HTTPS et SOCKS5 en tant que upstream. Pour SOCKS5, le format d'enregistrement est légèrement différent :

socks=proxy.example.com:1080

Pour les tâches de test du comportement géo-dépendant des applications, les proxies résidentiels sont très adaptés - ils utilisent de véritables IP d'utilisateurs domestiques du pays souhaité, et l'application reçoit des réponses exactement comme un véritable utilisateur de cette région. Cela est important si l'API renvoie un contenu différent selon la géolocalisation.

Si vous avez besoin d'une vitesse élevée pour télécharger de grandes quantités de données lors du débogage, les proxies de datacenter sont appropriés - ils offrent une connexion stable et un minimum de latence, ce qui est pratique lors du travail avec des API lourdes.

static function OnBeforeRequest(oSession: Session) {
  if (oSession.HostnameIs("api.us-service.com")) {
    oSession["x-OverrideGateway"] = "us-proxy.example.com:8080";
  }
}

Scénarios pratiques : parsing, test d'API, contournement géographique

Examinons des tâches spécifiques que Fiddler facilite.

Scénario 1 : Reverse engineering de l'API d'une application mobile

Vous souhaitez automatiser des actions dans une application, mais elle n'a pas d'API publique. Solution : lancez l'application sur un émulateur Android ou via un client Windows, configurez-la pour utiliser Fiddler comme proxy, et enregistrez toutes les requêtes lors de l'exécution des actions nécessaires.

Après l'enregistrement, vous obtenez une vue complète : points de terminaison, formats de requêtes, en-têtes d'authentification, jetons. Ces données peuvent être utilisées pour écrire votre propre client ou automatiser via des scripts.

Scénario 2 : Débogage d'un parser de marketplace

Lors du développement d'un parser pour Wildberries, Ozon ou d'autres marketplaces, il est souvent difficile de comprendre pourquoi les requêtes sont bloquées. Fiddler permet de comparer les requêtes du navigateur (qui passent) avec celles du parser (qui sont bloquées) et de trouver des différences dans les en-têtes, l'ordre de leur apparition, les valeurs des cookies ou le TLS fingerprint.

Découverte typique : le parser envoie les en-têtes dans un ordre différent, manque le Accept-Language, ou le User-Agent contient la version de Python. En corrigeant ces détails dans le code du parser, vous réduisez la probabilité de blocage.

Scénario 3 : Test du contenu géo-dépendant

Si votre application affiche un contenu différent aux utilisateurs de différents pays, vous devez la tester avec de véritables IP de ces pays. Configurez Fiddler avec un proxy upstream de la région souhaitée, lancez l'application - et vous verrez exactement ce que voit un utilisateur de ce pays, plus le journal complet de toutes les requêtes.

Scénario 4 : Surveillance de l'activité en arrière-plan des applications

Vous voulez savoir où "appelle" un programme installé ? Lancez Fiddler, démarrez le programme, attendez 5-10 minutes. La liste des sessions affichera tous les hôtes auxquels le programme a accédé. C'est utile pour l'audit de sécurité des logiciels tiers, la vérification de la télémétrie ou des connexions indésirables.

Scénario 5 : Exportation des requêtes pour reproduction

Fiddler permet d'exporter les requêtes interceptées au format cURL, qui peut être immédiatement exécuté dans le terminal ou collé dans Postman. Clic droit sur la session → Copy → cURL Request. C'est pratique pour transmettre une requête à un collègue ou pour documenter une API.

Fiddler Classic vs Fiddler Everywhere : que choisir

Telerik prend en charge deux versions du produit, et le choix entre elles n'est pas toujours évident. Examinons les principales différences.

Quand choisir Fiddler Classic : vous travaillez uniquement sur Windows, vous avez besoin de travailler avec des applications UWP, vous utilisez FiddlerScript pour l'automatisation, ou vous souhaitez une version entièrement gratuite sans restrictions.

Quand choisir Fiddler Everywhere : vous travaillez sur macOS ou Linux, vous avez besoin d'une interface moderne, la collaboration avec des collections de requêtes partagées est importante, ou vous souhaitez une intégration avec des pipelines CI/CD.

Il convient également de mentionner des alternatives : Charles Proxy (payant, populaire sur macOS), mitmproxy (gratuit, en ligne de commande, très flexible), Wireshark (fonctionne au niveau des paquets, et non HTTP). Chaque outil a ses points forts, mais pour la plupart des tâches de débogage des applications Windows, Fiddler Classic reste le choix optimal.

Problèmes typiques et leurs solutions

Lors de l'utilisation de Fiddler, des problèmes typiques peuvent survenir. Voici les plus courants et comment les résoudre.

Problème : L'application ne fonctionne pas avec Fiddler activé

Causes : Certificate Pinning, proxy codé en dur dans l'application, ou l'application ne fait pas confiance au certificat Fiddler. Solutions :

• Installez le certificat Fiddler dans le magasin Local Machine → Trusted Root
• Vérifiez si l'application utilise le certificate pinning
• Ajoutez l'hôte aux exceptions SSL : Tools → Options → HTTPS → Skip Decryption for following hosts

Problème : Après la fermeture de Fiddler, Internet ne fonctionne pas

Fiddler n'a pas eu le temps de désactiver le proxy système lors d'une fermeture inattendue. Solution : ouvrez Paramètres Windows → Réseau → Proxy et désactivez le proxy manuel. Ou relancez Fiddler et fermez-le normalement.

Problème : Seules les tunnels CONNECT sont visibles, mais pas le contenu HTTPS

L'interception HTTPS n'est pas configurée. Revenez à la section sur la configuration du certificat et assurez-vous que la case Decrypt HTTPS traffic est cochée et que le certificat est installé dans le magasin système.

Problème : Le trafic de l'application UWP n'apparaît pas dans Fiddler

Aucune exception de loopback n'a été ajoutée pour cette application. Utilisez WinConfig (décrit dans la section sur UWP) et redémarrez l'application après avoir ajouté l'exception.

Problème : Le proxy upstream ne fonctionne pas (erreur de connexion)

Vérifiez : l'exactitude de l'adresse et du port du proxy, la validité du nom d'utilisateur/mot de passe, la disponibilité du serveur proxy (essayez de vous connecter directement sans Fiddler). Assurez-vous également que le proxy prend en charge le protocole requis - tous les proxies HTTP ne prennent pas en charge le tunneling HTTPS.

Conclusion

Fiddler est un outil indispensable pour tous ceux qui travaillent avec le trafic HTTP des applications Windows. Il permet de voir toutes les requêtes en temps réel, de les modifier à la volée, de tester le comportement des applications dans différentes conditions et de résoudre des tâches impossibles à réaliser avec les DevTools du navigateur. Le support des applications UWP via le mécanisme d'exceptions de loopback est particulièrement précieux - c'est une opportunité unique qui n'est pas offerte par la plupart des alternatives.

Pour les tâches de test du comportement géo-dépendant des applications ou pour vérifier le fonctionnement via des proxies externes - configurez le proxy upstream dans Fiddler. Si vous avez besoin de véritables IP de pays spécifiques pour des tests corrects, portez une attention particulière aux proxies résidentiels - ils offrent une géolocalisation réaliste et un risque minimal de blocage de la part des services testés.

Commencez avec Fiddler Classic - il est gratuit, bien documenté et couvre 90 % des tâches de débogage sur Windows. Au fur et à mesure que vos besoins augmentent, vous pouvez passer à Fiddler Everywhere ou compléter votre flux de travail avec des outils spécialisés comme mitmproxy pour une automatisation plus flexible.