Ставишь прокси на свой VPS, открываешь конфиг, доходишь до строки port и зависаешь. Одно число, вроде мелочь. От него зависит, подключится клиент с первого раза или ты полчаса будешь смотреть в логи и гадать, почему соединение висит без ошибки.
Ситуацию видел десятки раз. Человек копирует первый попавшийся порт из чужого гайда, а потом удивляется, что половина программ не работает. Порт - не универсальный пароль. Скорее дверь, и у каждой двери свой замок.
Порт и протокол путают даже те, кто настраивает прокси годами
Порт отвечает на вопрос «куда стучаться». Протокол - на вопрос «как разговаривать». Можно поднять SOCKS5 на 443, трафик от этого не станет HTTPS. Можно поставить HTTP-прокси на 1080, и он не превратится в SOCKS. Номер и протокол живут отдельно, и разложить это в голове стоит первым делом.
Универсального ответа на вопрос, какой порт использовать для прокси, нет. Есть рабочие комбинации под конкретный протокол, клиент и сеть. Дальше по порядку: цифры и места, где реально спотыкаются.
HTTP и HTTPS прокси: 80, 443, 3128, 8080
Классика для HTTP-прокси - 8080 и 3128. Первый чаще встречается на прокси-шлюзах и в корпоративных сетях, второй исторически закрепился за Squid. Оба рабочие, но есть нюанс: в некоторых сетях такие порты режут на входе, потому что админы считают их подозрительными.
80 и 443 выглядят как обычный веб-трафик. В корпоративных сетях их обычно оставляют открытыми, иначе не работает половина интернета. Прокси на 443 проходит строгий шлюз заметно чаще. Но номер порта сам по себе трафик не защищает: шифрование даёт TLS, а не цифра в конфиге.
HTTPS-прокси с проверкой сертификата требует корректного TLS. Ломается чаще всего на самоподписанных сертификатах: браузер ругается, приложение молча отваливается. Для корпоративного узла бери сертификат от доверенного центра, иначе пользователи будут игнорировать прокси и ходить напрямую.
Отдельная ловушка: 80 занят веб-сервером. Прокси на него не встанет, пока не освободишь номер или не перенастроишь сайт. С 443 та же история, поэтому в работе почти всегда выбирают заведомо свободный номер.
SOCKS5: почему 1080 - это привычка, а не правило
1080 закрепился за SOCKS исторически, ещё со времён первых реализаций. Многие гайды пишут его по умолчанию, и в половине случаев он действительно работает. Загвоздка в другом: SOCKS5 не привязан к конкретному номеру. Сервер может слушать любой свободный порт, клиенту всё равно, если он знает, куда стучаться.
В сборках на базе Mihomo SOCKS живёт на 7891, HTTP на 7890. Не стандарт, а договорённость внутри конкретного софта. Берёшь готовую сборку - смотри её конфиг, а не гадай по чужим скриншотам.
Отдельная история с локальными перенаправлениями. В связке с redsocks локальный порт вроде 12345 принимает трафик от системы и отправляет его на внешний прокси. Тут легко перепутать два порта: тот, что слушает локально, и тот, что слушает на удалённом сервере. Цифра 12345 в инструкции - вообще не про SOCKS5-сервер, а про промежуточное звено.
Для SOCKS5 важнее другое: поддержка UDP associate, если клиенту нужен голос или видео, и нормальная аутентификация. Номер вторичен. Парсеры годами работали через SOCKS5 на нестандартном порту, и всё было отлично.
Смешанный порт: один номер на два протокола
Смешанный порт принимает HTTP и SOCKS5 одновременно. В Mihomo это 7892. Удобно, когда не хочется держать два порта и объяснять пользователям, какой из них какой: клиент подключается одним номером, а прокси сам разбирается, какой протокол пришёл.
Минус - сложнее логировать и ограничивать. Нужно разделить политики по протоколам - смешанный порт только мешает. Для домашнего сервера или небольшой команды это экономия времени, для продакшена с аудитом лучше разделять.
MTProto: 443 и альтернатива 8400
Для MTProto-прокси стандартный выбор - 443. Причина простая: снаружи это выглядит как обычный HTTPS, и корпоративные шлюзы пропускают его чаще. Если 443 на сервере занят, например там крутится сайт, берут альтернативу вроде 8400.
В интерфейсе настройки всё просто: указываешь порт, имя пользователя и генерируешь секрет. Секрет создавай автоматически, а не придумывай руками из словарных слов. Длинная случайная строка снижает шанс, что доступ подберут.
Логика та же, что и везде: сначала проверь, свободен ли порт, потом открывай его в файрволе. Порядок важен. Открыл файрвол, а порт занят - получишь непонятную ошибку и потеряешь время.
Прозрачный прокси: 7893 и 7894
Прокси на шлюзе, который заворачивает трафик всей сети, использует порты прозрачного режима. redirect на 7893 умеет только TCP, tproxy на 7894 тянет TCP и UDP. Работают на Linux и Android, redirect ещё на macOS. Офисному шлюзу с VoIP и видеозвонками нужен tproxy, иначе часть трафика пойдёт мимо.
В прозрачном режиме клиенты вообще не знают про порт. Для корпоративного узла удобно, но требует аккуратности с правилами маршрутизации. Одна ошибка в правилах - и трафик заворачивается в петлю.
SSH на 22: когда прокси вроде и не нужен
SSH-туннель через 22 порт часто берут как быстрый способ получить защищённый канал без отдельного прокси-сервера. Динамический форвардинг поднимает локальный SOCKS на стороне клиента. Для разовых задач нормально, для постоянного парсинга неудобно: нет ротации, нет управления сессиями, всё держится на одном соединении.
Плюс 22 порт на многих серверах открыт по умолчанию и меняют его редко. Оставишь доступ без ключей и пароля - рано или поздно найдут боты. Прокси-сервер с нормальной аутентификацией предсказуемее.
Один сервер, несколько портов: когда это оправдано
Иногда удобно поднять на одной машине несколько сервисов сразу. HTTP на 8080, SOCKS5 на 1080, MTProto на 443. У каждого свои политики, логи, лимиты. Команда подключается к нужному протоколу, а ты видишь, кто и куда ходит.
Цена решения - растущая поверхность атаки. Больше открытых портов, больше конфигов, больше шансов оставить что-то без пароля. Делаешь так - закрой лишнее в файрволе и не выставляй наружу то, что нужно только локально.
Порт и скорость: магической связи нет
Бытует миф, что 443 работает быстрее, чем 8080. Неправда. Скорость зависит от канала, расстояния до узла, загрузки сервера и качества маршрута. Номер порта на это не влияет вообще.
Что реально влияет: задержка до узла, потери пакетов и настройки буферов. На Reddit сисадмины регулярно вспоминают, как переезд с 8080 на 443 убирал просадки у конкретного провайдера, но это история про маршрут, а не про скорость номера. Прокси тормозит - смотри пинг и трассировку, а не подбирай «счастливый» порт.
Как выбрать порт под свою задачу
Начинай с вопроса, кто клиент. Браузер и большинство приложений дружат с HTTP и SOCKS5, им подойдёт 8080, 3128 или 7892. Парсер на Python обычно просит SOCKS5, тут логичны 1080 или 7891. Telegram с MTProto ждёт 443, а если он занят - альтернативный номер.
Дальше смотри на сеть. В корпоративной сети выживают 80 и 443, остальное часто закрыто. На своём VPS ограничений меньше, но открывать наружу случайный высокий порт без аутентификации не стоит: сканеры найдут его за пару часов.
Проверь занятость. На Linux - ss или netstat, на Windows - netstat с фильтром. Если порт уже слушает другой процесс, прокси не запустится или запустится с ошибкой, которую не сразу видно.
Занятый порт и файрвол: где теряют время
Типичная ошибка новичка: поменять порт в конфиге и забыть про файрвол. Прокси слушает новый номер, а снаружи тишина. Или наоборот: файрвол открыт, а сервис не перезапущен. Проверяй оба конца.
Второй момент: порты неодинаково полезны с точки зрения маскировки. 443 выглядит как HTTPS, 8080 как альтернативный веб, а случайный 54321 сразу выдаёт нестандартный сервис. В строгой сети это имеет значение.
И не оставляй прокси без пароля. Открытый SOCKS5 на публичном адресе разберут на боты за сутки. Аутентификация, ограничение по адресам источников, лимиты соединений, логи. Скучно, но без этого никакой порт не спасёт.
Прокси для парсинга и бизнеса: порт тут вторичен
Когда прокси нужен команде или парсеру, выбор порта уходит на второй план. Важнее стабильность, география, лимиты и ротация. Один удачный порт не компенсирует узел, который падает каждый час.
Для сбора данных по регионам нужен пул адресов, а не один сервер. Для корпоративного шлюза важна пропускная способность и нормальное логирование. Для защиты трафика в публичном Wi-Fi хватит собственного VPS с TLS и авторизацией.
Готовые пулы и отдельные узлы удобно смотреть в каталоге прокси https://3seller.com/proxy. Там можно подобрать вариант под задачу, а не собирать всё с нуля на одном сервере.
Что вводить в клиенте, чтобы не запутаться
В браузере настройки лежат в разделе сети: адрес сервера, порт, тип прокси. Порт вводится отдельным полем, и путать его с портом сайта, который ты открываешь, нельзя. В приложении мессенджера настройки спрятаны глубже: тип подключения, добавление прокси, поля сервера, порта и секрета.
Проверка простая. Клиент пишет про таймаут - скорее всего порт закрыт файрволом или сервис не слушает этот номер. Ошибка аутентификации - порт верный, а пароль или секрет нет. Соединение устанавливается, но ничего не грузится - проблема в маршрутизации или DNS.
Про DNS отдельно. В некоторых конфигурациях запросы уходят мимо прокси, и тогда часть сайтов не открывается, хотя порт рабочий. Проверяй, что резолвинг идёт через тот же узел, иначе будешь искать проблему не там.
Сертификаты и SNI: почему 443 требует внимания
Прокси на 443 в режиме HTTPS-шлюза заставляет клиент проверять сертификат. На корпоративном устройстве вопрос решается установкой собственного корневого сертификата, но только на технике, которую ты контролируешь. На личном телефоне сотрудника такое лучше не делать без объяснений.
Самоподписанный сертификат на 443 вызывает больше вопросов у клиентов, чем тот же прокси на 8080. Браузер может просто не дать пройти дальше, а приложение упадёт с невнятной ошибкой. Выбор порта тянет за собой историю с TLS.
Мой рабочий порядок действий
Сначала определяю протокол, потом выбираю порт. Для HTTP - 8080 или 3128, для SOCKS5 - 1080 или 7891, для MTProto - 443 с запасным 8400. Смешанный 7892 оставляю для случаев, когда клиент не хочет выбирать.
Дальше проверяю, свободен ли номер, открываю его в файрволе только для нужных адресов, включаю аутентификацию и логи. Тестирую снаружи, а не с самого сервера: локальный тест часто врёт и показывает, что всё работает, хотя снаружи порт закрыт.
Если не хочется возиться с инфраструктурой, посмотри готовые варианты в каталоге https://3seller.com/proxy. Выбор порта перестаёт быть головной болью, когда узел уже настроен и проверен.