Fiddler per il debug del traffico HTTP delle applicazioni Windows e UWP: guida completa alla configurazione del proxy

Installazione e configurazione iniziale

L'installazione di Fiddler Classic richiede circa due minuti. Scarica il programma di installazione dal sito ufficiale telerik.com/fiddler e avvialo. Dopo l'installazione, Fiddler si configura automaticamente come proxy di sistema di Windows sulla porta 127.0.0.1:8888.

Subito dopo l'avvio vedrai la finestra principale con tre aree:

• Pannello sinistro (Sessions) — elenco di tutte le richieste catturate in tempo reale
• Pannello in alto a destra — dettagli della richiesta selezionata (intestazioni, corpo, parametri)
• Pannello in basso a destra — risposta del server

La prima cosa da fare è configurare il filtro, altrimenti nell'elenco finirà tutto il traffico di sistema di Windows (aggiornamenti, telemetria, OneDrive, ecc.), e sarà difficile trovare le richieste necessarie. Vai alla scheda Filters nella parte destra e attiva Use Filters. Nel campo Show only the following Hosts specifica i domini che ti interessano.

Ti consigliamo anche di configurare subito il salvataggio automatico delle sessioni: File → Capture Traffic e File → Save → All Sessions. Questo ti permetterà di tornare al traffico registrato in seguito e analizzarlo offline.

Cattura del traffico HTTPS: configurazione del certificato

Per impostazione predefinita, Fiddler cattura solo il traffico HTTP. Per lavorare con HTTPS (che rappresenta oltre il 95% del traffico moderno), è necessario configurare la decrittazione SSL. Fiddler agisce come un Man-in-the-Middle: genera il proprio certificato radice e lo utilizza per firmare tutte le connessioni HTTPS.

Configurazione passo-passo della cattura HTTPS:

1. Apri Tools → Options → HTTPS
2. Seleziona Capture HTTPS CONNECTs
3. Seleziona Decrypt HTTPS traffic
4. Nel menu a discesa seleziona ...from all processes
5. Clicca sul pulsante Actions → Trust Root Certificate
6. Conferma l'installazione del certificato nel negozio di sistema di Windows
7. Riavvia Fiddler

Dopo questo, nella colonna Protocol vedrai HTTPS invece di CONNECT, e potrai visualizzare il contenuto decrittografato delle richieste e delle risposte.

Alcune applicazioni utilizzano Certificate Pinning: controllano un certificato specifico del server e si rifiuteranno di funzionare tramite Fiddler. In questo caso, vedrai un errore di connessione nell'applicazione. Il bypass del pinning è un argomento separato, che va oltre questo articolo.

Come catturare il traffico delle applicazioni UWP

UWP (Universal Windows Platform) sono le applicazioni dal Microsoft Store: Posta, Mappe, Film e TV, Spotify, Netflix e molte altre. La loro particolarità è che, per motivi di sicurezza, funzionano in un contenitore isolato (App Container) e non utilizzano il proxy di sistema. Ecco perché la configurazione standard di Fiddler non cattura il loro traffico.

Per risolvere questo problema, Fiddler fornisce uno strumento speciale: AppContainer Loopback Exemption Utility. Questo aggiunge l'app UWP all'elenco delle eccezioni, consentendole di accedere al proxy locale di Fiddler.

Metodo 1 — tramite l'interfaccia di Fiddler:

1. Nel menu seleziona WinConfig (pulsante sulla barra degli strumenti o Tools → Win8 Loopback Exemptions)
2. Si aprirà un elenco di tutte le applicazioni UWP installate
3. Trova l'applicazione desiderata e seleziona la casella accanto ad essa
4. Clicca su Save Changes
5. Riavvia l'applicazione UWP

Metodo 2 — tramite il prompt dei comandi (per automazione):

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

Sostituisci Microsoft.WindowsMaps_8wekyb3d8bbwe con il Package Family Name dell'applicazione desiderata. Puoi trovarlo in PowerShell con il comando:

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

Dopo aver aggiunto l'eccezione, l'app UWP inizierà a inviare traffico tramite Fiddler. Vedrai le sue richieste nell'elenco delle sessioni: di solito sono facilmente identificabili dal User-Agent o dall'host di destinazione.

Filtri, breakpoint e modifica delle richieste

Le tre funzionalità più potenti di Fiddler per il debug sono la filtrazione delle sessioni, i breakpoint e l'AutoResponder. Esaminiamo ciascuna di esse.

Filtrazione delle sessioni

La scheda Filters consente di mostrare solo le richieste necessarie. Le opzioni principali sono:

• Show only the following Hosts — filtro per dominio (ad esempio, api.example.com)
• Show only if URL contains — filtro per parte dell'URL
• Show only if response Content-Type — solo JSON, XML, immagini, ecc.
• Hide if URL contains — escludi le richieste di rumore (ad esempio, telemetry, analytics)

Puoi anche utilizzare la barra QuickExec in fondo alla finestra per comandi rapidi. Ad esempio, select status 404 evidenzierà tutte le richieste con errore 404, mentre bold api evidenzierà in grassetto tutte le sessioni contenenti "api" nell'URL.

Breakpoint

I breakpoint consentono di fermare una richiesta o una risposta prima che venga inviata/ricevuta e modificare manualmente il contenuto. Questo è simile a un punto di interruzione in un debugger di codice, ma per HTTP.

• Rules → Automatic Breakpoints → Before Requests — ferma ogni richiesta prima dell'invio
• Rules → Automatic Breakpoints → After Responses — ferma ogni risposta prima della trasmissione all'applicazione
• Click destro sulla sessione → Breakpoint → Break on Request — breakpoint puntuale su un URL specifico

Quando la richiesta è ferma, puoi modificare qualsiasi intestazione, corpo della richiesta, URL e premere Run to Completion per continuare. Questo è particolarmente utile per testare il comportamento dell'applicazione con dati modificati.

AutoResponder

AutoResponder è uno strumento per sostituire le risposte del server. Crei una regola: "se l'URL corrisponde al pattern — restituisci questo file/risposta". Applicazioni:

• Testare l'applicazione con stub API senza un backend reale
• Simulare errori del server (500, 503, timeout)
• Sostituire le risorse — caricare una versione locale di JS/CSS invece di quella del server
• Accelerare lo sviluppo — memorizzare nella cache richieste lente a API esterne

Connessione a un proxy esterno tramite Fiddler

Una delle funzionalità importanti di Fiddler è il funzionamento in modalità "proxy attraverso proxy" (upstream proxy). Fiddler cattura il traffico localmente e poi lo inoltra attraverso un server proxy esterno. Questo consente di debuggare le richieste e cambiare l'indirizzo IP o la geolocalizzazione contemporaneamente.

Quando è necessario:

• Testare il comportamento dell'applicazione quando si utilizza un proxy aziendale
• Verificare contenuti geo-dipendenti — come funziona l'applicazione da un altro paese
• Debug dell'applicazione che utilizza un proxy
• Testare API con limitazioni IP (whitelist per IP)

Configurazione del proxy upstream in Fiddler Classic:

1. Apri Tools → Options → Gateway
2. Seleziona Manual Proxy Configuration
3. Nel campo Proxy inserisci l'indirizzo del proxy nel formato host:port
4. Se il proxy richiede autenticazione, specifica nome utente e password
5. Clicca su OK e riavvia la cattura del traffico

Fiddler supporta proxy HTTP, HTTPS e SOCKS5 come upstream. Per SOCKS5, il formato di registrazione è leggermente diverso:

socks=proxy.example.com:1080

Per testare il comportamento geo-dipendente delle applicazioni, i proxy residenziali sono molto utili: utilizzano IP reali di utenti domestici nel paese desiderato, e l'applicazione riceve risposte proprio come farebbe un utente reale di quella regione. Questo è importante se l'API restituisce contenuti diversi a seconda della geolocalizzazione.

Se hai bisogno di alta velocità per scaricare grandi volumi di dati durante il debug, i proxy di data center sono adatti: offrono una connessione stabile e una latenza minima, il che è comodo quando si lavora con API pesanti.

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

Scenari pratici: parsing, test delle API, geo-bypass

Esaminiamo compiti specifici che è conveniente risolvere con Fiddler.

Scenario 1: Reverse engineering delle API di un'app mobile

Vuoi automatizzare le azioni in un'applicazione, ma non ha un'API pubblica. Soluzione: avvia l'app su un emulatore Android o tramite il client Windows, configurala per utilizzare Fiddler come proxy e registra tutte le richieste mentre esegui le azioni necessarie.

Dopo la registrazione, ottieni un quadro completo: endpoint, formati delle richieste, intestazioni di autenticazione, token. Questi dati possono essere utilizzati per scrivere il proprio client o per automatizzare tramite script.

Scenario 2: Debug del parser di un marketplace

Durante lo sviluppo di un parser per Wildberries, Ozon o altri marketplace, spesso non è chiaro perché le richieste vengano bloccate. Fiddler consente di confrontare le richieste del browser (che passano) con quelle del parser (che vengono bloccate) e trovare differenze nelle intestazioni, nell'ordine in cui appaiono, nei valori dei cookie o nel fingerprint TLS.

Una scoperta tipica: il parser invia le intestazioni in un ordine diverso, manca Accept-Language, o User-Agent contiene la versione di Python. Correggendo questi dettagli nel codice del parser, riduci la probabilità di blocco.

Scenario 3: Testare contenuti geo-dipendenti

Se la tua applicazione mostra contenuti diversi agli utenti di diversi paesi, è necessario testarla con IP reali di quei paesi. Configura Fiddler con un proxy upstream della regione desiderata, avvia l'applicazione e vedrai esattamente ciò che vede un utente di quel paese, oltre a un log completo di tutte le richieste.

Scenario 4: Monitoraggio dell'attività in background delle applicazioni

Vuoi sapere dove "chiama" un programma installato? Avvia Fiddler, avvia il programma e aspetta 5-10 minuti. Nell'elenco delle sessioni appariranno tutti gli host a cui si è rivolto il programma. Questo è utile per l'audit della sicurezza del software di terze parti, per verificare la presenza di telemetria o connessioni indesiderate.

Scenario 5: Esportazione delle richieste per riproduzione

Fiddler consente di esportare le richieste catturate nel formato cURL, che può essere immediatamente eseguito nel terminale o incollato in Postman. Clicca destro sulla sessione → Copy → cURL Request. Questo è comodo per trasferire una richiesta a un collega o per documentare l'API.

Fiddler Classic vs Fiddler Everywhere: cosa scegliere

Telerik supporta due versioni del prodotto e la scelta tra di esse non è sempre ovvia. Esaminiamo le differenze chiave.

Quando scegliere Fiddler Classic: lavori solo su Windows, hai bisogno di lavorare con applicazioni UWP, utilizzi FiddlerScript per l'automazione o desideri una versione completamente gratuita senza limitazioni.

Quando scegliere Fiddler Everywhere: lavori su macOS o Linux, hai bisogno di un'interfaccia moderna, è importante la collaborazione con collezioni condivise di richieste o desideri integrazione con pipeline CI/CD.

Vale anche la pena menzionare alternative: Charles Proxy (a pagamento, popolare su macOS), mitmproxy (gratuito, console, molto flessibile), Wireshark (funziona a livello di pacchetti, non HTTP). Ogni strumento ha i suoi punti di forza, ma per la maggior parte delle attività di debug delle applicazioni Windows, Fiddler Classic rimane la scelta ottimale.

Problemi tipici e loro soluzioni

Quando si lavora con Fiddler, possono sorgere periodicamente problemi tipici. Ecco i più comuni e come risolverli.

Problema: L'app non funziona con Fiddler attivo

Cause: Certificate Pinning, proxy hardcoded nell'applicazione, o l'app non si fida del certificato di Fiddler. Soluzioni:

• Installa il certificato di Fiddler nel negozio Local Machine → Trusted Root
• Controlla se l'app utilizza il certificate pinning
• Aggiungi l'host alle eccezioni SSL: Tools → Options → HTTPS → Skip Decryption for following hosts

Problema: Dopo la chiusura di Fiddler, Internet non funziona

Fiddler non è riuscito a rimuovere il proxy di sistema a causa di una chiusura anomala. Soluzione: apri Impostazioni Windows → Rete → Proxy e disattiva il proxy manuale. Oppure riavvia Fiddler e chiudilo normalmente.

Problema: Vedi solo tunnel CONNECT, ma non il contenuto HTTPS

La cattura HTTPS non è configurata. Torna alla sezione sulla configurazione del certificato e assicurati che l'opzione Decrypt HTTPS traffic sia attivata e che il certificato sia installato nel negozio di sistema.

Problema: Il traffico dell'app UWP non appare in Fiddler

Non è stata aggiunta l'eccezione loopback per questa applicazione. Usa WinConfig (descritto nella sezione su UWP) e riavvia l'app dopo aver aggiunto l'eccezione.

Problema: Il proxy upstream non funziona (errore di connessione)

Controlla: correttezza dell'indirizzo e della porta del proxy, correttezza di nome utente/password, disponibilità del server proxy (prova a connetterti direttamente senza Fiddler). Assicurati anche che il proxy supporti il protocollo necessario: non tutti i proxy HTTP supportano il tunneling HTTPS.

Conclusione

Fiddler è uno strumento indispensabile per chiunque lavori con il traffico HTTP delle applicazioni Windows. Ti consente di vedere tutte le richieste in tempo reale, modificarle al volo, testare il comportamento delle applicazioni in diverse condizioni e risolvere problemi che non possono essere affrontati con gli DevTools del browser. È particolarmente preziosa la supporto per le applicazioni UWP tramite il meccanismo delle eccezioni loopback: questa è un'opportunità unica che non hanno la maggior parte delle alternative.

Per testare il comportamento geo-dipendente delle applicazioni o verificare il funzionamento tramite proxy esterni, configura il proxy upstream in Fiddler. Se hai bisogno di IP reali da paesi specifici per testare correttamente, dai un'occhiata ai proxy residenziali: offrono la geolocalizzazione più realistica e il rischio minimo di blocchi da parte dei servizi testati.

Inizia con Fiddler Classic: è gratuito, ben documentato e copre il 90% delle attività di debug su Windows. Man mano che crescono le esigenze, puoi passare a Fiddler Everywhere o integrare il tuo flusso di lavoro con strumenti specializzati come mitmproxy per un'automazione più flessibile.