Устранение неполадок с прокси-сервером разработки

Используйте это руководство для диагностики и устранения распространенных проблем с прокси-сервером разработки. Начните с симптома и ознакомьтесь с диагностическими вопросами, чтобы найти решение.

Симптом: прокси разработки не перехватывает запросы

Вы запустили прокси-сервер разработки, но запросы приложения не отображаются в выходных данных прокси-сервера разработки. Ознакомьтесь с этими вопросами, чтобы определить причину.

Запущен ли прокси-сервер разработки?

Убедитесь, что прокси-сервер разработки запущен и готов перехватывать запросы.

Что рекомендуется отслеживать:

После запуска прокси-сервера разработки вы увидите следующие выходные данные:

 info    Dev Proxy API listening on http://127.0.0.1:8897...
 info    Dev Proxy listening on 127.0.0.1:8000...

Hotkeys: issue (w)eb request, (r)ecord, (s)top recording, (c)lear screen
Press CTRL+C to stop Dev Proxy

Если вы не видите эти выходные данные:

Зарегистрирован ли прокси-сервер разработки в качестве системного прокси-сервера?

Прокси-сервер разработки должен быть зарегистрирован в качестве системного прокси-сервера для автоматического перехвата запросов. Если это не так, запросы приложения обходят Dev Proxy.

Как проверить macOS:

  1. Откройте Параметры системы>Сеть
  2. Выбор активного сетевого подключения
  3. Перейдите к сведениям...>Прокси
  4. Поиск конфигурации безопасного HTTPS-прокси, установленной в 127.0.0.1:8000

Как проверить в Windows:

  1. Откройте Параметры>Сеть и Интернет>Прокси
  2. В разделе настройки прокси-сервера вручную убедитесь, что для прокси-сервера задано значение 127.0.0.1:8000

Если прокси-сервер разработки не зарегистрирован в качестве системного прокси-сервера:

Проверьте конфигурацию прокси-сервера разработки. Запустите devproxy config , чтобы открыть файл конфигурации и убедитесь, что он не содержит:

{
  "asSystemProxy": false
}

Если этот параметр существует и установлен false, удалите его или установите для него значение true, а затем перезапустите прокси-сервер разработки.

Вы просматриваете правильные URL-адреса?

Прокси-сервер разработки перехватывает запросы только на те URL-адреса, которые соответствуют шаблонам, указанным в конфигурации urlsToWatch.

Как проверить:

  1. Просмотрите вывод при запуске прокси-сервера для разработки, чтобы увидеть список отслеживаемых URL-адресов.
  2. Сравните их с URL-адресом, вызываемого приложением

Распространенные проблемы:

  • Отсутствующие подстановочные знаки: https://api.example.com не соответствует https://api.example.com/users. Вместо этого используйте https://api.example.com/*.
  • Неправильный домен: дважды проверьте доменное имя, включая поддомены
  • HTTP и HTTPS: убедитесь, что протокол соответствует

Чтобы проверить шаблон URL-адреса, выполните приведенные действия.

devproxy --urls-to-watch "https://your-api.com/*"

Затем выполните запрос к API и проверьте, регистрирует ли Dev Proxy этот запрос.

Вы используете правильный файл конфигурации?

Прокси-сервер разработки может использовать другой файл конфигурации, отличный от ожидаемого.

Как прокси-сервер разработки находит файлы конфигурации:

  1. При указании --config-fileпрокси-сервер разработки использует этот файл
  2. В противном случае Dev Proxy ищет devproxyrc.json в текущем каталоге
  3. Если не найдено, Dev Proxy использует параметры по умолчанию

Чтобы проверить, какой файл конфигурации используется:

Запустите прокси-сервер разработки с ведением журнала отладки:

devproxy --log-level debug

Найдите выходные данные, показывающие, какой файл конфигурации загружен.

Чтобы явно указать файл конфигурации:

devproxy --config-file ./my-config.json

Используете ли вы Dev Proxy с приложением Node.js?

Node.js не использует параметры системного прокси-сервера автоматически. Необходимо настроить приложение Node.js для явного использования прокси-сервера.

Solution:

global-agent Используйте пакет или настройте библиотеку HTTP для использования прокси-сервера. Подробные инструкции см. в статье "Использование прокси-сервера разработки" с Node.js приложениями .

Быстрое исправление с помощью глобального агента:

  1. Установите глобальный агент:

    npm install global-agent
    
  2. Добавьте в точку входа приложения:

    import { bootstrap } from 'global-agent';
    bootstrap();
    
  3. Запустите приложение с переменными среды прокси-сервера:

    NODE_TLS_REJECT_UNAUTHORIZED=0 GLOBAL_AGENT_HTTP_PROXY=http://127.0.0.1:8000 node app.js
    

Вы используете прокси-сервер разработки с PowerShell в Windows?

PowerShell не использует автоматически параметры системного прокси-сервера для веб-запросов, сделанных с помощью Invoke-WebRequest или Invoke-RestMethod.

Solution:

Настройте PowerShell для использования прокси-сервера -Proxy , задав параметр:

Invoke-WebRequest -Uri "https://api.example.com/data" -Proxy "http://127.0.0.1:8000"

Или задайте прокси-сервер для всего сеанса:

$env:HTTPS_PROXY = "http://127.0.0.1:8000"
$env:HTTP_PROXY = "http://127.0.0.1:8000"

Если вы используете PowerShell 7+, вы также можете использовать следующее:

[System.Net.WebRequest]::DefaultWebProxy = New-Object System.Net.WebProxy("http://127.0.0.1:8000")

Другие платформы и фреймворки

Если вы используете другие платформы, ознакомьтесь со следующими руководствами:

Platform Guide
Приложения .NET Использование прокси-сервера разработки с приложениями .NET
Приложения .NET 4.8 Для приложений .NET 4.8 требуется специальная настройка
Контейнеры Docker Использование прокси-сервера разработки в контейнере Docker
SharePoint Framework Использование прокси-сервера разработки с SPFx

Симптом: запросы перехватываются, но передаются без изменений

Прокси разработки показывает ваши запросы в выводе, но они не изменяются, не имитируются и не возвращают симулированные ошибки.

Включены ли плагины?

Убедитесь, что плагины, которые вы хотите использовать, включены в вашей конфигурации.

Как проверить:

Откройте файл конфигурации и убедитесь, что:

  1. Плагин указан в массиве plugins
  2. Подключаемый модуль имеет "enabled": true
{
  "plugins": [
    {
      "name": "GenericRandomErrorPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll"
    }
  ]
}

Ваши подключаемые модули расположены в правильном порядке?

Порядок подключаемых модулей имеет значение в DevProxy. Подключаемые модули выполняются в том порядке, в каком порядке они перечислены, и некоторые подключаемые модули могут прекратить обработку до запуска других.

Распространенные проблемы:

Если у вас есть MockResponsePlugin перед GenericRandomErrorPlugin, и мок соответствует вашему запросу, плагин случайной ошибки никогда не запускается.

Solution:

Расположите подключаемые модули в порядке, в котором они будут обрабатывать запросы. Дополнительные сведения см. в статье "Почему случайные ошибки не возникают при использовании макетов?".

Соответствует ли шаблон URL-адреса макета запросу?

Для макетных ответов шаблон URL-адреса должен точно соответствовать URL-адресу запроса.

Действия, которые необходимо проверить:

  • Параметры строки запроса: https://api.example.com/users?id=1 не соответствует https://api.example.com/users
  • Косая черта: https://api.example.com/users/ не соответствует https://api.example.com/users
  • Чувствительность к регистру: пути URL чувствительны к регистру

Правильно ли метод запроса?

Макеты зависят от метода. Макет запросов GET не соответствует POST запросам.

Как проверить:

В файле макетов убедитесь, что свойство соответствует вашему запросу method :

{
  "request": {
    "url": "https://api.example.com/users",
    "method": "GET"
  },
  "response": {
    "statusCode": 200,
    "body": { "users": [] }
  }
}

Симптом: ошибки SSL/certificate в приложении

Ваше приложение выдает ошибки SSL или сертификата при попытке выполнить запросы через Dev Proxy.

Установлен ли сертификат прокси-сервера разработки?

Dev Proxy использует самоподписанный сертификат для расшифровки трафика HTTPS. Ваша система должна доверять этому сертификату.

Solution:

Выполните команду установки сертификата:

devproxy cert ensure

Эта команда устанавливает и доверяет сертификат прокси-разработки на вашей системе.

Является ли сертификат доверенным?

Сертификат может быть установлен, но не является доверенным.

Как проверить macOS:

  1. Открыть доступ к цепочке ключей
  2. Поиск по запросу "Прокси разработки"
  3. Дважды щелкните сертификат
  4. Расширить Trust
  5. Убедитесь, что для протокола SSL задано значение Always Trust

Как проверить в Windows:

  1. Запуск certmgr.msc
  2. Перейдите к Доверенным корневым центрам сертификации>\Сертификаты
  3. Ищите сертификат прокси-сервера разработки

Если сертификат не является доверенным:

Удалите и переустановите сертификат:

devproxy cert remove
devproxy cert ensure

Вы используете Node.js?

Node.js по умолчанию не использует хранилище системных сертификатов. Вам нужно выполнить следующие действия:

Вариант 1. Отключение проверки сертификатов (только для разработки):

NODE_TLS_REJECT_UNAUTHORIZED=0 node app.js

Предупреждение

Никогда не используется NODE_TLS_REJECT_UNAUTHORIZED=0 в рабочей среде. Он отключает все проверки сертификатов.

Вариант 2. Добавление сертификата прокси-сервера разработки в Node.js:

Экспортируйте сертификат прокси-сервера разработки и задайте NODE_EXTRA_CA_CERTS переменную среды:

NODE_EXTRA_CA_CERTS=/path/to/devproxy-cert.pem node app.js

Вы используете другую среду выполнения или платформу?

Разные платформы обрабатывают сертификаты по-разному:

Platform Solution
Питон Используйте переменные среды REQUESTS_CA_BUNDLE или SSL_CERT_FILE
Ява Импорт сертификата в хранилище ключей Java с помощью keytool
.NET Сертификат обычно является доверенным через системное хранилище
Докер Установите сертификат и обновите списки сертификатов ЦС в контейнере.

Другие распространенные проблемы.

Все запросы завершаются сбоем при истечении времени ожидания шлюза

Причина.

Прокси-сервер разработки не может достичь целевого API.

Solution:

См. раздел "Почему все запросы завершаются сбоем при истечении времени ожидания шлюза"?

Отсутствие подключения к интернету после использования прокси-сервера разработчика

Причина.

Разработческий прокси-сервер неправильно отменяет регистрацию как системный прокси.

Solution:

См. статью "Почему подключение к Интернету не работает после использования прокси-сервера?

Неожиданное получение ответов 429

Причина.

Включены и настроены плагины для ограничения скорости.

Solution:

Узнайте , почему я продолжаю получать 429 ответов?

Ошибки базы данных

Ошибка Solution
Ошибка инициализации SqliteConnection Исправление конфигурации SQLite
"Образ диска базы данных неправильно сформирован" Перестроение базы данных

Получить дополнительную справку

Если вы не можете найти решение:

  1. Включение ведения журнала отладки: запуск devproxy --log-level debug для подробных выходных данных
  2. Поиск существующих вопросов: проблемы Dev Proxy на GitHub
  3. Запрос справки: получение справки и поддержки

См. также