Fiddler для отладки HTTP-трафика Windows-приложений и UWP: полное руководство с настройкой прокси

Установка и первоначальная настройка

Установка Fiddler Classic занимает около двух минут. Скачайте установщик с официального сайта telerik.com/fiddler и запустите его. После установки Fiddler автоматически прописывает себя как системный прокси Windows на порту 127.0.0.1:8888.

Сразу после запуска вы увидите главное окно с тремя зонами:

• Левая панель (Sessions) — список всех перехваченных запросов в реальном времени
• Правая верхняя панель — детали выбранного запроса (заголовки, тело, параметры)
• Правая нижняя панель — ответ сервера

Первое, что стоит сделать — настроить фильтрацию, иначе в список попадёт весь системный трафик Windows (обновления, телеметрия, OneDrive и т.д.), и найти нужные запросы будет сложно. Перейдите во вкладку Filters в правой части и включите Use Filters. В поле Show only the following Hosts укажите домены, которые вас интересуют.

Также рекомендуем сразу настроить автосохранение сессий: File → Capture Traffic и File → Save → All Sessions. Это позволит вернуться к записанному трафику позже и анализировать его офлайн.

Перехват HTTPS-трафика: настройка сертификата

По умолчанию Fiddler перехватывает только HTTP-трафик. Для работы с HTTPS (а это 95%+ современного трафика) нужно настроить SSL-дешифрование. Fiddler действует как Man-in-the-Middle: он генерирует свой корневой сертификат и подписывает им все HTTPS-соединения.

Пошаговая настройка HTTPS-перехвата:

1. Откройте Tools → Options → HTTPS
2. Поставьте галочку Capture HTTPS CONNECTs
3. Поставьте галочку Decrypt HTTPS traffic
4. В выпадающем списке выберите ...from all processes
5. Нажмите кнопку Actions → Trust Root Certificate
6. Подтвердите установку сертификата в системное хранилище Windows
7. Перезапустите Fiddler

После этого в колонке Protocol вы увидите HTTPS вместо CONNECT, и сможете просматривать расшифрованное содержимое запросов и ответов.

Некоторые приложения используют Certificate Pinning — они проверяют конкретный сертификат сервера и откажутся работать через Fiddler. В этом случае вы увидите ошибку подключения в приложении. Обход пиннинга — отдельная тема, выходящая за рамки этой статьи.

Как перехватить трафик UWP-приложений

UWP (Universal Windows Platform) — это приложения из Microsoft Store: Почта, Карты, Кино и ТВ, Spotify, Netflix и многие другие. Их особенность в том, что по соображениям безопасности они работают в изолированном контейнере (App Container) и не используют системный прокси. Именно поэтому обычная настройка Fiddler не перехватывает их трафик.

Для решения этой проблемы Fiddler предоставляет специальный инструмент — AppContainer Loopback Exemption Utility. Он добавляет UWP-приложение в список исключений, позволяя ему обращаться к локальному прокси Fiddler.

Способ 1 — через интерфейс Fiddler:

1. В меню выберите WinConfig (кнопка на панели инструментов или Tools → Win8 Loopback Exemptions)
2. Откроется список всех установленных UWP-приложений
3. Найдите нужное приложение и поставьте галочку напротив него
4. Нажмите Save Changes
5. Перезапустите UWP-приложение

Способ 2 — через командную строку (для автоматизации):

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

Замените Microsoft.WindowsMaps_8wekyb3d8bbwe на Package Family Name нужного приложения. Найти его можно в PowerShell командой:

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

После добавления исключения UWP-приложение начнёт отправлять трафик через Fiddler. Вы увидите его запросы в списке сессий — обычно они легко идентифицируются по User-Agent или по хосту назначения.

Фильтры, брейкпоинты и изменение запросов

Три самые мощные функции Fiddler для отладки — это фильтрация сессий, брейкпоинты и AutoResponder. Разберём каждую из них.

Фильтрация сессий

Вкладка Filters позволяет показывать только нужные запросы. Основные опции:

• Show only the following Hosts — фильтр по домену (например, api.example.com)
• Show only if URL contains — фильтр по части URL
• Show only if response Content-Type — только JSON, XML, изображения и т.д.
• Hide if URL contains — исключить шумовые запросы (например, telemetry, analytics)

Также можно использовать строку QuickExec внизу окна для быстрых команд. Например, select status 404 выделит все запросы с ошибкой 404, а bold api выделит жирным все сессии, содержащие "api" в URL.

Брейкпоинты (Breakpoints)

Брейкпоинты позволяют остановить запрос или ответ до его отправки/получения и изменить содержимое вручную. Это аналог точки останова в отладчике кода, только для HTTP.

• Rules → Automatic Breakpoints → Before Requests — останавливает каждый запрос до отправки
• Rules → Automatic Breakpoints → After Responses — останавливает каждый ответ до передачи приложению
• Правый клик на сессии → Breakpoint → Break on Request — точечный брейкпоинт на конкретный URL

Когда запрос остановлен, вы можете изменить любой заголовок, тело запроса, URL и нажать Run to Completion для продолжения. Это особенно полезно для тестирования поведения приложения при изменённых данных.

AutoResponder

AutoResponder — инструмент для подмены ответов сервера. Вы создаёте правило: "если URL совпадает с паттерном — вернуть вот этот файл/ответ". Применения:

• Тестирование приложения с заглушками API без реального бэкенда
• Симуляция ошибок сервера (500, 503, таймауты)
• Подмена ресурсов — загрузить локальную версию JS/CSS вместо серверной
• Ускорение разработки — кешировать медленные запросы к внешним API

Подключение внешнего прокси через Fiddler

Одна из важных возможностей Fiddler — работа в режиме "прокси через прокси" (upstream proxy). Fiddler перехватывает трафик локально, а затем направляет его через внешний прокси-сервер. Это позволяет одновременно отлаживать запросы и менять IP-адрес или гео-локацию.

Когда это нужно:

• Тестирование поведения приложения при работе через корпоративный прокси
• Проверка геозависимого контента — как приложение работает из другой страны
• Отладка приложения, которое само использует прокси
• Тестирование API с IP-ограничениями (whitelist по IP)

Настройка upstream proxy в Fiddler Classic:

1. Откройте Tools → Options → Gateway
2. Выберите Manual Proxy Configuration
3. В поле Proxy введите адрес прокси в формате host:port
4. Если прокси требует аутентификацию — укажите логин и пароль
5. Нажмите OK и перезапустите захват трафика

Fiddler поддерживает HTTP, HTTPS и SOCKS5 прокси в качестве upstream. Для SOCKS5 формат записи немного отличается:

socks=proxy.example.com:1080

Для задач тестирования геозависимого поведения приложений хорошо подходят резидентные прокси — они используют реальные IP домашних пользователей из нужной страны, и приложение получает ответы именно такие, какие получил бы реальный пользователь из этого региона. Это важно, если API возвращает разный контент в зависимости от гео.

Если вам нужна высокая скорость для загрузки больших объёмов данных во время отладки, подойдут прокси дата-центров — они обеспечивают стабильное соединение и минимальную задержку, что удобно при работе с тяжёлыми API.

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

Практические сценарии: парсинг, тестирование API, геообход

Разберём конкретные задачи, которые удобно решать с помощью Fiddler.

Сценарий 1: Реверс-инжиниринг API мобильного приложения

Вы хотите автоматизировать действия в приложении, но у него нет публичного API. Решение: запустить приложение на эмуляторе Android или через Windows-клиент, настроить его на использование Fiddler как прокси, и записать все запросы при выполнении нужных действий.

После записи вы получаете полную картину: эндпоинты, форматы запросов, заголовки аутентификации, токены. Эти данные можно использовать для написания собственного клиента или автоматизации через скрипты.

Сценарий 2: Отладка парсера маркетплейса

При разработке парсера для Wildberries, Ozon или других маркетплейсов часто непонятно, почему запросы блокируются. Fiddler позволяет сравнить запросы браузера (которые проходят) с запросами парсера (которые блокируются) и найти отличия в заголовках, порядке их следования, значениях cookie или TLS fingerprint.

Типичная находка: парсер отправляет заголовки в другом порядке, отсутствует Accept-Language, или User-Agent содержит версию Python. Исправив эти детали в коде парсера, вы снижаете вероятность блокировки.

Сценарий 3: Тестирование геозависимого контента

Если ваше приложение отображает разный контент пользователям из разных стран, нужно тестировать его с реальными IP из этих стран. Настройте Fiddler с upstream-прокси из нужного региона, запустите приложение — и вы увидите ровно то, что видит пользователь из этой страны, плюс полный лог всех запросов.

Сценарий 4: Мониторинг фоновой активности приложений

Хотите знать, куда "звонит" установленная программа? Запустите Fiddler, запустите программу, подождите 5-10 минут. В списке сессий появятся все хосты, к которым обращалась программа. Это полезно для аудита безопасности стороннего ПО, проверки на наличие телеметрии или нежелательных подключений.

Сценарий 5: Экспорт запросов для воспроизведения

Fiddler позволяет экспортировать перехваченные запросы в формате cURL, который можно сразу запустить в терминале или вставить в Postman. Правый клик на сессии → Copy → cURL Request. Это удобно для передачи запроса коллеге или для документирования API.

Fiddler Classic vs Fiddler Everywhere: что выбрать

Telerik поддерживает две версии продукта, и выбор между ними не всегда очевиден. Разберём ключевые отличия.

Когда выбрать Fiddler Classic: вы работаете только на Windows, вам нужна работа с UWP-приложениями, вы используете FiddlerScript для автоматизации, или вам важна полностью бесплатная версия без ограничений.

Когда выбрать Fiddler Everywhere: вы работаете на macOS или Linux, вам нужен современный интерфейс, важна командная работа с общими коллекциями запросов, или вы хотите интеграцию с CI/CD пайплайнами.

Также стоит упомянуть альтернативы: Charles Proxy (платный, популярен на macOS), mitmproxy (бесплатный, консольный, очень гибкий), Wireshark (работает на уровне пакетов, а не HTTP). Каждый инструмент имеет свои сильные стороны, но для большинства задач отладки Windows-приложений Fiddler Classic остаётся оптимальным выбором.

Типичные проблемы и их решения

При работе с Fiddler периодически возникают типовые проблемы. Вот самые распространённые и способы их решения.

Проблема: Приложение не работает при включённом Fiddler

Причины: Certificate Pinning, жёстко прописанный прокси в приложении, или приложение не доверяет сертификату Fiddler. Решения:

• Установите сертификат Fiddler в хранилище Local Machine → Trusted Root
• Проверьте, не использует ли приложение certificate pinning
• Добавьте хост в исключения SSL: Tools → Options → HTTPS → Skip Decryption for following hosts

Проблема: После закрытия Fiddler интернет не работает

Fiddler не успел снять системный прокси при аварийном завершении. Решение: откройте Параметры Windows → Сеть → Прокси и отключите ручной прокси. Или запустите Fiddler снова и закройте штатно.

Проблема: Видны только CONNECT-туннели, но не содержимое HTTPS

Не настроен HTTPS-перехват. Вернитесь к разделу про настройку сертификата и убедитесь, что галочка Decrypt HTTPS traffic включена и сертификат установлен в системное хранилище.

Проблема: Трафик UWP-приложения не появляется в Fiddler

Не добавлено loopback-исключение для этого приложения. Используйте WinConfig (описано в разделе про UWP) и перезапустите приложение после добавления исключения.

Проблема: Upstream прокси не работает (ошибка соединения)

Проверьте: правильность адреса и порта прокси, корректность логина/пароля, доступность прокси-сервера (попробуйте подключиться напрямую без Fiddler). Также убедитесь, что прокси поддерживает нужный протокол — не все HTTP-прокси поддерживают HTTPS-туннелирование.

Заключение

Fiddler — незаменимый инструмент для всех, кто работает с HTTP-трафиком Windows-приложений. Он позволяет видеть все запросы в реальном времени, изменять их на лету, тестировать поведение приложений в разных условиях и решать задачи, которые невозможно выполнить браузерными DevTools. Особенно ценна поддержка UWP-приложений через механизм loopback-исключений — это уникальная возможность, которой нет у большинства аналогов.

Для задач тестирования геозависимого поведения приложений или проверки работы через внешние прокси — настройте upstream proxy в Fiddler. Если вам нужны реальные IP из конкретных стран для корректного тестирования, обратите внимание на резидентные прокси — они обеспечивают максимально реалистичное гео и минимальный риск блокировок со стороны тестируемых сервисов.

Начните с Fiddler Classic — он бесплатный, хорошо задокументированный и покрывает 90% задач отладки на Windows. По мере роста потребностей можно перейти на Fiddler Everywhere или дополнить рабочий процесс специализированными инструментами вроде mitmproxy для более гибкой автоматизации.