top of page

Как проверить прокси командой curl

12.10.26

От «жив ли адрес» до прогона списка из 500 строк за пару минут

WinGate: приватные прокси IPv4 и SOCKS5, бесплатный тест до 2 часов
Пять проверок прокси через curl: доступ, скорость, анонимность, SOCKS5 и список

Как проверить прокси надёжно? С той машины, где он будет работать, одной командой curl. За 15 секунд она показывает, отвечает ли сервер, принимает ли он логин, какой IP видит сайт и сколько длится ответ. Ещё две команды закрывают анонимность и SOCKS5. Список на сотни строк прогоняется скриптом в 50 потоков.


Порядок важен. Однажды онлайн-чекер показал мне 0 живых из 200 адресов, а curl с рабочего сервера тут же вернул 200 ответов из 200. Прокси были с авторизацией по IP. Чекер стучался со своего адреса, которого в белом списке не было, и честно получал отказ.


Ловушка онлайн-чекера: проверка идёт с чужого адреса

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


  • Авторизация по IP. Прокси пускает только привязанные адреса. Сервер чекера в белом списке не значится, и живой адрес уходит в мёртвые.

  • Чужой маршрут. Пинг и скорость измерены от сервера чекера. Ваша программа стоит в другой сети, её цифры будут другими.

  • Пароль у третьей стороны. Вставив строку с логином и паролем в форму, вы отдаёте свой доступ к прокси постороннему сервису, о котором ничего не знаете.


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


Проверка 1. Жив ли адрес и принимает ли он логин

Самая короткая команда. Подставьте свои данные:


curl -x http://IP:ПОРТ -U ЛОГИН:ПАРОЛЬ https://api.ipify.org -m 15

В ответ должна прийти одна строка с выходным IP прокси. Пришла? Адрес жив и пускает вас. У пула с ротацией этот IP будет отличаться от адреса в строке подключения, так и задумано. Сообщение «CONNECT tunnel failed, response 407» значит, что сервер жив и отвечает, просто логин, пароль или привязка IP не совпали. Тишина и таймаут через 15 секунд говорят о том, что до порта вы не достучались вовсе.


Ключ -U удобнее логина внутри адреса. Пароль с символами @, двоеточием или решёткой с ним пишется как есть. В форме ЛОГИН:ПАРОЛЬ@IP знак @ в пароле ломает разбор строки, и его приходится кодировать как %40. Ещё одна мелочь из практики: если забыть порт, curl молча подставит 1080 и будет ждать ответа на нём. При авторизации по IP ключ -U просто уберите.


В Windows PowerShell набирайте curl.exe с расширением. Короткое имя curl там ведёт на встроенный Invoke-WebRequest, который ключи вроде -x не понимает и падает с ошибкой параметра.


Если адрес не прошёл даже эту проверку, дальше идти рано: сначала разберитесь по списку причин, почему прокси не работает.


Проверка 2. Скорость и кто именно отказал: прокси или сайт

Вторая команда идёт на тот сайт, где адрес будет работать, и печатает четыре числа:


curl -x http://IP:ПОРТ -U ЛОГИН:ПАРОЛЬ https://нужный-сайт.ru -o /dev/null -s -m 20 -w "proxy=%{http_connect} site=%{http_code} tcp=%{time_connect} total=%{time_total}\n"

Как читать ответ curl с кодом туннеля, кодом сайта и временем соединения

В Windows вместо /dev/null пишите NUL. Разбираем вывод по полям.


  • proxy. Код, которым прокси ответил на запрос CONNECT. 200 значит, что туннель открыт. 407 указывает на авторизацию.

  • site. Код самого сайта: 200, 403, 429 и так далее. Если proxy равен 407, здесь будет 000, до сайта запрос не дошёл.

  • tcp. Секунды до установки соединения с прокси. Это сетевое расстояние от вас до сервера.

  • total. Полное время запроса вместе с TLS и загрузкой страницы.


Главная ценность команды в первых двух полях. Связка proxy=200 и site=403 однозначно говорит, что прокси исправен и отказывает сам сайт, поэтому крутить настройки программы в такой ситуации бесполезно. Связка proxy=407 и site=000 переводит разговор на логин и привязку. Расшифровка остальных ответов есть в разборе ошибок прокси-сервера по кодам.


По скорости у меня простое правило. Для парсинга я отсеиваю адреса, у которых total на лёгкой странице стабильно выше 5 секунд, потому что в 50 потоках такие тормоза тянут вниз весь прогон. Запустите команду 3 раза подряд. Одиночный выброс ничего не значит. Адрес, медленный во всех трёх замерах, смело отсеивайте.


Проверка 3. Анонимность: что прокси дописывает в заголовки

HTTP-прокси вправе добавить к запросу свои заголовки. Самые болтливые из них: X-Forwarded-For с вашим реальным IP, Via с именем прокси-сервера, Forwarded и X-Real-IP. Сайт читает их и делает выводы.


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


curl -x http://IP:ПОРТ -U ЛОГИН:ПАРОЛЬ "http://httpbin.org/headers?show_env=1" -m 15

Эхо-сервис возвращает заголовки ровно в том виде, в каком их получил. Параметр show_env=1 обязателен. Без него сервис прячет X-Forwarded-For и Via, и утечку не видно. Сам он стоит за балансировщиком, который тоже дописывает в X-Forwarded-For адрес прокси, это нормально. Тревожный признак один: ваш собственный IP где угодно в ответе. Свой адрес узнайте той же первой командой без ключей -x и -U.


По ответу прокси относят к одному из трёх уровней. Прозрачный передаёт ваш IP в X-Forwarded-For. Анонимный прячет IP, но оставляет Via или Forwarded, и сайт понимает, что перед ним прокси. Элитный не оставляет следов вовсе, запрос выглядит прямым. Подробнее уровни разобраны там, где описана проверка анонимности прокси.


Заголовки, по которым видно прозрачный, анонимный и элитный прокси

Проверка 4. Как проверить прокси SOCKS5 и где у него утечки

Для SOCKS5 меняется только схема:


curl -x socks5h://ЛОГИН:ПАРОЛЬ@IP:ПОРТ https://api.ipify.org -m 15

Буква h в схеме значит, что имя сайта резолвит сам прокси. Со схемой socks5 без h curl сначала спросит адрес у вашего DNS-сервера, и тот, обычно это провайдер, увидит, куда вы ходите. Старый ключ --socks5-hostname делает то же, что socks5h.


SOCKS5 работает уровнем ниже HTTP. Он передаёт байты и в заголовки не заглядывает. Поэтому проверка из прошлого раздела для него пустая: дописывать X-Forwarded-For протокол SOCKS5 не предусматривает, и главное место утечки у него DNS. Для программ, где ходит не только веб, разумно сразу купить socks5 прокси.


Перепутанный протокол даёт странные симптомы. Если указать socks5h на порт HTTP-прокси, curl чаще всего висит до таймаута. Обратная ошибка, http на порт SOCKS5, заканчивается обрывом соединения. Обе выглядят как мёртвый адрес. Адрес при этом жив.


Проверка 5. Список на сотни адресов в 50 потоков

Руками сотню строк не проверить. Для Linux и macOS хватает связки xargs и curl, если список записан в виде ЛОГИН:ПАРОЛЬ@IP:ПОРТ:


xargs -P 50 -I{} curl -s -o /dev/null -m 15 -x "http://{}" https://api.ipify.org -w "{} %{http_connect} %{time_total}\n" < list.txt > result.txt

В result.txt каждая строка получит код туннеля и время. Для любой системы, включая Windows, удобнее короткий скрипт на Python. Он читает формат IP:ПОРТ:ЛОГИН:ПАРОЛЬ или IP:ПОРТ, проверяет адреса в 50 потоков и сохраняет живые в alive.txt, отсортировав по скорости:


import time
from collections import Counter
from concurrent.futures import ThreadPoolExecutor
from urllib.parse import quote
import requests

SCHEME = "http"          # для SOCKS5 поставьте socks5h
TARGET = "https://api.ipify.org"

def check(line):
    ip, port, *auth = line.strip().split(":", 3)
    cred = f"{quote(auth[0], safe='')}:{quote(auth[1], safe='')}@" if auth else ""
    proxy = f"{SCHEME}://{cred}{ip}:{port}"
    start = time.perf_counter()
    try:
        r = requests.get(TARGET, proxies={"http": proxy, "https": proxy}, timeout=(5, 10))
        return line.strip(), str(r.status_code), r.text.strip(), time.perf_counter() - start
    except requests.RequestException as e:
        return line.strip(), type(e).__name__, "", 0.0

lines = [l for l in open("proxies.txt", encoding="utf-8") if l.strip()]
with ThreadPoolExecutor(max_workers=50) as pool:
    results = list(pool.map(check, lines))

alive = sorted((r for r in results if r[1] == "200"), key=lambda r: r[3])
with open("alive.txt", "w", encoding="utf-8") as f:
    for line, _, exit_ip, sec in alive:
        f.write(f"{line}\t{exit_ip}\t{sec:.2f}\n")
print(f"живых {len(alive)} из {len(results)}")
print(Counter(r[1] for r in results))

Для SOCKS5 поставьте библиотеку командой pip install "requests[socks]". Три детали в коде сделаны намеренно. Функция quote кодирует спецсимволы в логине и пароле. Разбиение split(":", 3) оставляет двоеточие внутри пароля на месте. Счётчик в конце показывает, от чего умерли остальные: ProxyError значит, что прокси недоступен или отказал в доступе, ошибки с Timeout в названии говорят, что ответ не уложился в таймаут.


В alive.txt рядом с каждой строкой лежит выходной IP. Если у нескольких строк он совпадает, все они ведут на один и тот же адрес, и считать их разными прокси при расчёте потоков нельзя.


Считаем время. 500 адресов в 50 потоках при таймауте 15 секунд в худшем случае дают 10 волн по 15 секунд, то есть две с половиной минуты. Живые отвечают за секунду, так что обычно выходит быстрее. Замените TARGET на страницу рабочего сайта, и тот же скрипт покажет по каждому адресу 403 и 429 там, где они вам реально помешают.


Когда проверка списка превращается в ежедневную рутину

Проверенный утром список к вечеру редеет. Часть адресов начинает получать 403 на рабочем сайте, часть упирается в лимиты, и прогон из этой статьи приходится повторять каждый день, выкидывая строки и докупая новые. На десятках задач это съедает часы.


Пул с ротацией снимает эту рутину. Вы подключаетесь к одной точке входа, а выходной IP меняется сам на каждый запрос, поэтому проверять приходится одну строку вместо сотен. Если нужно купить быстрые прокси под массовую проверку, у WinGate так устроен пул: приватные IPv4 и SOCKS5, протоколы HTTP, HTTPS и SOCKS5, безлимитный трафик, до 5000 потоков, авторизация по IP или строкой IP:PORT:LOGIN:PASS.


Все пять команд из этой статьи можно прогнать на тестовом доступе. Для этого есть тест прокси сервера без оплаты, до 2 часов: запустите скрипт на рабочем сайте и посмотрите, сколько ответов вернётся с кодом 200.

WinGate: приватные прокси IPv4 и SOCKS5, бесплатный тест до 2 часов

Свежие статьи

14.10.26

Прокси не работает: 9 причин и как найти свою за 5 минут

Сначала тест за 60 секунд. Потом симптомы, коды и 9 причин по порядку.

13.10.26

Подключение прокси и символ @, который ломает всю строку

Где задаётся подключение, как записать строку и какую авторизацию выбрать

12.10.26

Как проверить прокси командой curl

От «жив ли адрес» до прогона списка из 500 строк за пару минут

О справочнике

Proxyra разбирает прокси по делу: настройка в Windows, Linux и браузерах, коды ошибок, прокси в парсерах и антидетектах. Команды из статей можно копировать и запускать сразу.

© 2026 Proxyra. Справочник по настройке и ошибкам прокси.

bottom of page