NO_PROXY: как окружение меняет маршрут отдельного процесса

Основная идея

HTTP_PROXY, HTTPS_PROXY и NO_PROXY являются соглашениями приложений, а не одной обязательной сетевой настройкой. Регистр имён, leading dot, wildcard, CIDR и port matching поддерживаются по-разному, поэтому список нельзя переносить без теста.

В автоматизации тема «NO_PROXY: как окружение меняет маршрут отдельного процесса» должна стать воспроизводимым сценарием, а не набором бесконечных повторов. Заранее задайте входные данные, ожидаемое состояние, общий таймаут, лимит параллельности и условие остановки. Прокси является одной зависимостью сценария; ошибку страницы, браузера или тестовых данных нужно отличать от ошибки канала.

Что подтверждает первичный источник

Сравниваем родительский процесс, дочерний процесс и контейнер и ловим различия синтаксиса host, suffix, port, IPv4 и IPv6.

Первичный источник «everything curl — proxy environment, curl manual, Docker CLI proxy configuration, Docker daemon proxy configuration, dockerd reference» задаёт техническую основу, но не описывает конфигурацию каждого клиента и поставщика. Читайте нормативную формулировку рядом с датой и версией документа, затем подтверждайте поведение в своей программе. Если интерфейс обещает больше, чем источник, помечайте это как свойство продукта, которое нужно проверить отдельно.

Практический стенд

Таблица NO_PROXY включает exact host, suffix, host:port и loopback. Выполните curl и контейнерный минимальный клиент по всем endpoints, затем измените одну запись и перезапустите только часть процессов. Отрицательный тест должен показать старое окружение в неперезапущенном процессе, а не случайное «прокси работает через раз».

Проверка шаг за шагом

Создайте четыре своих endpoints: exact host, subdomain, другой port и IPv6. Запустите один клиент в чистом environment, второй с proxy variables и третий как child process. Для каждого проверьте exit marker и вывод фактически распознанной конфигурации без secret.

Начните с одного разрешённого URL и одной прокси. Проверьте выходной IP, затем добавьте целевое действие и явное ожидание его результата. Сохраняйте request ID и этап, но не реквизиты. Только после стабильных одиночных запусков добавляйте таблицу регионов и ограниченную параллельность. Каждая строка матрицы должна быть независимой и иметь собственный контекст.

Повторы разрешайте лишь для доказанно безопасных чтений. Уважайте Retry-After и увеличивайте паузу после 429 или сетевой серии. Мутации — покупка, смена реквизитов, продление — требуют идемпотентного ключа и проверки результата перед новой попыткой. Таймаут не доказывает отказ: команда могла завершиться у внешней системы.

• Создать четыре endpoints
• Снять чистое окружение
• Сравнить parent/child/container
• Проверить обязательный restart

Какие данные сохранить

Храните имя клиента/версию, sanitized env keys, PID/start time, destination, DNS result, selected direct/proxy route и exit marker. Значение proxy URL с credentials маскируйте целиком.

Хороший журнал содержит сценарий, этап, время начала и конца, код результата, число попыток и корреляционный ID. HAR и снимок прикладывайте только к сбою и очищайте от Authorization, Cookie и прокси-пароля. Для массового запуска храните сводку отдельно от детальных записей, чтобы единичная ошибка не потерялась среди успешных строк.

Сразу задайте имена колонок отчёта и формат времени. Результат без контекста быстро превращается в догадку: неизвестно, какой адрес использовался, был ли кэш и что изменилось. Сохраняйте не только успех, но и контролируемые отказы. Они доказывают, что проверка действительно различает состояния, а не всегда рисует зелёный индикатор.

Как читать результат

Контейнер получает только переданные переменные и может иметь отдельный DNS. Удаление переменной в текущей оболочке не меняет уже запущенный service; перезапуск и проверка process environment обязательны.

Нет единого полного стандарта NO_PROXY. Даже поддерживаемый CIDR или wildcard в одном runtime может игнорироваться другим.

Один успешный запуск подтверждает только конкретную комбинацию клиента, маршрута и времени. Для устойчивого вывода повторите опыт, изменяя одну переменную, и укажите границы. Если наблюдение расходится с документацией, сначала исключите кэш, версию программы и промежуточный сервер, а затем сформулируйте воспроизводимый пример для поддержки.

Разбор рабочего решения

Для «NO_PROXY: как окружение меняет маршрут отдельного процесса» опишите конечный автомат состояний до написания цикла. Минимальный набор включает ожидающую, выполняющуюся, успешную, окончательно ошибочную и неопределённую операции. Таймаут внешнего запроса переводит изменение в неопределённое состояние, потому что поставщик мог завершить его после разрыва связи. В таком случае сначала выполняется чтение и сверка, а повтор разрешается только после доказательства, что изменения не было.

Нагрузка ограничивается на нескольких уровнях: общий размер очереди, число задач на один домен, число задач на один аккаунт и частота повторов. Добавьте случайный небольшой сдвиг расписания, чтобы процессы не стартовали одновременно. Уважайте Retry-After и увеличивайте паузу после серии сетевых ошибок. Эти правила нужны даже при большом пуле IP: адреса не отменяют лимиты конечного сервиса и стоимость собственных ресурсов.

Для разбора инцидента храните идентификатор сценария, номер попытки, этап, время, безопасный код результата и связь с исходной задачей. Секреты, HTML целиком и личные данные в журнал не входят. Панель должна показывать зависшие и неопределённые операции отдельно от обычных ошибок. Восстановление начинается с одной контрольной задачи; массовую очередь возвращают только после подтверждённого конечного результата.

Типичные ошибки

Длинный sleep маскирует гонку, а немедленный retry усиливает сбой. Нельзя лечить 429 сменой адресов или запускать тесты одного аккаунта параллельно, если они меняют серверное состояние. Стабильность появляется от ожидания конкретного события, ограниченной очереди, изолированных аккаунтов и понятного конечного статуса.

Остановитесь, если растёт доля ошибок, источник вернул ограничение, результат требует обхода защиты или в журнал попали секреты. Сначала сохраните обезличенную диагностику и устраните причину. Смена IP или увеличение параллельности в такой точке скрывает проблему и может создать лишнюю нагрузку вместо полезных данных.

Критерии внедрения и сопровождение

Перед внедрением сформулируйте критерий решения: какое наблюдение разрешает продолжить работу, какое требует ручной проверки, а какое немедленно останавливает процесс. Укажите допустимый процент ошибок, максимальное время ожидания и владельца исключения. Без этих границ команда начинает объяснять одинаковый результат по-разному, а временный сбой незаметно превращается в постоянную настройку.

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

Рабочий регламент

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

• Есть условие успеха и остановки
• Проверен выходной IP
• Ожидание связано с событием
• Повторы ограничены
• Мутации идемпотентны
• Секреты удалены из артефактов