Posted:
Фев 7, 2023
Comments:
0 Comments

Проксирование запросов это: что это такое, зачем и как использовать

Содержание

🔄 Как работает прокси-сервер: максимально простое объяснение

Прокси-сервер, или
просто прокси – это компьютер, выполняющий роль посредника между пользователем и целевым сервером. Сначала клиент подключается к прокси-серверу и запрашивает необходимый ресурс, расположенный на другом сервере. Например, почту или html-страницу. Затем прокси либо подключается к указанному серверу и получает у него ресурс, либо возвращает ресурс из собственного кэша.

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

Процесс работы с прокси

Когда речь заходит о
прокси, обычно подразумевается прямой прокси-сервер. Представим, что мы делаем запрос, например, пытаемся перейти на GitHub – вводим
URL, нажимаем Enter. Прокси не подключает нас к GitHub напрямую, а перехватывает соединение и обновляет содержание запроса, удаляя входящий IP и изменяя заголовок. В результате GitHub считает, что запрос пришел с другого
компьютера, и отправляет нужные данные не нам, а прокси-серверу. Прокси принимает информацию GitHub, проверяет и отправляет данные нашему компьютеру.

Распространенные варианты использования прокси:

  • повышение безопасности сети с помощью шифрования запросов;
  • предотвращение перехвата конфиденциальной информации;
  • блокировка вредоносных сайтов и рекламы;
  • кэширование сайтов для экономии трафика;
  • контроль использования сетевого канала;
  • блокировка доменов;
  • мониторинг и регистрация веб-запросов;
  • тестирование веб-ресурсов при заходе с различных IP.

Свои варианты вы можете предложить в комментариях к публикации.

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

Анонимный прокси никогда не передают IP-адрес клиента на целевой ресурс. Хороший вариант, если вы не хотите,
чтобы таргетированная реклама следила за вами или вашим местоположением. Прокси высокой анонимности не передает ни IP-адрес, ни личные данные и даже не идентифицирует себя как прокси. В процессе работы IP-адрес периодически меняется – это позволяет обеспечить максимальную конфиденциальность. Браузер TOR использует этот тип прокси-сервера. Поскольку IP меняется, чрезвычайно трудно отследить источник запросов.

Искажающий (distorting) прокси работает
аналогично анонимному, но передает заведомо ложный IP-адрес. Такой подход используется, чтобы обойти локальные ограничения доступа к контенту.

Резидентный (residential) прокси используют реальные (белые, статические) IP-адреса. Для серверов они выглядят
как обычные клиенты. Противоположность резидентного – data center прокси, имеющие IP-адреса, не привязанные
к реальному устройству. Облачные провайдеры имеют высокоскоростные интернет-соединения. Однако если на одном сервере размещено сотни прокси-серверов, все они будут иметь одинаковые IP-адреса.

Публичный (public) прокси – самый небезопасный и ненадежный. Могут «отвалиться» в любой
момент, уязвимы для хакерских атак. Найти списки бесплатных
публичных прокси не так уж сложно, но найти хороший публичный прокси – почти невозможно.

Частный (private) прокси может использоваться единовременно только одним клиентом, а перед использованием происходит проверка подлинности. Это более надежная версия публичного прокси. Частный прокси-сервер может быть прозрачным или иметь высокую анонимность, подобно вышеописанным собратьям, таким как резидентный или data center прокси.

Общий (shared) прокси – один из самых
дешевых видов прокси-серверов. Стоимость аренды сервера разделяется между клиентами, которые получают к нему одновременный доступ.

Ротационный (rotating) прокси для нового клиента выделяет новый IP-адрес. То есть один и тот же IP не используется более одного раза. Ротационный сервер
обеспечивает высокий уровень безопасности и конфиденциальности.

SSL-прокси работают
по принципу HTTPS-запросов – запросы
между клиентом и сервером защищены шифрованием.

Обратный (reverse) прокси предлагает совершенно другой
подход к проксированию. Здесь скрывается не IP-адрес клиента, а IP-адрес сервера, на который отправляется
запрос. Инструмент используется, чтобы контролировать доступ к серверу и ограничивать
неконтролируемый доступ к базе данных, а также для снижения трафика за счет кэширования информации.

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

  • https://smartproxy.com/
  • https://www.megaproxy.com/
  • https://whoer.net/webproxy
  • https://www.proxysite.com/
  • https://hide.me/en/proxy
  • https://www.kproxy.com/
  • https://www.vpnbook.com/webproxy

Главное отличие прокси от VPN заключается в том, что VPN защищает весь сетевой трафик, а
прокси – только интернет-трафик. Прокси передает запросы, действуя как посредник,
а VPN туннелирует всю сетевую активность до уровня операционной системы.

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

Несмотря на все
преимущества, у VPN в сравнении с прокси есть недостатки:

  • VPN дороже;
  • соединение обычно происходит медленнее.

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

Создать собственный прокси-сервер проще, чем, кажется. Прокси-сервер может располагаться где угодно, им может стать даже домашний компьютер. На сервере Linux можно установить Squid и задать необходимые настройки. Можно блокировать
определенные веб-сайты или требовать аутентификацию, прежде чем клиент подключится к прокси-серверу (пошаговое руководство по настройке Squid).

В Windows и Mac есть возможность создать прокси-сервер с помощью Python и Google
App Engine, но придется немного
заплатить. Настройка сервера незначительно сложнее, чем в Linux.

Если вы знаете IP-адрес и номер порта прокси, подключиться будет несложно. Нужно зайти
в настройки сети, далее в раздел прокси, а после ввести информацию о сервере.

Настройка прокси-сервера в WindowsНастройка прокси-сервера в Ubuntu

Использование прокси оправдано, если необходимо скрыть или защитить информацию. Выше мы рассмотрели список задач, решаемых с помощью прокси. Как мы увидели, в использовании прокси есть преимущества:

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

Но есть и недостатки:

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

Если вам интересна тема информационной безопасности, в Библиотеке программиста есть множество публикаций на эту тему, например:

  • «Я тебя по IP вычислю»: как хакеры рассекречивают звенья цепи Tor
  • Как стать специалистом по информационной безопасности
  • Что такое кибербезопасность и почему за этой профессией будущее?

Больше полезной информации вы найдете на наших телеграм-каналах «Библиотека программиста» и «Книги для программистов».

Интересно, перейти к каналу «Библиотека программиста»

Настройка проксирования в nginx с помощью proxy_pass

Хочу рассказать об одной полезной возможности nginx, которую регулярно использую в своих делах. Речь пойдет о настройке проксирования запросов на удаленный сервер с помощью nginx и директивы proxy_pass. Я приведу примеры различных настроек и расскажу, где сам использую данный модуль популярного веб сервера.

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти вступительный тест.

Введение

Настройка proxy_pass в nginx

Передача реального ip (real ip) адреса клиента в nginx при proxy_pass

Передача https через nginx с помощью proxy pass

Проксирование определенной директории или файлов

Часто задаваемые вопросы по теме статьи (FAQ)

Заключение

Помогла статья? Подписывайся на telegram канал автора

Введение

Немного расскажу своими словами о том, как работает модуль ngx_http_proxy_module. Именно он реализует весь функционал, о котором пойдет речь. Допустим, у вас в локальной или виртуальной сети есть какие-то сервисы, не имеющие прямого доступа из интернета. А вы хотите таковой иметь. Можно пробрасывать нужные порты на шлюзе, можно что-то еще придумывать. А можно сделать проще всего — настроить единую точку входа на все свои сервисы в виде nginx сервера и с него проксировать различные запросы к нужным серверам.

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

  1. Ранее я рассказывал о настройке чат серверов — matrix и mattermost. В этих статьях я как раз рассказывал о том, как проксировать запросы в чат с помощью nginx. Прошелся по теме вскользь, не останавливаясь подробно. Суть в том, что вы настраиваете на любом виртуальном сервере эти чаты, помещаете их в закрытые периметры сети без лишних доступов и просто проксируете запросы на эти сервера. Они идут через nginx, который у вас смотрит во внешний интернет и принимает все входящие соединения.

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

  3. Еще один популярный пример. Допустим, у вас есть сервер с гипервизором proxmox или любым другим. Вы настраиваете на одной из виртуальных машин шлюз, создаете локальную сеть только из виртуальных машин без доступа в нее извне. Делаете в этой локальной сети для всех виртуальных машин шлюз по-умолчанию в виде вашей виртуальной машины со шлюзом. На виртуальных серверах в локальной сети размещаете различные сервисы и не заморачиваетесь с настройками фаервола на них. Вся их сеть все равно не доступна из интернета. А доступ к сервисам проксируете с помощью nginx, установленным на шлюз или на отдельной виртуальной машине с проброшенными на нее портами.

  4. Мой личный пример. У меня дома есть сервер synology. Я хочу организовать к нему простой доступ по https из браузера по доменному имени. Нет ничего проще. Настраиваю на сервере nginx получение бесплатного сертификата Let’s encrypt, настраиваю проксирование запросов на мой домашний ip, там на шлюзе делаю проброс внутрь локалки на synology сервер. При этом я могу фаерволом ограничить доступ к серверу только одним ip, на котором работает nginx. В итоге на самом synology вообще ничего не надо делать. Он и знать не знает, что к нему заходят по https, по стандартному порту 443.

  5. Допустим, у вас большой проект, разбитый на составные части, которые живут на разных серверах. К примеру, на отдельном сервере живет форум, по пути /forum от основного домена. Вы просто берете и настраиваете проксирование всех запросов по адресу /forum на отдельный сервер. Точно так же можно без проблем все картинки перенести на другой сервер и проксировать к ним запросы. То есть вы можете создать любой location и переадресовывать запросы к нему на другие сервера.

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

  • Без проблем можете настроить https доступ к сервисам, при этом совершенно не трогая эти сервисы. Вы получаете и используете сертификаты на nginx сервере, используете https соединение с ним, а сам nginx уже передает информацию на сервера со службами, которые могут работать по обычному http и знать не знают о https.

  • Вы очень легко можете менять адреса, куда проксируете запросы. Допустим у вас есть сайт, его запросы проксируются на отдельный сервер. Вы подготовили обновление или переезд сайта. Отладили все на новом сервере. Теперь вам достаточно на сервере nginx изменить адрес старого сервера на новый, куда будут перенаправляться запросы. И все. Если что-то пойдет не так, можете оперативно вернуть все обратно.

С теорией закончил. Перейдем теперь к примерам настройки. В своих примерах я буду использовать следующие обозначения:







blog.zeroxzed.ruдоменное имя тестового сайта
nginx_srvимя внешнего сервера с установленным nginx
blog_srvлокальный сервер с сайтом, куда проксируем соединения
94.142.141.246внешний ip nginx_srv
192.168.13.31ip адрес blog_srv
77.37.224.139ip адрес клиента, с которого я буду заходить на сайт

Настройка proxy_pass в nginx

Рассмотрим самый простой пример. Буду использовать свой технический домен zeroxzed.ru в этом и последующих примерах. Допустим, у нас есть сайт blog.zeroxzed.ru. В DNS создана A запись, указывающая на ip адрес сервера, где установлен nginx — nginx_srv. Мы будем проксировать все запросы с этого сервера на другой сервер в локальной сети blog_srv, где реально размещается сайт. Рисуем конфиг для секции server.

server {
    listen 80;
    server_name blog.zeroxzed.ru;
    access_log /var/log/nginx/blog.zeroxzed.ru-access.log;
    error_log /var/log/nginx/blog.zeroxzed.ru-error.log;

location / {
    proxy_pass http://192.168.13.31;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    }
}

Заходим по адресу http://blog.zeroxzed.ru. Мы должны попасть на blog_srv, где тоже должен работать какой-то веб сервер. В моем случае это будет тоже nginx. У вас должно открыться содержимое, аналогичное тому, что вы увидите, набрав http://192.168.13.31 в локальной сети. Если что-то не работает, то проверьте сначала, что по адресу директивы proxy_pass у вас все корректно работает.

Посмотрим логи на обоих сервера. На nginx_srv вижу свой запрос:

77.37.224.139 - - [19/Jan/2018:15:15:40 +0300] "GET / HTTP/1. 1" 304 0 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko"

Проверяем blog_srv:

94.142.141.246 - - [19/Jan/2018:15:15:40 +0300] "GET / HTTP/1.0" 304 0 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko" "77.37.224.139"

Как мы видим, запрос сначала пришел на nginx_srv, был переправлен на blog_srv, куда он пришел уже с адресом отправителя 94.142.141.246. Это адрес nginx_srv. Реальный же ip адрес клиента мы видим только в самом конце лога. Это неудобно, так как директива php REMOTE_ADDR не будет возвращать настоящий ip адрес клиента. А он очень часто бывает нужен. Мы это дальше исправим, а пока создадим в корне сайта на chat_srv тестовую страничку для проверки ip адреса клиента следующего содержания:

<?php
echo $_SERVER['REMOTE_ADDR']
?>

Назовем ее myip.php. Перейдем по адресу http://blog.zeroxzed.ru/myip.php и проверим, как сервер определит наш адрес. Никак не определит 🙂 Он покажет адрес nginx_srv. Исправляем это и учим nginx передавать реальный ip адрес клиента на сервер.

Передача реального ip (real ip) адреса клиента в nginx при proxy_pass

В предыдущем примере мы на самом деле передаем реальный ip адрес клиента с помощью директивы proxy_set_header, которая добавляет в заголовок X-Real-IP настоящий ip адрес клиента. Теперь нам нужно на принимающей стороне, то есть blog_srv сделать обратную замену — заменить информацию об адресе отправителя на ту, что указана в заголовке X-Real-IP. Добавляем в секцию server следующие параметры:

set_real_ip_from 94.142.141.246;
real_ip_header X-Real-IP;

Полностью секция server на blog_srv в самом простом варианте получается следующей:

    server {
	listen       80 default_server;
	server_name  blog.zeroxzed.ru;
	root         /usr/share/nginx/html;
	set_real_ip_from 94.142.141.246;
	real_ip_header X-Real-IP;
        
    location / {
	index index. php index.html index.htm;
	try_files	$uri $uri/	=404;
	}

    location ~ \.php$ {
	fastcgi_pass   127.0.0.1:9000;
	fastcgi_index  index.php;
	fastcgi_intercept_errors on; 
	include fastcgi_params;
	fastcgi_param       SCRIPT_FILENAME  $document_root$fastcgi_script_name;
	fastcgi_ignore_client_abort     off;
	}

    error_page 404 /404.html;
	location = /40x.html {
    }

    error_page 500 502 503 504 /50x.html;
	location = /50x.html {
    }
}

Сохраняем конфиг, перечитываем его и снова проверяем http://blog.zeroxzed.ru/myip.php. Вы должны увидеть свой реальный ip адрес. Его же вы увидите в логе web сервера на blog_srv.

Дальше рассмотрим более сложные конфигурации.

Передача https через nginx с помощью proxy pass

Если у вас сайт работает по https, то достаточно настроить ssl только на nginx_srv, если вы не беспокоитесь за передачу информации от nginx_srv к blog_srv. Она может осуществляться по незащищенному протоколу. Рассмотрю пример с бесплатным сертификатом let’s encrypt. Это как раз один из кейсов, когда я использую proxy_pass. Очень удобно настроить на одном сервере автоматическое получение всех необходимых сертификатов. Подробно настройку let’s encrypt я рассматривал отдельно. Сейчас будем считать, что у вас стоит certbot и все готово для нового сертификата, который потом будет автоматически обновляться.

Для этого нам надо на nginx_srv добавить еще один location — /.well-known/acme-challenge/. Полная секция server нашего тестового сайта на момент получения сертификата будет выглядеть вот так:

server {
    listen 80;
    server_name blog.zeroxzed.ru;
    access_log /var/log/nginx/blog.zeroxzed.ru-access.log;
    error_log /var/log/nginx/blog.zeroxzed.ru-error.log;

    location /.well-known/acme-challenge/ {
	root /web/sites/blog.zeroxzed.ru/www/;
    }

    location / {
	proxy_pass http://192. 168.13.31;    
	proxy_set_header Host $host;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Real-IP $remote_addr;
    }
}

Перечитывайте конфиг nginx и получайте сертификат. После этого конфиг меняется на следующий:

server {
    listen 80;
    server_name blog.zeroxzed.ru;
    access_log /var/log/nginx/blog.zeroxzed.ru-access.log;
    error_log /var/log/nginx/blog.zeroxzed.ru-error.log;
    return 301 https://$server_name$request_uri; # редирект обычных запросов на https
    }

server {
    listen 443 ssl http2;
    server_name blog.zeroxzed.ru;
    access_log /var/log/nginx/blog.zeroxzed.ru-ssl-access.log;
    error_log /var/log/nginx/blog.zeroxzed.ru-ssl-error.log;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/blog.zeroxzed.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/blog.zeroxzed.ru/privkey.pem;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1. 1 TLSv1.2;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;
    ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    location /.well-known/acme-challenge/ {
	root /web/sites/blog.zeroxzed.ru/www/;
    }
    location / {
	proxy_pass http://192.168.13.31; 
	proxy_set_header Host $host;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Real-IP $remote_addr;
    }
}

Проверяем, что получилось.

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

Проксирование определенной директории или файлов

Рассмотрим еще один пример. Допустим, у вас форум живет в директории http://blog. zeroxzed.ru/forum/, вы хотите вынести форум на отдельный web сервер для увеличения быстродействия. Для этого к предыдущему конфигу добавьте еще один location.

location /forum/ {
	proxy_pass http://192.168.13.31; 
	proxy_set_header Host $host;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Real-IP $remote_addr;
        proxy_redirect default;
	}

Еще одно популярное решение. Вы можете отдавать картинки с одного сервера, а все остальное с другого. В моем примере, картинки будут жить на том же сервере, где nginx, а остальной сайт на другом сервере. Тогда у нас должна быть примерно такая конфигурация локаций.

location / {
	proxy_pass http://192.168.13.31; 
	proxy_set_header Host $host;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Real-IP $remote_addr;
	}

location ~ \.(gif|jpg|png)$ {
	root /web/sites/blog.zeroxzed.ru/www/images;
	}

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

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

Особое внимание следует уделить директивам кэширования proxy_cache, если в этом есть потребность. Можно существенно увеличить отклик веб сайта, если подходящим образом настроить отдачу кэша. Но это тонкий момент и нужно настраивать в каждом конкретном случае отдельно. Готовых рецептов тут не бывает.

Более подробно о комплексной настройке nginx читайте в отдельной большой статье с моими личными примерами.

Часто задаваемые вопросы по теме статьи (FAQ)

При использовании https нужно ли в режиме proxy_pass настраивать https и на бэкенде?

В общем случае не обязательно. Но есть некоторый софт, который не может корректно работать в таком режиме. Он не понимает, как корректно обрабатывать такую ситуацию. Может создавать ссылки вида http://site.ru:443, которые будут являться ошибочными. В таком случае необходимо настроить обмен между nginx и бэк сервером тоже https соединение.

Как наиболее простым спосбом передавать сертификат let’s encrypt с nginx на backend? Ведь обновдление и генерация сертификата происходят только на nginx.

Я в таких случаях использую 2 способа, в зависимости от ситуации. Самый простой — на сервере с nginx настроить nfs сервер, а на бэкенде подмонтировать по nfs к себе директорию /etc/letsencrypt и спокойно использовать сертификаты, как-будто они лежат локально. Второй вариант — использовать простой bash скрипт для копирования сертификатов к себе на сервер по scp. В обоих случаях надо не забыть на бэкенде перезапускать службы, которые использую сертификат, после его обновления.

При обращении с бэкенда по адресу сайта, запрос уходит на nginx proxy, так как в dns прописан его ip адрес. Из-за этого иногда не работают встроенные скрипты или проверки некоторых движков, так как они ожидают, что запрос вернется с того же сервера, с которого он был сделан. Но на практике он уходит на proxy и приходит оттуда.

В такой ситуации может помочь правка файла /etc/hosts на самом бэкенде. Сделайте там статическую запись с именем сайта и локальным ip адресом. Тогда запросы с самого сервера будут приходить на него же локально, а не на nginx proxy.

Что лучше использовать для проксирования http запросов nginx или haproxy?

Однозначного ответа на этот вопрос не может быть. В чем-то это схожий софт, но есть и существенные отличия. В общем случае, описанном в статье, принципиальной разницы нет. У haproxy в бесплатной версии есть функционал, который присутсвует только в nginx plus. Так что нужно смотреть по конкретным задачам и решать, какой продукт подойдет лучше.

Добавляет ли nginx в режиме proxy_pass дополнительные сетевые задержки?

Конечно да. Но на практике они очень малы, если nginx и целевой сервер находятся в общей локальной сети. С учетом задержек при передачи пакетов по сети интернет, этими локальными задержками можно пренебречь. Они будут ничтожно малы. Если же вы проксируете запросы через интернет, то нужно внимательно смотреть величину задержек между nginx и бэкендом. Желательно их делать минимальными, располагая сервера поближе друг к другу.

Заключение

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

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

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите подробнее программу по ссылке.

Помогла статья? Подписывайся на telegram канал автора


Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Скачать pdf

Как использовать прокси с запросами Python?

Введение

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

Предварительные требования и установка

Эта статья предназначена для тех, кто хотел бы парсить за прокси в Python. Для максимального усвоения материала полезно:

✅ Иметь опыт работы с Python 3 🐍.

✅ Python 3 установлен на вашем локальном компьютере.

Проверьте, установлены ли пакеты python-requests , открыв терминал и набрав:

 $ pip freeze

pip freeze отобразит все ваши текущие пакеты Python и их версии, поэтому проверьте, присутствует ли он. Если нет, установите его, запустив:

 $ запросы на установку pip

Как использовать прокси с запросами Python

  1. Чтобы использовать прокси в Python, сначала импортируйте пакет запросов .

  2. Затем создайте словарь прокси , определяющий соединения HTTP и HTTPS. Эта переменная должна быть словарем, который сопоставляет протокол с URL-адресом прокси. Кроме того, установите переменную url для веб-страницы, с которой вы выполняете парсинг.

Обратите внимание, что в приведенном ниже примере словарь определяет URL-адрес прокси-сервера для двух отдельных протоколов: HTTP и HTTPS. Каждое соединение сопоставляется с отдельным URL-адресом и портом, но это не означает, что они не могут быть одинаковыми

  1. Наконец, создайте переменную response , которая использует любой из методов запросов. Метод будет принимать два аргумента: созданную вами переменную URL и определенный словарь.

Вы можете использовать один и тот же синтаксис для разных вызовов API, но независимо от того, какой вызов вы делаете, вам необходимо указать протокол. 

 запросы на импорт
прокси = {
   'http': 'http://proxy.example.com:8080',
   'https': 'http://secureproxy.example.com:8090',
}
URL = 'http://mywebsite.com/example'
ответ = запросы. сообщение (url, прокси = прокси)

Методы запросов ✍️ 

 response = request.get(url)
ответ = запросы.сообщение (url, данные = {"а": 1, "б": 2})
ответ = запросы.put(url, данные=put_body)
ответ = запросы.удалить(url)
ответ = запросы. patch(url, data=patch_update)
ответ = запросы.head(url)
ответ = запросы.варианты(url)

Прокси-аутентификация 👩‍💻

Если вам нужно добавить аутентификацию, вы можете переписать свой код, используя следующий синтаксис:

 response = request.get(url, auth=('user', 'pass'))

Сеансы прокси 🕒

Вы также можете захотеть выполнить очистку с веб-сайтов, использующих сеансы, в этом случае вам нужно будет создать объект сеанса. Вы можете сделать это, сначала создав переменную сеанса и установив ее для запросов Session() 9Метод 0016. Затем, как и раньше, вы отправляете свои прокси-серверы сеанса через метод запросов, но на этот раз только передавая URL-адрес в качестве аргумента.

 запросов на импорт
сеанс = запросы.Сеанс()
session.прокси = {
   'http': 'http://10.10.10.10:8000',
   'https': 'http://10.10.10.10:8000',
}
URL = 'http://mywebsite.com/example'
ответ = session. get(url)

Переменные среды 🌱

Вы можете повторно использовать один и тот же прокси-сервер для каждого запроса, поэтому не стесняйтесь СУШИТЬ свой код, установив некоторые переменные среды:

 экспорт HTTP_PROXY='http://10.10.10.10:8000'
экспорт HTTPS_PROXY='http://10.10.10.10:1212'

Если вы решите установить переменные окружения, вам больше не нужно устанавливать прокси в вашем коде. Как только вы сделаете запрос, будет сделан вызов API!

Чтение ответов 📖

Если вы хотите прочитать свои данные:

 response = request.get(url)
text_resp = ответ.текст

JSON : для ответов в формате JSON пакет запросов предоставляет встроенный метод.

 ответ = запросы.получить(url)
json_resp = ответ.json()

Ротация прокси с запросами

Помните, мы говорили, что некоторые разработчики используют более одного прокси? Что ж, теперь вы тоже можете!

В любое время, когда вы постоянно очищаете веб-страницу, рекомендуется использовать более одного прокси-сервера, потому что велика вероятность того, что ваш парсер будет заблокирован, а это означает, что ваш IP-адрес будет заблокирован. Культура отмены очистки реальна! Итак, чтобы избежать отмены, лучше всего использовать чередующиеся прокси. Ротация прокси — это прокси-сервер, который назначает новый IP-адрес из пула прокси для каждого подключения.

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

Как чередовать IP-адреса с запросами

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

  1. Сначала импортируйте библиотеки запросов , BeautifulSoup и selection .

  2. Затем определите метод get_proxy() , который будет отвечать за получение IP-адресов для использования вами. В этом методе вы определите свой URL-адрес как любой ресурс списка прокси, который вы решите использовать. После отправки вызова API-запроса преобразуйте ответ в объект Beautiful Soup, чтобы упростить извлечение. Используйте библиотеку синтаксического анализатора html5lib для анализа HTML веб-сайта, как в браузере. Создать прокси переменная, которая использует выбор для случайного выбора IP-адреса из списка прокси, сгенерированного супом . В функции карты вы можете использовать функцию lambda для преобразования элемента HTML в текст как для извлеченных IP-адресов, так и для номеров портов.

  3. Создайте метод proxy_request , который принимает 3 аргумента:
    request_type     , URL и **kwargs . Внутри этого метода определите свой прокси-словарь как прокси-сервер, возвращенный из метод get_proxy . Как и раньше, вы будете использовать запросов , передавая свои аргументы.

 запросов на импорт
ip_addresses = [ "mysuperproxy.com:5000", "mysuperproxy.com:5001", "mysuperproxy.com:5100", "mysuperproxy.com:5010", "mysuperproxy.com:5050", "mysuperproxy.com:8080" , "mysuperproxy.com:8001",
"mysuperproxy.com:8000", "mysuperproxy.com:8050" ]
def proxy_request (тип_запроса, URL, **kwargs):
   пока верно:
      пытаться:
         proxy = random.randint(0, len(ip_addresses) - 1)
            прокси = {"http": ip_addresses(прокси), "https": ip_addresses(прокси)}
            ответ = запросы.получить(тип_запроса, URL, прокси=прокси, время ожидания=5, **kwargs)
            print(f"Используемый прокси: {proxy['https']}")
         сломать
      кроме:
         print("Ошибка, ищу другой прокси")
   вернуть ответ

Теперь вы можете парсить и вращать все сразу!🌀

Используйте прокси-режим ScrapingBee

Хотите верьте, хотите нет, есть еще одна бесплатная * альтернатива, которая делает парсинг через прокси еще проще! Такой альтернативой является прокси-режим ScrapingBee, прокси-интерфейс к API. 🐝

  1. Создайте бесплатную учетную запись на ScrapingBee. После входа в систему вы можете увидеть информацию о своей учетной записи, включая ключ API. * И не говоря уже о 1000 бесплатных кредитов API! 🍯😍

  2. Запустите следующий сценарий, передав ключ API в качестве имени пользователя прокси-сервера и параметры API в качестве пароля прокси-сервера. Вы можете пропустить пароль прокси, если параметры API по умолчанию вам подходят. :

 # Установите библиотеку Python Requests:
# запросы на установку pip
запросы на импорт
защита send_request():
    прокси = {
        "http": "http://YOUR_SCRAPINGBEE_API_KEY:[email protected]:8886",
        "https": "https://YOUR_SCRAPINGBEE_API_KEY:[email protected]:8887"
    }
    ответ = запросы.получить(
        url="http://httpbin.org/headers?json",
        прокси=прокси,
        проверить=ложь
    )
    print('Код состояния ответа HTTP: ', response. status_code)
    print('Тело ответа HTTP ответа: ', response.content)
послать запрос()

Помните, что если вы хотите использовать режим прокси , ваш код должен быть настроен так, чтобы не проверять сертификаты SSL. В этом случае это будет verify=False , так как вы работаете с запросами Python.

Это все, что нужно для отправки успешных HTTP-запросов! Когда вы используете прокси-режим ScrapingBee, вам больше не нужно заниматься ротацией прокси вручную, мы позаботимся обо всем за вас. 😎

Заключение

Хотя может показаться заманчивым начать парсинг сразу же с вашими модными новыми прокси, есть еще несколько ключевых вещей, которые вы должны знать. Для начала не все прокси одинаковы. На самом деле существуют разные типы, из которых три основных: прозрачные прокси, анонимные прокси и элитные прокси.

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

Теперь, когда мы все прояснили, пришло время начать парсинг с помощью прокси в Python . Итак, отправляйтесь туда и сделайте все запросы, которые вы можете придумать!💭

Ресурсы

  • Пакет запросов
  • **кваргс

ScrapingBee, лучший API для парсинга веб-страниц.

API ScrapingBee обрабатывает безголовые браузеры и меняет прокси для вас.

Попробуйте ScrapingBee бесплатно

на основе 30+ отзывов.

Визуализируйте свою веб-страницу, как если бы это был настоящий браузер.

Мы управляем тысячами безголовых экземпляров, используя последнюю версию Chrome. Сосредоточьтесь на извлечении необходимых данных и
не иметь дело с одновременными безголовыми браузерами, которые съедят всю вашу оперативную память и процессор.

Последняя версия Chrome
Быстро, несмотря ни на что!

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

Майк Ричи

Генеральный директор @ SeekWell

Рендеринг Javascript

Мы рендерим Javascript с помощью простого параметра, чтобы вы могли парсить каждый веб-сайт, даже одностраничные приложения, используя React, AngularJS, Vue. js или любые другие библиотеки.

Выполнить пользовательский фрагмент JS
Пользовательское ожидание выполнения всех JS

ScrapingBee помогает нам очищать многие доски объявлений о вакансиях и веб-сайты компаний без использования прокси-серверов или браузеров Chrome. Это значительно упростило наш конвейер данных .

Рассел Тейлор

Генеральный директор @ HelloOutbound

Ротация прокси

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

Большой пул прокси
Геотаргетинг
Автоматическая ротация прокси

ScrapingBee четкая документация, простой в использовании API и высокий уровень успеха сделали его легким делом.

Доминик Филлипс

Соучредитель @ CodeSubmit

Шесть конкретных способов использования ScrapingBee

Как наши клиенты используют наш API:

1. Общий веб-скрейпинг

API-интерфейс веб-скрейпинга ScrapingBee отлично подходит для общих задач веб-скрейпинга, таких как просмотр недвижимости, мониторинг цен, извлечение отзывов без блокировки . документация

2. Извлечение данных

Получение HTML — это круто, получение отформатированных данных JSON — еще лучше. Благодаря нашим простым в использовании правилам извлечения вы можете получить только те данные, которые вам нужны, с помощью одного простого вызова API. узнать больше

3. Сценарий JavaScript

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

4. Скриншоты

Нужен скриншот этого сайта, а не HTML? Вы можете сделать это очень легко с нашей функцией скриншота. Мы также поддерживаем полную страницу и частичные скриншоты! узнать больше

5. Страница результатов поисковой системы

Очистка страниц результатов поисковой системы чрезвычайно болезненна из-за ограничений скорости. Благодаря нашему API поиска Google это стало проще, чем когда-либо. узнать больше

6. Веб-скрапинг без кода

Если кодирование не для вас, вы можете использовать нашу интеграцию с Make для создания собственных механизмов веб-скрапинга, не написав ни одной строки кода! узнать больше

Ты в отличной компании.

Более 500 клиентов по всему миру используют ScrapingBee для решения своих задач по очистке веб-страниц.

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

Антон Р

★★★★★

CTO (см. на Capterra)

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

Максим Ю.

★★★★★

Менеджер по продукту @ NordFolk (см. на Capterra)

Я кандидат наук, у меня нет абсолютно никакого опыта веб-скрейпинга, и мне нужно было собрать некоторые данные для диссертационного проекта. ScrapingBee помог мне быстро и легко выполнить работу . Отличная поддержка клиентов тоже. Не может быть счастливее!

Сэм

★★★★★

Кандидат наук (см. на Capterra)

Отличный инструмент SaaS для законного парсинга и извлечения данных. ScrapingBee упрощает автоматическое извлечение данных с сайтов , которые публикуют периодические данные в удобном для чтения формате.

Энди Хоукс

Основатель @Loadster

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

Жан Девиль

Основатель @DongFang Hour

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

Майк П.

★★★★★

VP (см. на Capterra)

Хороший опыт. Я нашел этот прокси-сервис более эффективным по сравнению с предыдущими, которые использовались. Это быстро и эффективно.

Ааюши

★★★★★

Старший аналитик (см. на Capterra)

Отличный сервис, рад, что мы сделали переход! Мы всегда могли выделить ресурсы и построить свои собственные системы для всего... или мы могли бы просто вызвать API-интерфейс scrapingBee и сосредоточиться на данных. Это делает нашу работу намного проще.

Дэниел Л.

★★★★★

Ведущий разработчик (см. на Capterra)

Простое и прозрачное ценообразование.

Отменить в любое время, без вопросов!

Кредиты API

Параллельные запросы

Рендеринг JavaScript

Ротационные и премиум прокси

Геотаргетинг

Скриншоты, правила извлечения, Google Search API

Приоритетная поддержка по электронной почте

Выделенный менеджер по работе с клиентами

Управление командой

Рекомендуется
Внештатный
49 долларов/mo

100 000

1

-

-

-

Попроб.

Рекомендуется
Запуск
$99/мес.

1 000 000

10

-

-

Попроб.

Рекомендуется
Бизнес
$249/мес.

2 500 000

40

Попроб.

Рекомендуется
Предприятие
$999+/мес

12 500 000+

200+

Расчет в один клик

Не знаете, какой план вам нужен? Попробуйте ScrapingBee с 1000 бесплатных вызовов API.

(кредитная карта не требуется)

Разработчики спрашивают...

Что произойдет, если запрос не будет выполнен?
Мы взимаем плату только за успешные запросы, то есть возврат с кодом состояния 200 или 404.

Мне нужно более 2 500 000 кредитов в месяц!
Мы вас прикрыли! Просто свяжитесь с нами по адресу contact@scrapingbee. com, мы пообщаемся и создадим для вас индивидуальный план!

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

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

Что такое кредит API?
Каждый план дает определенное количество кредитов API в месяц. В зависимости от параметров, которые вы используете при вызовах API, это будет стоить вам от одного до нескольких кредитов. По умолчанию каждый запрос стоит 5 кредитов, поскольку рендеринг JavaScript включен по умолчанию. Узнайте больше о стоимости запросов.

Что произойдет, если у меня закончатся кредиты до окончания срока действия моей текущей подписки?
Не беспокойтесь, мы вас прикрыли. Если вам временно нужно больше кредитов, вы можете сделать две вещи. Либо обновите свой план на текущий месяц. Вы сможете понизить его позже, когда захотите. Или вы можете досрочно продлить текущую подписку в два клика.

Могу ли я отменить свой план в любое время?
Да, вы можете отменить подписку в любое время. Это можно сделать менее чем за 30 секунд с панели управления.

Кто мы?

Разработчики, разработчики, разработчики!

Полную историю можно прочитать здесь.

Кевин Сахин
Соучредитель

Кевин — эксперт по веб-скрейпингу и автор книги Java Web Scraping Handbook. Он участвовал во многих веб-скрейпингах.
проектов для банков, стартапов и интернет-магазинов.

This entry was posted in Популярное