Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Используйте это руководство для диагностики и устранения распространенных проблем с прокси-сервером разработки. Начните с симптома и ознакомьтесь с диагностическими вопросами, чтобы найти решение.
Симптом: прокси разработки не перехватывает запросы
Вы запустили прокси-сервер разработки, но запросы приложения не отображаются в выходных данных прокси-сервера разработки. Ознакомьтесь с этими вопросами, чтобы определить причину.
Запущен ли прокси-сервер разработки?
Убедитесь, что прокси-сервер разработки запущен и готов перехватывать запросы.
Что рекомендуется отслеживать:
После запуска прокси-сервера разработки вы увидите следующие выходные данные:
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
Если вы не видите эти выходные данные:
- Убедитесь, что прокси-сервер разработки установлен правильно, выполнив команду
devproxy --version - При возникновении ошибки переустановите прокси-сервер разработки
Зарегистрирован ли прокси-сервер разработки в качестве системного прокси-сервера?
Прокси-сервер разработки должен быть зарегистрирован в качестве системного прокси-сервера для автоматического перехвата запросов. Если это не так, запросы приложения обходят Dev Proxy.
Как проверить macOS:
- Откройте Параметры системы>Сеть
- Выбор активного сетевого подключения
- Перейдите к сведениям...>Прокси
- Поиск конфигурации безопасного HTTPS-прокси, установленной в
127.0.0.1:8000
Как проверить в Windows:
- Откройте Параметры>Сеть и Интернет>Прокси
- В разделе настройки прокси-сервера вручную убедитесь, что для прокси-сервера задано значение
127.0.0.1:8000
Если прокси-сервер разработки не зарегистрирован в качестве системного прокси-сервера:
Проверьте конфигурацию прокси-сервера разработки. Запустите devproxy config , чтобы открыть файл конфигурации и убедитесь, что он не содержит:
{
"asSystemProxy": false
}
Если этот параметр существует и установлен false, удалите его или установите для него значение true, а затем перезапустите прокси-сервер разработки.
Вы просматриваете правильные URL-адреса?
Прокси-сервер разработки перехватывает запросы только на те URL-адреса, которые соответствуют шаблонам, указанным в конфигурации urlsToWatch.
Как проверить:
- Просмотрите вывод при запуске прокси-сервера для разработки, чтобы увидеть список отслеживаемых URL-адресов.
- Сравните их с 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 этот запрос.
Вы используете правильный файл конфигурации?
Прокси-сервер разработки может использовать другой файл конфигурации, отличный от ожидаемого.
Как прокси-сервер разработки находит файлы конфигурации:
- При указании
--config-fileпрокси-сервер разработки использует этот файл - В противном случае Dev Proxy ищет
devproxyrc.jsonв текущем каталоге - Если не найдено, 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 приложениями .
Быстрое исправление с помощью глобального агента:
Установите глобальный агент:
npm install global-agentДобавьте в точку входа приложения:
import { bootstrap } from 'global-agent'; bootstrap();Запустите приложение с переменными среды прокси-сервера:
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 |
Симптом: запросы перехватываются, но передаются без изменений
Прокси разработки показывает ваши запросы в выводе, но они не изменяются, не имитируются и не возвращают симулированные ошибки.
Включены ли плагины?
Убедитесь, что плагины, которые вы хотите использовать, включены в вашей конфигурации.
Как проверить:
Откройте файл конфигурации и убедитесь, что:
- Плагин указан в массиве
plugins - Подключаемый модуль имеет
"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:
- Открыть доступ к цепочке ключей
- Поиск по запросу "Прокси разработки"
- Дважды щелкните сертификат
- Расширить Trust
- Убедитесь, что для протокола SSL задано значение Always Trust
Как проверить в Windows:
- Запуск
certmgr.msc - Перейдите к Доверенным корневым центрам сертификации>\Сертификаты
- Ищите сертификат прокси-сервера разработки
Если сертификат не является доверенным:
Удалите и переустановите сертификат:
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 |
| "Образ диска базы данных неправильно сформирован" | Перестроение базы данных |
Получить дополнительную справку
Если вы не можете найти решение:
-
Включение ведения журнала отладки: запуск
devproxy --log-level debugдля подробных выходных данных - Поиск существующих вопросов: проблемы Dev Proxy на GitHub
- Запрос справки: получение справки и поддержки