Порт прокси-сервера: как узнать номер и почему он закрыт

Порт прокси-сервера это числовой номер от 1 до 65535, по которому программа обращается к конкретной службе на удалённой машине. IP-адрес доводит пакет до нужного сервера, номер порта заводит этот пакет в нужный процесс внутри сервера. Одна машина спокойно держит HTTP-прокси на одном номере и SOCKS5 на другом, поэтому ошибка в две цифры обрывает связь ещё до того, как дойдёт очередь до логина и пароля.

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

Симптом: страница висит, и непонятно, где обрыв

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

Второй вариант симптома выглядит иначе: соединение обрывается мгновенно, за доли секунды, с текстом про отказ или про недоступный прокси. Мгновенный обрыв и минутное молчание указывают на разные причины, и я привык разводить их сразу, ещё до всякой диагностики. Быстрый отказ означает, что пакет дошёл до машины и получил внятный ответ. Долгое молчание означает, что пакет где-то потерялся по дороге без всякого ответа.

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

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

Что делает номер порта в связке клиент и прокси

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

Сервер слушает конкретные номера, и всё остальное для него закрыто. Если поставщик поднял HTTP-прокси на 8080 и SOCKS5 на 1080, то стук в 3128 на той же машине не даст ничего: там никто не слушает. Отсюда самая частая ошибка новичка, когда номер берётся из чужой инструкции в интернете, хотя у своего поставщика он другой.

Есть и обратная ошибка, когда номер верный, а протокол в настройках выставлен не тот. Браузер отправляет HTTP-запрос в порт SOCKS5, сервер получает мусор с точки зрения своего протокола и рвёт связь. Внешне это выглядит как поломка прокси, хотя обе стороны живы и работают. Пара «номер плюс протокол» держится вместе: меняя одно поле, сразу сверяйте второе.

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

Какие номера обычно отдают под HTTP и SOCKS5

Набор номеров сложился исторически, и большинство поставщиков от него не отходит. Я собрал в таблицу то, что встречаю чаще всего.

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

У себя я видел пулы с номерами вида 9091, 10800, 24000 и с полностью произвольными пятизначными номерами. Такие номера выдаются под конкретный заказ, и угадать их невозможно в принципе. Единственный корректный источник в этом случае это личный кабинет.

Ещё один момент касается количества номеров на один адрес. Приватный сервер часто отдаёт оба протокола сразу: HTTP на одном номере и SOCKS5 на соседнем. Когда нужен браузерный трафик и трафик из скрипта одновременно, беру оба номера и развожу их по разным программам. Если задача целиком браузерная, хватает HTTP-прокси для браузера и curl без всякого второго протокола. Софт, который открывает много соединений сразу, я сажу на точку входа по протоколу SOCKS5: она держит и TCP, и UDP на одном номере.

Где смотреть номер: кабинет и строка подключения

Личный кабинет остаётся первым и самым надёжным местом. У приватных поставщиков список выданных адресов лежит в разделе с активными заказами, и рядом с каждым адресом стоит номер порта, протокол и пара логин-пароль. Там же обычно есть кнопка выгрузки списка в текстовый файл, и я всегда беру номер оттуда, чтобы исключить опечатку при переписывании вручную.

Формат выгрузки чаще всего выглядит так:

203.0.113.45:8080:mylogin:mypass
203.0.113.45:1080:mylogin:mypass
198.51.100.17:8080:mylogin:mypass

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

Вторая точка это строка подключения. Она собирается в единый адрес с указанием протокола и удобно копируется в скрипты:

http://mylogin:mypass@203.0.113.45:8080
socks5://mylogin:mypass@203.0.113.45:1080
socks5h://mylogin:mypass@203.0.113.45:1080

Число после двоеточия в самом конце это порт. Схема в начале задаёт протокол. Вариант socks5h отличается тем, что имя домена уходит на разрешение на сторону прокси-сервера, и локальный резолвер в процесс не вмешивается.

Третья точка это настройки той программы, где прокси уже работал раньше. В браузере номер лежит в системных настройках сети или в свойствах расширения. В антидетект-браузере номер виден в карточке профиля. В парсере номер записан в файле со списком адресов. Когда меня просят помочь с чужой машиной, я начинаю с этих трёх мест и почти всегда нахожу номер за пару минут.

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

netstat -ano | findstr LISTENING
ss -lntp

Такой список даёт номера, открытые на самом компьютере. Для удалённого прокси-сервера он бесполезен, зато отлично помогает найти локальный порт, который занял антидетект-браузер или клиент туннеля.

Как проверить доступность порта: telnet, curl, Test-NetConnection

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

Самый короткий вариант это telnet. Клиент в Windows отключён по умолчанию, включается через компоненты системы.

telnet 203.0.113.45 1080

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

В PowerShell есть встроенная проверка, которая не требует ничего доустанавливать:

Test-NetConnection -ComputerName 203.0.113.45 -Port 1080

Смотреть нужно на строку TcpTestSucceeded. Значение True говорит об открытом порте, False о недоступном. Команда заодно показывает адрес сетевого интерфейса, с которого ушёл пакет, и это помогает поймать случаи, когда трафик уходит через служебный туннель.

В Linux и macOS ту же работу делает netcat:

nc -zv 203.0.113.45 1080

Флаг z означает пробу без передачи данных, флаг v включает подробный вывод. Ответ succeeded подтверждает открытый порт.

Все три команды проверяют только транспортный уровень. Они говорят, что порт принимает соединение, и молчат о том, работает ли на нём прокси-протокол. Полную проверку с учётом протокола и учётных данных даёт curl:

curl -x socks5://mylogin:mypass@203.0.113.45:1080 -sS https://api.ipify.org
curl -x http://mylogin:mypass@203.0.113.45:8080 -sS -o /dev/null -w "%{http_code}\n" https://example.com

Первая команда возвращает адрес, который видит внешний сайт. Если в ответе пришёл адрес прокси-сервера, связка собрана правильно от начала до конца: порт открыт, протокол совпал, пароль принят. Вторая команда печатает только код ответа и годится для быстрой прогонки списка адресов циклом.

Я обычно иду по лестнице: сперва telnet или Test-NetConnection, затем curl. Первый шаг занимает секунды и сразу отсекает половину причин. Второй шаг уточняет, где именно проблема, когда транспорт живой.

Что означает каждый вид ответа

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

Активный отказ приходит быстро, обычно за единицы миллисекунд, и текст ошибки в curl выглядит примерно так:

curl: (7) Failed to connect to 203.0.113.45 port 1080 after 3 ms: Connection refused

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

Молчание выглядит по-другому:

curl: (28) Failed to connect to 203.0.113.45 port 1080 after 75003 ms: Timeout was reached

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

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

Ещё одна пара ответов возникает уже на уровне протокола, когда транспорт в порядке. Код 407 от HTTP-прокси означает, что порт верный и служба живая, а пароль или адрес авторизации не подошли. Ответ SOCKS с кодом отказа в методе аутентификации означает то же самое для второго протокола. Оба случая приятные: связка почти собрана, править остаётся одно поле.

Кто закрывает порт по дороге: файрвол, антивирус, маршрутизатор

Офисная сеть обычно настроена по принципу разрешённого списка. Наружу открыты веб-порты 80 и 443, почтовые номера, DNS, иногда несколько служебных. Всё остальное отбрасывается молча. Именно поэтому SOCKS5 на 1080 из офиса часто выглядит мёртвым, хотя с домашней машины тот же адрес открывается мгновенно.

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

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

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

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

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

Характерный признак: соединение устанавливается и разрывается через мгновение. В логе curl это выглядит как обрыв уже после подключения. Telnet при этом успевает показать пустой экран и тут же выкидывает обратно в командную строку. Разрыв после успешной связи почти всегда указывает на локальный перехват.

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

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

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

Почему порт бывает занят локально

Третья ветка симптомов относится к своей же машине. Программа стартует и падает с сообщением о занятом адресе:

bind: Address already in use
Не удалось запустить прослушивание на 127.0.0.1:1080

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

Ищется занявший процесс двумя командами:

netstat -ano | findstr :1080
tasklist /FI "PID eq 4812"

Первая печатает строку с номером процесса в последней колонке. Вторая переводит номер в имя программы. В Linux и macOS то же самое делается одной строкой:

ss -lntp | grep 1080
lsof -i :1080

Дальше два пути. Либо завершить зависший процесс и запустить программу заново, либо поменять локальный номер в настройках на свободный. Второй путь надёжнее, когда номер занимает нужная служба. Я держу под локальные прокси диапазон от 10800 и выше: там пусто почти всегда, и конфликтов у меня с тех пор не было.

Есть ещё одна ловушка, о которой мало кто помнит. Windows резервирует диапазоны номеров под внутренние подсистемы, и попытка занять номер из зарезервированного диапазона даёт ту же ошибку при полностью свободном порте. Список резерваций показывает команда netsh с параметрами про excludedportrange. Проверка занимает секунды и снимает вопрос, когда netstat пустой, а порт всё равно недоступен.

Как подобрать номер порта под задачу и записать его себе

Когда порт найден и проверен, остаётся выбрать рабочую схему. Здесь я исхожу из того, какой софт будет ходить через прокси.

Браузер и простые скрипты спокойно живут на HTTP-порте. Этого хватает для ручной работы, для проверки выдачи по регионам, для загрузки страниц через curl. Парсеры, чекеры и всё, что открывает много соединений сразу, лучше себя чувствуют на SOCKS5: протокол работает на транспортном уровне, держит и TCP, и UDP, и отдаёт разрешение имён на сторону сервера. Под многопоточную выборку я развожу задачи по двум номерам одного адреса, чтобы браузерная проверка не мешала фоновому прогону.

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

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

Проверять новый порт стоит один раз, сразу после получения адресов, до того как они попадут в рабочий конфиг. Минута на telnet и curl экономит вечер разбора логов через неделю, когда прогон встанет посреди задачи и причина будет неочевидна.

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

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

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

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

Смежные темы разобраны в соседних материалах вики: чем IPv4 отличается от IPv6 объясняет, какой адрес вообще окажется перед номером порта, белый и серый адрес разбирает репутацию по спискам и отказы, которые внешне похожи на закрытый порт, доступ к пулу на месяц отвечает на вопрос о сроке жизни номера, а разбор работы A-Parser с пулом адресов показывает, как оба номера одного адреса раскладываются по заданиям.