Полчаса искал причину: скрипт на Python исправно ходил через прокси, а запросы к внутреннему API компании падали с таймаутом. Виновник — пустое поле исключений. Добавил домен API в список — и всё заработало. Мелочь, которая экономит вечер.
Разберу, как добавить сайт в исключения прокси сервера на Windows, macOS, Chrome, Firefox, Opera и на мобильных. С конкретными путями в меню, синтаксисом и граблями, на которые наступают даже сисадмины.
Список исключений решает три разные задачи
Первая — локальный трафик. Внутренние порталы, базы, админки, тестовые стенды в корпоративной сети часто доступны только напрямую. Если гнать их через внешний прокси, запрос уходит наружу и возвращается, а иногда не возвращается вовсе. Задержка растёт, часть сервисов отваливается по таймауту.
Вторая — сервисы, которые не любят чужой IP. Банки, платёжные шлюзы, личные кабинеты и некоторые API видят смену гео и включают проверки. Иногда проще пустить конкретный домен напрямую, чем объяснять службе безопасности, почему вход был из другой страны.
Третья — производительность. Тяжёлые файлы, обновления, видеозвонки и внутренние бэкапы через прокси гонять бессмысленно. Например, обновление Windows 11 через прокси может пожрать гигабайты платного трафика, в то время как прямой доступ к внутренним серверамUpdate это не требует. Прокси нужен для задач, где важен IP, а не для всего трафика подряд.
Смешивать эти задачи в одном правиле не стоит. Исключения — точечный инструмент, а не глобальный выключатель.
Где живёт настройка в Windows 10 и 11
Современный путь короткий. Открываете Параметры, затем Сеть и Интернет, затем Прокси. В блоке ручной настройки включаете переключатель и видите два поля: адрес с портом и «Не использовать прокси для». Вот оно и есть. Домены перечисляете через точку с запятой, без пробелов.
Старый путь через Панель управления тоже работает и иногда удобнее, потому что открывает всё окно целиком. Свойства браузера, вкладка Подключения, кнопка Настройка сети, затем Дополнительно. Там же галочка «Не использовать прокси для локальных адресов», которая автоматически прикрывает внутренние имена. Если у вас корпоративная сеть с доменом, эту галочку лучше оставить включённой.
Отдельно про формат. В Windows список разделяется точкой с запятой. Запятая тоже может сработать, но не во всех сборках и не во всех приложениях, которые читают системные настройки. Звёздочка вида *.site.ru поддерживается не везде. Надёжнее указать и site.ru, и нужный поддомен отдельно.
После правок нажимайте ОК последовательно во всех открытых окнах. Закрытие крестиком в правом верхнем углу не сохраняет изменения, и это самая частая причина «я всё добавил, но не работает».
Chrome и Edge молча берут системные настройки
В Chrome нет собственного списка исключений. Браузер читает то, что задано в системе. Открыли настройки прокси внутри Chrome, а вас всё равно перебросило в окно Windows или macOS — так и задумано. Поэтому добавлять домен нужно там, где живёт системная настройка, а не в самом браузере.
Edge ведёт себя так же. Исключения из Windows применяются к обоим браузерам одновременно. Если у вас в системе стоит прокси, а в Chrome установлено расширение для управления трафиком, правила расширения перекрывают системные. Проверьте список расширений, прежде чем искать причину в реестре.
Есть нюанс с фоновыми процессами. Обновления Chrome, синхронизация и часть служебных запросов идут отдельно от вкладок. Если сайт открывается напрямую, а встроенные сервисы браузера продолжают стучаться через прокси, это нормально и на работу страниц не влияет.
Firefox держит свой список отдельно от системы
Здесь всё иначе. Firefox по умолчанию использует системные настройки, но может жить своей жизнью. Настройки, затем Основные, затем Настройки сети, кнопка Настроить. В открывшемся окне выбираете ручную настройку, вводите адрес и порт, а ниже заполняете поле «Не использовать прокси для».
В Firefox разделитель — запятая. Поддерживаются маски и указание портов. Если нужно исключить целый домен вместе с поддоменами, удобно прописать два варианта: site.ru и .site.ru. Точка перед доменом в некоторых версиях трактуется как «все поддомены», но поведение менялось от релиза к релизу, поэтому дублирование лишним не будет.
Полезная деталь для командной работы: в корпоративной сборке настройки могут приезжать через файл политик. Тогда поле в интерфейсе будет серым, и правки не применятся. Смотрите в сторону администратора или локального файла конфигурации, а не щёлкайте по кнопкам.
Opera: три уровня настроек и легко потеряться
В актуальных версиях путь такой. Настройки, затем Дополнительно, затем Сеть, затем Прокси. Выбираете ручную конфигурацию, проверяете адрес и порт, а исключения вписываете в блок «Не использовать прокси для». Интерфейс подписан иначе, чем в Windows, но логика та же.
В старых сборках Opera 15 и выше диалог вызывался через кнопку меню и пункт настроек, а дальше открывалось системное окно. Там нужно было поставить галочку использования прокси, указать адрес и порт, отметить «Не использовать прокси для локальных адресов» и нажать Дополнительно для ввода исключений. Если вы застали ещё Presto, там был отдельный диалог с полем «Не использовать прокси для», и правила не пересекались с системными.
Практический совет: после смены списка перезапустите браузер полностью, а не только вкладку. Opera кэширует сетевые настройки агрессивнее, чем кажется.
macOS: исключения прячутся за кнопкой «Подробнее»
Системные настройки, затем Сеть. Выбираете активную службу слева, нажимаете Подробнее, затем Прокси. Включаете нужный протокол, вводите адрес и порт, а ниже видите поле «Исключения» или «Пропускать для». Домены перечисляете через запятую.
В старых версиях macOS путь был чуть короче: Системные настройки, Сеть, Дополнительно, Прокси. Логика не поменялась, поменялись подписи. Для HTTP и HTTPS списки могут быть разными, если включены оба протокола. Проверьте оба блока, иначе получится, что часть запросов идёт напрямую, а часть продолжает уходить через прокси.
На macOS часто мешает отдельный VPN-клиент или корпоративный профиль конфигурации. Он может перетирать настройки прокси при каждом подключении. Если список сбрасывается после перезагрузки, ищите профиль в разделе Основные, Устройства или в описании конфигурации.
Android и iOS: та же логика, только спрятана в Wi-Fi
На Android откройте Wi-Fi, нажмите и удерживайте нужную сеть, выберите Изменить, затем Дополнительно. В блоке прокси выберите ручной режим, введите адрес и порт, а в поле «Не использовать прокси для» перечислите домены. Разделитель зависит от прошивки, чаще запятая. На чистом Android поле может называться «Пропускать прокси для».
На iPhone и iPad: Настройки, Wi-Fi, значок информации рядом с сетью, Настройка прокси, вручную. Появляются поля сервера, порта и исключений. Список небольшой, но для пары доменов хватает.
Мобильные приложения ведут себя по-разному. Браузеры обычно читают системные настройки Wi-Fi. Мессенджеры вроде Telegram настраиваются отдельно: Настройки, Данные и память, Прокси. Там есть адрес, порт и секрет, но отдельного списка исключений нет. Правила задаются на уровне системы или маршрутизации, а не внутри приложения. То же касается WhatsApp и большинства клиентов, которые умеют ходить через собственный узел.
Синтаксис исключений: что реально понимает система
Просто домен без протокола. Никаких http:// и https://, никаких слэшей и путей. Прокси-клиент сравнивает хост, а не полный URL. Запись https://site.ru в списке исключений часто игнорируется целиком.
Поддомены указываются отдельно или через маску. Универсального стандарта нет, поэтому надёжнее явно перечислить нужные имена. Для внутренних зон помогает localhost и имена вида *.company.local, если система поддерживает звёздочку.
Порты можно указывать через двоеточие, если нужно исключить только конкретный сервис на хосте. Для большинства задач это избыточно, но при работе с нестандартными API пригодится.
Подсети задаются в CIDR-формате, если интерфейс это поддерживает. В Windows такое поле есть в расширенных настройках, в macOS — в блоке исключений. Для офисных сетей удобно прописать диапазон один раз, чем перечислять десятки хостов.
Пробелы вокруг разделителей лучше не ставить. Часть парсеров воспринимает их как часть домена, и правило тихо не срабатывает.
Три ошибки, из-за которых исключения не работают
Первая — протокол в строке. Люди копируют адрес из браузера целиком и удивляются, почему сайт по-прежнему идёт через прокси. Уберите http, https и всё, что идёт после первого слэша.
Вторая — несохранённые окна. В Windows настройки применяются только после ОК во всех диалогах. В macOS — после кнопки ОК в окне прокси и кнопки Применить в настройках сети. Закрыли окно — правила не применились.
Третья — перекрывающие правила. PAC-файл, групповые политики, антивирус с собственным прокси, VPN-клиент и расширения браузера могут игнорировать ваш список. Проверяйте по цепочке: система, затем браузер, затем расширения, затем защитное ПО.
Отдельно про DNS и keep-alive. После правок соединение к сайту может оставаться открытым со старыми параметрами. Перезапуск браузера и сброс DNS-кэша решают проблему чаще, чем кажется.
Как проверить, что сайт действительно идёт напрямую
Самый простой способ — сравнить исходящий IP. Откройте страницу определения IP с включённым прокси и без него. Если адрес одинаковый, исключение работает. Если разный, правило не применилось или применяется не к тому процессу.
Второй способ — логи прокси-сервера. Если у вас собственный узел на VPS, в журнале видно, приходит ли запрос к нужному домену. Это точнее любых внешних сервисов, особенно когда речь о корпоративных приложениях.
Третий способ — командная строка. Утилита curl умеет игнорировать прокси через флаг --noproxy. Если с флагом запрос проходит, а без него нет, проблема точно в маршруте, а не в самом сайте.
Для браузерных сценариев помогает режим разработчика: вкладка Сеть показывает, через какой узел ушёл запрос, если прокси прописан на уровне системы. Не самый наглядный метод, но рабочий.
Когда исключений становится много, нужен нормальный пул адресов
С одним-двумя доменами всё просто. С десятками задач сложнее: парсинг маркетплейсов, проверка рекламы по гео, аналитика выдачи, работа с несколькими кабинетами, корпоративные интеграции. Тут уже важно не только правильно заполнить поле исключений, но и иметь под рукой предсказуемые адреса, которые не попали в чёрные списки чужих сервисов.
Я в таких случаях смотрю в каталог 3seller. Там прокси разложены по протоколам, странам и типам, без необходимости собирать список по форумам и проверять каждый адрес вручную. Для команд, которым нужен стабильный узел под задачи, это заметно экономит время. Как отмечают авторы каталога, предсказуемый IP-адрес для бизнес-приложений — основа стабильной работы.
С выделенными адресами проще и с исключениями: вы точно знаете, какой трафик куда идёт, и не ловите сюрпризы, когда сосед по бесплатному пулу уже успел наследить на нужном сайте. Если планируете работать с чувствительными сервисами, лучше сразу брать вариант с понятной репутацией адреса.
Как это выглядит в архитектуре, а не в галочках
В корпоративной среде чаще поднимают собственный VPS с SOCKS5 или HTTP-прокси. SOCKS5 работает на уровне сессии и не разбирает содержимое запросов, поэтому список исключений для него задаётся на стороне клиента или в правилах маршрутизации ОС. Шифрование пакетов, балансировка между узлами и снижение задержки — отдельный слой, который настраивается уже после того, как определены адреса и домены.
Для парсинга важно другое: предсказуемая скорость ответа и отсутствие массовых блокировок. Исключения здесь нужны, чтобы не гонять через платный трафик внутренние сервисы и служебные эндпоинты. Один раз настроенный список экономит гигабайты и часы отладки.
MTProto в мессенджерах устроен иначе, но принцип тот же: адрес узла, порт и секрет. Список исключений на уровне приложения там не предусмотрен, поэтому если нужен раздельный трафик, рулите системными настройками или маршрутизацией на роутере.
Что сделать прямо сейчас
Возьмите один проблемный домен, который точно не должен идти через прокси. Добавьте его в список в том месте, где у вас реально применяются настройки: Windows, macOS, Firefox или мобильная сеть. Перезапустите браузер, сравните исходящий IP и время ответа.
Если разница есть, добавляйте остальные адреса и не забывайте про поддомены. Если ничего не изменилось, ищите перекрывающее правило: PAC-файл, политики, антивирус, VPN или расширение. Прокси редко виноват сам по себе, чаще дело в том, кто последним записал настройку в систему.