Прокси хост что это: Как узнать свой прокси-сервер – ip адрес и порт

Как узнать свой прокси-сервер – ip адрес и порт

Многие пользователи, которые хотят безопасно путешествовать по Интернету, озадачены вопросом «Как узнать свой прокси-сервер?». Важность и нетривиальность поднятого вопроса объясняется назначением прокси. Его основная задача — скрыть личный IP пользователя, путем его замены на другой адрес.

Чаще всего, данная услуга востребована в сфере SMM, где нужно заходить под разными аккаунтами в социальных сетях с одного компьютера. Это сводит к нулю риск блокировки аккаунтов и не вызывает подозрений со стороны модераторов. Иногда, используют европейские прокси или IP других стран. Для иллюстрации поднятой проблемы, вспомните случаи, когда заходили на зарубежный сайт с желанием посмотреть видеоролик или воспользоваться сервисами, но появлялось предупреждение о том, что просмотр ограничен для вашего региона. Такие ситуации возникают сплошь и рядом, но из-за отсутствия подкованности в вопросе, как узнать свой прокси сервер и порт, эти проблемы могут казаться нерешаемыми. Более того, это существенно обедняет возможности пользователя в получении полезной информации, которую можно было бы получить при наличии соответствующего знания.

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

Как узнать адрес прокси сервера — первый способ

Узнать также просто как и настроить прокси в Mozilla Firefox или в любом другом браузере. Для этого открываем программу, и находим: Инструменты->Настройки->Дополнительные, а после нажимаем на вкладку «Сеть». Там выбираем «настроить» и перед нами появляется окошко с настройкой прокси. Если черная точка стоит возле «Без прокси», вы не используете proxy в данный момент. Если же отмечен пункт «Ручная настройка прокси», то нужно обратить внимание на поле под названием «HTTP прокси». Цифры, указанные в данном поле — ip адрес вашего proxy сервера.

Купить анонимные прокси США сейчас!

Второй способ

Выражаясь фигурально, не всегда следует «лезть в гору», чтобы добиться желаемого пункта назначения. Иногда нужно проявить смекалку и «гору» тактично обойти. Ответ, как узнать адрес прокси, можно получить самым простым способом. Все что нужно — обратиться к системному администратору, который обслуживает локальную сеть. У него хватит компетенции посмотреть прокси и передать его вам. Сложность в том, что не все могут узнать, как связаться с системным администратором. Для решения данной проблемы, рекомендуем обратиться к более знающим людям. Они подскажут, куда звонить, чтоб связаться с администратором.

Третий способ

В панели управления своего компьютера, найдите и откройте пункт «сетевое окружение». В нем нажмите «отобразить сетевые подключения», а затем «подключения по локальной сети». Кликните по нему правой кнопкой и выберите свойства. В открывшемся окне необходимо найти протокол интернета TPC\IP. Опять выбираем «свойства». Если там стоит галочка возле «автоматически получать ip адрес», то никакого выделенного прокси не задействовано, если там будут цифры (например, 10.0.0.20), то это и будет адрес искомого proxy.

Как узнать порт прокси

Помимо адреса и пароля, многих пользователей может заинтересовать и вопрос как узнать порт прокси. Это еще один параметр, который используется при работе со своим прокси любого типа. Как правило, используются стандартные значения для порта: 8080, 80 и пр. Лишь в редких случаях значение отличается. Адрес порта можно посмотреть в браузере, выполнив действия, описанные выше. Его значение вписывается рядом с ip адресом. Рабочий порт, по которому в действительности подключается свой proxy, должен соответствовать заявленному значению в настройках системы или браузера, иначе у вас не будет работать соединение с интернетом.

Что такое прокси-сервер, зачем он нужен и как его настроить?

Поговорим о вечно актуальном: как обойти блокировку Hulu, как не остаться без Телеграма, если кто-то психанет и захочет его заблокировать, и как оставить без полезного трафика некоторые не особо качественные сайты. Поговорим о прокси-серверах.

Что такое прокси-сервер?

Прокси-сервер — это дополнительное звено между вами и интернетом. Некий посредник, который отделяет человека от посещаемого сайта. Создает условия, при которых сайт думает, что прокси — это и есть реальный человек. Только не вы. 

Такие посредники довольно многофункциональны и используются в нескольких сценариях:

1. Для обеспечения конфиденциальности. Чтобы сайты не знали, кто именно их посещает.
2. Для повышения уровня безопасности при выходе в сеть. Базовые атаки будут направлены именно на прокси.
3. Еще он нужен, чтобы получать доступ к контенту, который «существует» только в определенной локации.
4. Чтобы ускорить доступ к некоторым ресурсам в интернете.
5. Ну и для того, чтобы получить доступ к заблокированным страницам. Сайтам, мессенджерам и так далее.

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

Еще немножко об IP-адресе

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

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

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

Типы прокси-серверов

Косвенно я уже упомянул о том, что proxy бывают разными. Зачастую тип сервера сопоставим с задачами, которые он выполняет. Но для начала мы обсудим именно базовую типизацию proxy, а потом более подробно поговорим о том, какие проблемы эти серверы решают. 

Прозрачные

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

Анонимные

Более востребованный тип прокси. В отличие от первого, он тоже заявляет посещаемому ресурсу о своей proxy-сущности, но личные данные клиента не передает. То есть будет предоставлять обезличенную информацию для обеих сторон. Правда, неизвестно, как поведет себя сайт, который на 100% знает, что общается с proxy. 

Искажающие

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

Приватные

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

Другие подкатегории

Прокси-серверы отличаются друг от друга и технически. Существуют: 

• HTTP-прокси. Самые распространенные. Используются для веб-браузинга. Но они небезопасные, поэтому лучше выбирать другие.
• HTTPS. То же самое, что и HTTP, только с шифрованием. Можно смело использовать для выхода на заблокированные сайты типа Pandora или Hulu.
• SOCKS. Вариация протокола, работающая с разными типами трафика. Более гибкая и безопасная.

Зачем нужен прокси-сервер?

На плечи proxy возлагают много задач. Сейчас подробно обсудим каждую.

Фильтрация доступных ресурсов

Распространенный сценарий использования в общественных сетях. С помощью такого сервера можно наблюдать за трафиком и при необходимости его «фильтровать». Это как родительский контроль. Только масштабы иные. Подобный proxy запросто могут поднять в крупной компании, чтобы сотрудники не лезли в Твиттер, пока занимаются делами. Поэтому при входе в соцсеть может вылезти предупреждение с просьбой заняться работой. Ну или вместо этого начальник просто зафиксирует все время пребывания в Фейсбуке, а потом вычтет это из зарплаты. С детьми ситуация примерно такая же. Можно ограничить их свободу в сети на время выполнения домашнего задания, к примеру. 

Ускорение работы интернета

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

Сжатие данных

Тоже весьма практичный сценарий. Помогает заметно снизить количество затрачиваемого трафика. На некоторых прокси установлены инструменты, которые сжимают весь запрашиваемый контент перед тем, как перенаправить его к конечному пользователю. По такому принципу работает «Турбо-режим» в браузерах Opera и Яндекса. Сжатие происходит на прокси-сервере, только он загружает полную версию медиа-контента и берет на себя всю нагрузку. А клиент уже скачивает те же данные, только в облегченном виде. Поэтому люди с лимитированным трафиком от этого выигрывают.

Конфиденциальность

Если возникают беспокойства за частную жизнь, то можно настроить приватный или анонимный шлюз, который будет всячески скрывать информацию о компьютере, который сделал первоначальный запрос (уберет его IP-адрес как минимум). Ими пользуются как отдельные личности, уставшие от слежки рекламистов, так и крупные корпорации, не желающие мириться со шпионажем со стороны конкурентов, например. Это, конечно, не панацея, но самые примитивные проблемы, связанные с конфиденциальностью, прокси решить может. А еще он не требует большого количества ресурсов и времени на реализацию.

Безопасность

Прокси может обезопасить не только частную жизнь, но и защитить от реальных угроз вроде вирусов. Можно настроить шлюз таким образом, чтобы он не принимал запросы с вредоносных ресурсов. И превратить получившийся прокси в своего рода массовый «антивирус», через который можно выпускать всех сотрудников компании, не переживая, что те нарвутся на какую-нибудь серьезную угрозу. Конечно, это не защитит пользователей на 100%, но зато даст небольшой прирост безопасности. А он тоже дорогого стоит. Поэтому proxy, используемые именно для защиты, не такая уж редкость. 

Доступ к запрещенному контенту

Еще шлюз можно использовать, чтобы обойти региональные запреты. Это работает как с веб-страницами, так и с веб-приложениями. Можно смотреть заграничную библиотеку Netflix, слушать американский музыкальный сервис Pandora, смотреть что-то в Hulu и так далее. Можно заходить на сайты, которые блокируются конкретно в вашей стране. Или случайно заблокированные провайдером. Причем это могут быть совсем безобидные сайты. Я, например, долго не мог зайти на форум sevenstring.com. Ну и всем известная история с Телеграмом, который из недолгого забвения вытащили как раз таки proxy-серверы.

Сравнение прокси с VPN

VPN лучше как в плане безопасности, так и в плане удобства, но такая сеть чаще стоит приличных денег. Зачастую VPN сложнее в настройке и работают не так быстро. Сами посудите, вам обязательно нужен клиент для работы с виртуальными сетями или как минимум разрешения для браузера. Через proxy же можно подключаться, не устанавливая на компьютер ничего. 

Риски, которые несет с собой использование прокси

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

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

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

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

Лучшие бесплатные прокси-серверы

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

Hide My Ass

Популярный анонимайзер от разработчиков антивируса Avast. Работает как расширение для Chrome и Firefox. Бесплатно разрешает подключиться к серверами из 5 стран. В их числе Германия, Нидерланды и США. Из особенностей можно отметить функцию автоматического включения при попытке зайти на некоторые сайты. Например, если заходите на американскую Pandora, то proxy включится сам. 

Hotspot Shield

Это VPN-сервис с недурственной репутацией. Помимо предоставления доступа к VPN, у бренда есть как минимум 4 proxy-сервера, которыми можно пользоваться бесплатно. Для этого надо установить одноименное приложение на смартфон или расширение для браузера. Они тоже распространяются бесплатно. 

ProxySite

Удобный сайт для быстрого доступа к Proxy-серверам. Работает как шлюз в духе Hide My Ass. Просто заходите на страницу, вводите адрес сайта, на который хотите попасть, а затем указываете страну, из которой хотите зайти. Тут даже есть несколько ссылок на популярные сайты, на которые часто заходят через прокси.

Как выбрать proxy-сервер?

Есть 5 факторов, на которые стоит положиться при выборе прокси:

1. Хорошая репутация. Сами понимаете, подключаться к прокси, который уже когда-то скомпрометировали, не самая удачная идея.
2. Большое количество серверов. Так меньше шансов, что соединение вдруг оборвется. И всегда будет из чего выбрать. Можно будет указать сервер рядом со своей страной, чтобы увеличить скорость работы. Или выбрать тот, где работают нужные сервисы и веб-сайты.
3. Подробная информация о серверах. Важно знать, где он расположен, какие технологии используются. Что за протокол, есть ли шифрование и так далее.
4. Прокси-сервер должен собирать о вас минимум информации. Я не верю, что есть такие серверы, которые не собирают ее совсем, но платные и престижные делают это по минимуму. Да и используют ее исключительно в своих целях. Без продажи и передачи государственным органам.
5. Дополнительные механизмы обеспечения безопасности. Некоторые прокси блокируют вредоносные ресурсы, фильтруют рекламные баннеры, шифруют передаваемые данные и делают прочие полезные штуки.

Где найти proxy для ручной настройки?

Есть такой сайт как Hide My. На нем есть встроенный фильтр бесплатных proxy-серверов. Их там сотни. Можно выбрать страну, скорость, протокол, тип шифрования. В общем, что угодно. 

Это работает так: 

• Заходим на Hide My.
• Настраиваем фильтры.

• Потом копируем адрес, порт и выбираем подходящий протокол.

Настраиваем прокси-сервер

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

Итак, как настроить proxy-сервер:

На компьютере

Тут тоже есть два разветвления. Одна инструкция для настройки шлюза во всей системе, а вторая — только для браузера. Начнем с первой.

В системе

Чтобы настроить Proxy-сервер в Windows 10, делаем следующее:

• Открываем основные настройки системы.
• Выбираем пункт настроек «Сеть и интернет».
• Затем переходим в подпункт «Прокси».

• Спускаемся до блока настроек «Настройка прокси вручную».
• Переводим тумблер «Использовать прокси-сервер в положение «Вкл.».
• Вводим адрес прокси-сервер и порт в соответствующие поля. 

• Затем нажимаем на кнопку «Сохранить».

На этом все. В macOS и Linux принцип тот же. Даже меню в настройках со схожими названиями. Проблем возникнуть не должно. 

В браузере

Чтобы настроить прокси-сервер в Firefox, делаем следующее:

• Открываем основное меню браузера.

• Затем переходим в настройки Firefox.

• Листаем меню настроек до конца вниз, пока не доберемся до пункта «Настройки сети». Открываем их.

• Выбираем режим ручной настройки прокси.

• Вводим адрес и номер порта в соответствующие поля.

Для каждого типа прокси тут есть отдельная строка. Главное, не перепутать и ввести нужные данные в верные поля.

В телефоне или планшете

Покажу, как настроить proxy-сервер в iOS. Для этого:

• Открываем основные настройки устройства.

• Затем кликаем по вкладке Wi-Fi.

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

• Листаем вниз до пункта с настройками прокси и переходим в него.

1. Выбираем ручной режим настройки.
2. Указываем адрес и порт прокси-сервера.
3. Нажимаем на кнопку «Сохранить».

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

Создаем свой прокси-сервер

Чтобы быть менее зависимым от владельцев конкретных прокси-серверов, можно поднять свой. 

• Сначала арендуем виртуальный сервер (VPS/VDS) и фиксируем его IP-адрес.
• Затем скачиваем и устанавливаем программу PuTTY.
• Открываем вкладку Session и в поле Host Name (or IP address) вводим адрес арендованного сервера.
• После переходим в подпункт Connection.
• Меняем значение напротив строчки Seconds between keepalives (0 to turn off) на 100.
• Потом проходим по пути Connection/SSH/Tunnels в боковой панели меню.
• В строчке Source Port вводим номер 3128.
• Ставим галочку напротив пунктов Dynamic и Auto.
• А затем нажимаем на кнопку Open.

Все. Теперь надо только подключиться к своему серверу. Это можно сделать так же, как я уже описывал в инструкции к браузеру Firefox. Только надо:

1. Выбрать протокол SOCKS.
2. Указать в качестве адреса localhost.
3. Указать порт 3128.

Теперь вам известно, что такое прокси-сервер, как он функционирует и зачем может понадобиться. Засим откланяюсь. Более мне вам поведать не о чем.

Как узнать свой прокси? Определяем IP-адрес и порт прокси-сервера

Александр Попов

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

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

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

Что такое адрес и порт прокси-сервера

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

В случае с прокси, адрес – это набор из четырех 3-значных чисел (от 0 до 255) вида «243.446.7.234». То есть «село», куда мы отправляем письмо. Порт — число  в диапазоне от 0 до 65535, это наша любимая «бабушка».

Читайте также: Чем отличаются серверные прокси от мобильных

3 способа узнать свой прокси

Рассмотрим 3 самых простых способа определений адреса и порта прокси-сервера.

Сервис Socproxy.ru/ip

Зайдите на страницу https://socproxy.ru/ip в любом браузере с мобильного телефона или на компьютере.

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

Кроме этого, показываются следующие данные:

• местоположение;
• провайдер;
• user-agent;
• информация о клиенте (операционная система и браузер).

Утилита SocialKit Proxy Checker

Скачайте и установите утилиту SocialKit Proxy Checker. Она вам в любом случае понадобится если вы планируете постоянно использовать в работе прокси и поможет проверять прокси на валидность.

После скачивания, запустите программу на ПК. Откройте вкладку «Информация о соединении по умолчанию».

Здесь вы найдёте данные о текущем подключение к сети Интернет, в том числе IP-адрес.

Настройки браузера

Если у вас используются прокси в настройках браузера, то узнать его параметры можно там же. Для этого откройте браузер на своём ПК. Для примера возьмём Google Chrome. Открываем настройки браузера.

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

Появится окно, где вы можете посмотреть текущие параметры прокси, а именно IP-адрес прокси-сервера и номер порта (он стоит после двоеточия). Если используется логин и пароль, то они также будут показаны здесь.

Заключение

Честно сказать, определение адреса и порта прокси не самая часто возникающая потребность… Но если всё же перед вами встал вопрос «Как узнать свой прокси», то теперь вы знаете, где найти ответ на него.

Тем временем, мы советуем использовать только платные и проверенные прокси, которые можно купить у нас на сайте.

Как узнать прокси сервер и порт

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

Начнем с азов

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

• Платные прокси-сервера (мы их, конечно, поставили на первое место). Они перенаправляют весь трафик с компьютера пользователя, после чего отследить его перемещение в сети практически невозможно.
• Анонимайзеры. Можно выбрать одну из множества коммерческих утилит наподобие Cyberghost или SecurityKISS, но трафик в бесплатной версии вам будут выдавать в час по чайной ложке.
• Специальные версии браузеров. С введением блокировки множества популярных ресурсов широкую популярность в народе приобрел браузер Tor, функционирующий на основе множества бесплатных прокси-серверов. Вариант далеко не идеальный, но если иного выхода нет, им вполне можно воспользоваться.

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

Адрес и порт прокси-сервера: разбираемся в основах

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

Адрес – это набор из четырех 3-значных чисел (от 0 до 255) вида «192.168.0.254». По сути, это та «деревня», куда мы хотим отослать письмо. Далее после двоеточия указывается еще одно число в диапазоне от 0 от 65535 – наш любимый «дедушка».

Как узнать свой прокси-сервер и порт: собственно, ответ на вопрос

Теперь вы подкованы, и мы готовы изложить всю суть. Здесь возможно несколько вариантов:

• Сервис 2ip.ru. Зайдя на этот ресурс, вы получите исчерпывающую информацию о способе подключения своего компьютера к сети интернет. Но если при доступе в интернет используется технология анонимного доступа, узнать фактический адрес прокси-сервера и номер порта практически невозможно.
• В настройках браузера. У каждого из них они свои. Так, например, у «всеми любимого» Internet Explorer соответствующая информация скрыта здесь: «Свойства обозревателя» — «Подключение» — «Настройка». (о настройке прокси в Firefox читайте по указанной ссылке)
• В настройках ОС. Здесь многое зависит от версии Windows и «прямоты рук» человека, который ее настраивал. Если был использован «правильный» драйвер hands.sys (а это бывает далеко не всегда), то в Windows 10 эта информация находится по адресу «Параметры» — «Сеть и Интернет» — «Прокси» (рекомендуем к прочтению — Настройка прокси-сервера в windows 10).

После того, как адрес прокси был определен (или этого proxy вовсе не было прописано), часто пользователь приходит к выводу, что можно бы поменять сервер на более надежный. Здесь мы готовы дать один очевидный, но не всеми используемый совет…

… выбирайте платные прокси-серверы!

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

Free-версия – тоже неплохой вариант, но, переключаясь на нее, вы фактически доверяете свою сетевую безопасность непонятно кому. И если сравнивать такую схему работы с платным прокси-сервером, все параметры работы которого изначально известны, аргументов в пользу «сладкого уксуса» останется гораздо меньше. По крайне мере, если стабильность для вас – не пустой звук.

Итак, мы рассказали не только о том, как узнать прокси-сервер и порт, но и много смежной полезной информации. Были рады вам помочь.

Proxy List — бесплатный список прокси серверов

Проксируем и спасаем / Хабр

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

В данном пособии мы узнаем как быстро и просто сделать рабочее зеркало любого сайта, что позволяет сменить IP и назначить любое доменное имя. Мы даже попробуем спрятать домен в url, после чего можно сохранить локально полную копию сайта. Все упражнения можно сделать на любом виртуальном сервере — лично я использую хостинг Хетцнер и OS Debian. И конечно мы будем использовать лучший веб-сервер всех времен и народов — NGINX!

К этому абзацу пытливый читатель уже приобрел и настроил какой нибудь выделенный сервер или просто запустил Linux на старом компьютере под столом, а так же запустил Nginx последней версии со страничкой «Save me now».

Перед началом работы необходимо скомпилировать nginx c модулем ngx_http_substitutions_filter_module, прежнее название — substitutions4nginx.

Дальнейшая конфигурация будет показана на примере сайта www.6pm.com. Это сайт популярного онлайн магазина, торгующего товарами с хорошими скидками. Он отличается категорическим нежеланием давать доступ покупателям из России. Ну чем не оскал цензуры капитализма?

У нас уже есть работающий Nginx, который занимается полезными делом — крутит сайт на системе Livestreet о преимуществах зарубежного шоппинга. Чтобы поднять зеркало 6pm прописываем DNS запись с именем 6pm.pokupki-usa.ru который адресует на IP сервера. Как вы понимаете, выбор имени для суб-домена совершенно произволен. Это имя будет устанавливаться в поле HOST при каждом обращении к нашему новому ресурсу, благодаря чему на Nginx можно будет запустить виртуальный хостинг.

В корневой секции конфигурации nginx прописываем upstream — имя сайта-донора, так будем его называть в дальнейшем. В стандартных гайдах сайт обычно называется back-end, а reverse-proxy называется front-end.

http {
    ...
    upstream 6pm { server www.6pm.com; }

Дальше нужно создать секцию server, вот как она выглядит

    server {
        listen          80;
        server_name     6pm.pokupki-usa.ru;
        limit_conn  gulag 64;

        access_log   /var/log/nginx/6pm.access.log;
        error_log    /var/log/nginx/6pm.error.log;

        location / {
            root /var/www/6pm;
            try_files $uri @static;
        }
        location @static {

            include '6pm.conf';
            proxy_cookie_domain 6pm.com 6pm.pokupki-usa.ru;

            proxy_set_header Accept-Encoding "";
            proxy_set_header      Host     www.6pm.com;
            proxy_pass http://6pm;

            proxy_redirect http://www.6pm.com http://6pm.pokupki-usa.ru;
            proxy_redirect https://secure-www.6pm.com https://6pm.pokupki-usa.ru;
        }
    }

Стандартные директивы listen и server определяют имя виртуального хоста, при обращении к которому будет срабатывать секция server. Файлы логов лучше сделать отдельными.

Объявляем корневой локейшин, указываем путь до его хранилища — root /var/www/6pm; затем используем try_files. Это очень важная директива nginx, которая позволяет организовать локальное хранилище для загруженных файлов. Директива сначала проверяет нет ли файла с именем $uri и если не находит его — переходит в именованный локейшин @ static

$uri — переменная nginx, которая содержит путь из HTTP запроса

Префикс “@” задаёт именованный location. Такой location не используется при обычной обработке запросов, а предназначен только для перенаправления в него запросов. Такие location’ы не могут быть вложенными и не могут содержать вложенные location’ы

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

include ‘6pm.conf’ — логика модуля substitutions.

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

proxy_set_header Accept-Encoding «»; — очень важная команда, которая заставляет сайт донор отдавать вам контент не в сжатом виде, иначе модуль substitutions не сможет выполнить замены.

proxy_set_header Host — еще одна важная команда, которая в запросе к сайту донору выставляет правильное поле HOST. Без нее будет подставляться имя нашего прокси сервера и запрос будет ошибочным.
proxy_pass — прямая адресация не работает в именованном локейшине, именно поэтому мы прописали адрес сайта донора в директиве upstream.
proxy_redirect — многие сайты используют редиректы для своих нужд, каждый редирект нужно отловить и перехватить здесь, иначе запрос и клиент уйдет за пределы нашего уютного доменчика.

Теперь посмотрим содержимое 6pm.conf. Я не случайно вынес логику трансформации в отдельный файл. В нем можно разместить без какой либо потери производительности тысячи правил замены и сотни килобайт фильтров. В нашем случае мы хотим лишь завершить процесс проксирования, поэтому файл содержит всего 5 строк:

Меняем коды google analytics:

subs_filter 'UA-8814898-13' 'UA-28370154-3' gi;
subs_filter "'.6pm.com']," "'6pm.pokupki-usa.ru']," gi; 

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

Меняем все прямые ссылки на новые.

subs_filter "www.6pm.com" "6pm.pokupki-usa.ru" gi;
subs_filter "6pm.com" "6pm.pokupki-usa.ru" gi;

Как правило, в нормальных сайтах все картинки лежат на CDN сетях, которые не утруждают себя проверкой источника запросов, поэтому достаточно замены ссылок только основного домена. В нашем случае 6pm выпендрился и разместил часть картинок на доменах, которые отказывают посетителям из России. К счастью, модуль замены поддерживает регулярные выражения и не составляет никакого труда написать общее правило для группы ссылок. В нашем случае обошлось даже без regexp, просто поменяли два символа в домене. Получилось так:

subs_filter "http://a..zassets.com" "http://l3.zassets.com" gi;

Единственное, но очень серьезное ограничение модуля замены — он работает только с одной строкой. Это ограничение заложено архитектурно, поскольку модуль работает на этапе, когда страница загружена частично (chunked transfer encoding) и нет никакой возможности выполнить полнотекстовый regexp.

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

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

1. Абсолютные ссылки вида «www.example.com/some/path»
2. Ссылки относительно корня сайта вида «/some/path»
3. Относительные ссылки вида «some/path»

С п.1 все просто — мы заменяем все ссылки на новый путь с поддиректорией

С п.3 так же просто — мы ничего не трогаем и все работает само если не использовался атрибут base href. Если этот атрибут используется, что бывает крайне редко в современных сайтах, то достаточно его заменить и все будет работать.

Настоящая сложность возникает с п.2. из-за того что мы должны изменить кучу ссылок вида /… на /subdomain/…. Если сделать это в лоб, то сайт скорее всего полностью перестанет работать, ибо такая замена сломает множество конструкций использующих слеш, что испортит почти все скрипты javascript.

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

Вернемся к нашему пациенту:

        location /6pm {
            root /var/www/6pm;
            try_files $uri @6pm-static;
            access_log   /var/log/nginx/6pm.access.log;
        }
        location @6pm-static {
            include '6pm2.conf';
            proxy_cookie_domain 6pm.com pokupki-usa.ru;
            proxy_cookie_path / /6pm/;

            rewrite ^/6pm/(.*) /$1 break;

            proxy_set_header Accept-Encoding "";
            proxy_set_header      Host     www.6pm.com;
            proxy_pass http://6pm;

            proxy_redirect http://www.6pm.com http://pokupki-usa.ru/6pm;
            proxy_redirect http://www.6pm.com/login http://pokupki-usa.ru/6pm;
            proxy_redirect https://secure-www.6pm.com https://pokupki-usa.ru/6pm;

Конфигурация сервера претерпела некоторые изменения.

Во-первых, вся логика перенесена из директивы sever напрямую в location. Нетрудно догадаться, что мы решили создать директорию /6pm в которую будем выводить проксируемый сайт.

proxy_cookie_path / /6pm/ — переносим куки из корня сайта в поддиректорию. Это делать не обязательно, но в случае если проксируемых сайтов окажется много, их куки могут пересечься и затереть друг друга.

rewrite ^/6pm/(.*) /$1 break; — эта магия вырезает из клиентского запроса поддиректорию, которую мы добавили, в результате директива proxy_pass отправляет на сервер-донор корректное значение.

Чуть сложнее стало ловить редиректы. Теперь все ссылки на корень нужно перебросить на /6pm.

Посмотрим на логику трансформации:

subs_filter_types text/css text/javascript;

# Fix direct links
subs_filter "http://6pm.com" "http://pokupki-usa.ru/6pm" gi;
subs_filter "http://www.6pm.com" "http://pokupki-usa.ru/6pm" gi;

# Fix absolute links
subs_filter 'src="/' 'src="/6pm/' gi;
subs_filter 'href="/' 'href="/6pm/' gi;
subs_filter 'action="/' 'href="/6pm/' gi;

# Fix some js
subs_filter "\"/le.cgi" "\"/6pm/le.cgi" gi;
subs_filter "\"/track.cgi" "\"/6pm/track.cgi" gi;
subs_filter "\"/onload.cgi" "\"/6pm/onload.cgi" gi;
subs_filter "\"/karakoram" "\"/6pm/karakoram" gi;
subs_filter "/tealeaf/tealeaf.cgi" "/6pm/tealeaf/tealeaf.cgi" gi;

# Css and js path
subs_filter "script\('/" "script('/6pm/" gi;
subs_filter "url\(/" "url(/6pm/" gi;

subs_filter 'UA-8814898-13' 'UA-28370154-3' gi;
subs_filter "'.6pm.com']," "'pokupki-usa.ru/6pm']," gi;

subs_filter "http://a..zassets.com" "http://l3.zassets.com" gi;

Во-первых, мы включили фильтрацию файлов css и javascript (парсинг html включен по-умолчанию)

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

В итоге получилось так: http://pokupki-usa.ru/6pm/

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

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

Типы прокси HTTP, HTTPS, Socks

Прокси (в переводе с английского “proxy” – доверенное лицо) – это промежуточный транзитный веб-сервер, который используется как посредник между пользователем и конечным сервером.

Основное предназначение прокси — это смена IP адреса.

Рассмотрим ситуацию, когда пользователь посещает веб-сайт Google.com через прокси. В этом случае пользователь отправляет запрос к прокси на открытие веб-сайта. Прокси от своего имени открывает веб-сайт Google.com и затем передает данные пользователю.

Виды и типы прокси

Прокси сервера бывают нескольких типов:

• FTP прокси используются для загрузки данных на FTP сервера
• CGI прокси (анонимайзеры) помогают открыть любой веб-сайт прямо в браузере. Никаких дополнительных настроек не требуется. Чаще всего такие прокси выполнены в виде веб-сайта, где можно ввести адрес сайта, который необходимо посетить
• SMTP, POP3 и IMAP прокси используются для отправки и приема электронной почты
• HTTP и HTTPS прокси предназначены для просмотра веб-страниц
• Socks прокси передает все данные на конечный сервер как клиент, поэтому считается самым анонимным протоколом

HTTP, HTTPS и Socks прокси используются чаще всего, поэтому рассмотрим их подробнее.

HTTP прокси

HTTP прокси — это самый распространенный вид прокси. Основное предназначение — организация работы браузеров и других программ, использующих TCP протокол. Стандартные порты 80, 8080, 3128.

Принцип работы: программа или браузер посылает запрос прокси-серверу на открытие определенного URL ресурса. Прокси-сервер получает данные с запрашиваемого ресурса и отдает эти данные вашему браузеру.

HTTP прокси позволяют:

• кешировать загруженные файлы (картинки, страницы) для увеличения скорости открытия веб-сайтов
• ограничивать доступ к определенным ресурсам (например, Youtube)
• фильтровать данные. Например, вместо баннеров с рекламой показывать прозрачные картинки, которые не будут нарушать дизайн сайта, но будут существенно экономить время загрузки страницы и трафик
• ограничивать скорость соединения
• вести логи, контролировать трафик по пользователям

Виды прокси по анонимности

HTTP прокси по анонимности делятся на следующие виды:

• прозрачные прокси заявляют о том, что используется прокси и передают реальный IP адрес пользователя в HTTP заголовках. Прозрачные прокси использовать опасно, так как они не обеспечивают анонимности
• анонимные прокси уведомляют, что используется прокси, но при этом не передают реальный IP адрес пользователя. Анонимные прокси не могут гарантировать настоящей анонимности, так как заявляют, что прокси используется
• элитные прокси не уведомляют, что используется прокси и не передают реальный IP адрес пользователя. Только элитные прокси можно использовать для полной анонимности

HTTPS прокси

HTTPS прокси — фактически это HTTP-прокси, буква «S» в данном случае означает «secure» (защищенный) с поддержкой защищенного SSL соединения. Эти прокси применяются, когда требуется передать секретную информацию (например, логины/пароли, номера пластиковых карт). Стандартные порты 80, 8080, 3128.

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

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

Принцип работы: прокси-сервер соединяется с ресурсом и ваш трафик шифруется. При таком методе отсутствует возможность узнать, какая именно информация передается через прокси-сервер (это ограничивает применение прокси как фильтра). Также в процессе шифрации и дешифрации прокси участия не принимает. Этим занимается клиентская программа (браузер) и целевой сервер. Таким образом, HTTPS proxy занимается пассивной передачей зашифрованной информации и не производит никакой обработки передаваемой информации. Такой метод работы позволяет использовать HTTPS proxy для передачи практически любого TCP-протокола. То есть HTTPS прокси может использоваться и как POP3, SMTP, IMAP, NNTP прокси.

Socks прокси

На сегодняшний день Socks прокси — самый прогрессивный протокол передачи информации. Иногда ошибочно называют Socs, Sox, Soks. Этот протокол разработан Дейвом Кобласом (Dave Koblas).

Протокол Socks разрабатывался для программ, которые не поддерживают использование прокси напрямую. Стандартные порты 1080, 1081.

Данный протокол пережил множество изменений и на данный момент используются две версии протокола:

• Socks 4 поддерживает только TCP соединения
• Socks 5 поддерживает TCP, UDP, авторизацию по логину и паролю и возможность удаленного DNS-запроса

Socks не занимается модерацией HTTP-заголовков. Socks-сервер будет передавать информацию через себя в чистом виде. Поэтому все Socks серверы являются анонимными.

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

Socks поддерживает все протоколы, включая HTTP, HTTPS, FTP.

Мы рекомендуем использовать Socks 5 прокси

Сравнение разных типов прокси

Таблица сравнения разных видов прокси.

Откуда берутся прокси

Прокси – это программа, которая управляет запросами от пользователя к конечному серверу. Такая программа устанавливается на компьютере пользователя или на сервере.

1. Прокси установлены на обычных компьютерах пользователя с помощью троянских программ или вирусов через ботнет. Ботнет – это сеть инфицированных компьютеров, управляемых главным компьютером. Прокси выполняет ваши запросы, действуя от лица инфицированного компьютера. Данный вид прокси предоставляет максимальную анонимность. Минус прокси — невозможно гарантировать постоянную работу прокси, так как установлены на удаленном компьютере.
2. Прокси настроены на собственных серверах. Такие прокси являются самыми надежными, так как сервер работает все время. Постоянные прокси не нужно проверять на валидность. Минус таких прокси в том, что они не могут обеспечить идеальную анонимность, так как известно кому принадлежит сервер и его можно изъять.

Платные прокси настраиваются с целью получения материальной выгоды от продажи и чаще всего отличаются уровнем анонимности.

Бесплатные прокси

В Интернете существуют веб-сайты, где публикуются бесплатные прокси. С какой целью публикуются бесплатные прокси? Ответить на этот вопрос однозначно сложно. Бесплатные прокси можно использовать для обучения работе с прокси. Бесплатные прокси подходят вам, если анонимность не важна.

Причины появления бесплатных прокси:

• неправильная настройка доступа к прокси со стороны администратора локальной сети. Администратор сети не закрыл доступ к прокси из Интернета
• университеты и учебные заведения открывают доступ через прокси к библиотеке своего университета. При этом прокси попадает в список публичных
• прокси от государственных организаций

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

Мы не рекомендуем использовать бесплатные публичные прокси.

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

Если ваша цель – это анонимное использование сети Интернет, мы рекомендуем использовать только Socks 5 прокси.

Для целей парсинга данных, SMM, SEO и онлайн игр можно использовать HTTP/HTTPS прокси.

Прокси можно настраивать в браузере или через специальные программы.

Цепочки прокси

Прокси сервера можно выстраивать в цепочки. С точки зрения анонимности и скорости работы достаточно использовать цепочку из 2 прокси в разных странах. Данные будут последовательно проходить через 2 прокси.

Помните, что Интернет-провайдер может логировать и прослушивать ваш трафик через прокси.

Мы рекомендуем использовать VPN + 2 прокси для обеспечения вашей анонимности.

Посмотреть наши прокси

прокси — что такое glassfish-jvm-option «http.proxyHost» для / когда его использовать?

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

2. Авторизоваться
   зарегистрироваться

3. текущее сообщество
   

   • Переполнение стека

     Помогите
     болтать

.

Сетевые свойства

Сетевые свойства

Есть несколько стандартных системных свойств, используемых для
изменить механизмы и поведение различных классов
пакет java.net. Некоторые проверяются только один раз при запуске виртуальной машины,
и поэтому лучше всего их устанавливать с помощью опции -D команды java,
в то время как другие имеют более динамичный характер и также могут быть изменены с помощью
API System.setProperty (). Цель этого документа — перечислить
и подробно описать все эти свойства.

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

IPv4 / IPv6

• java.net.preferIPv4Stack (по умолчанию: false)
  Если IPv6 доступен в операционной системе,
  базовый собственный сокет по умолчанию будет сокетом IPv6, который
  позволяет приложениям подключаться и принимать подключения к обоим
  Хосты IPv4 и IPv6. Однако в случае, если приложение
  используйте только сокеты IPv4, тогда для этого свойства можно установить значение true .
  Подразумевается, что это будет невозможно для приложения
  для связи только с хостами IPv6.

• java.net.preferIPv6Addresses (по умолчанию: false)
  При работе с хостом, имеющим оба IPv4
  и IPv6-адреса, и если IPv6 доступен на рабочем
  системе по умолчанию предпочтение отдается использованию адресов IPv4, а не
  IPv6. Это необходимо для обеспечения обратной совместимости, например
  приложения, которые зависят от представления IPv4-адреса
  (например, 192.168.1.1). Это свойство может быть установлено на true на
  измените это предпочтение и используйте адреса IPv6 вместо адресов IPv4, где
  возможное.

Оба эти свойства проверяются только один раз при запуске.

Прокси

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

• HTTP

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

  • http.proxyHost (по умолчанию: <нет>)
    Имя хоста или адрес прокси-сервера.

  • http.proxyPort (по умолчанию: 80)
    Номер порта прокси-сервера.

  • http.nonProxyHosts (по умолчанию: localhost | 127. * | [:: 1])
    Указывает хосты, к которым следует обращаться без перехода
    через прокси. Обычно это определяет внутренние хосты.
    Значение этого свойства — список хостов,
    разделенные знаком ‘|’ характер.Кроме того, подстановочный знак
    символ ‘*’ может использоваться для сопоставления с образцом. Например
    -Dhttp.nonProxyHosts = "*. Foo.com | localhost"
    будет указывать, что все хосты в домене foo.com и
    localhost должен быть доступен напрямую, даже если прокси-сервер
    указано.

    Значение по умолчанию исключает все общие варианты адреса обратной связи.

• HTTPS
  Это HTTP через SSL, безопасная версия HTTP
  в основном используется, когда требуется конфиденциальность (например, на сайтах оплаты).

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

  • https.proxyHost (по умолчанию: <нет>)
    Имя хоста или адрес прокси-сервера.

  • https.proxyPort (по умолчанию: 443)
    Номер порта прокси-сервера.

    Обработчик протокола HTTPS будет использовать тот же nonProxyHosts
    свойство как протокол HTTP.

• FTP

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

  • ftp.proxyHost (по умолчанию: <нет>)
    Имя хоста или адрес прокси-сервера

  • ftp.proxyPort (по умолчанию: 80)
    Номер порта прокси-сервера.

  • ftp.nonProxyHosts (по умолчанию: localhost | 127. * | [:: 1])
    Указывает хосты, к которым следует обращаться без перехода.
    через прокси. Обычно это определяет внутренние хосты.
    Значение этого свойства — список хостов, разделенных
    ‘|’ характер.Кроме того, подстановочный знак
    ‘*’ может использоваться для сопоставления с образцом. Например
    -Dhttp.nonProxyHosts = "*. Foo.com | localhost"
    будет указывать, что все хосты в домене foo.com и
    localhost должен быть доступен напрямую, даже если прокси-сервер
    указано.

    Значение по умолчанию исключает все общие варианты адреса обратной связи.

• SOCKS
  Это еще один тип прокси. Это позволяет снизить
  уровень типа туннелирования, поскольку он работает на уровне TCP.В результате,
  на платформе Java ™ установка прокси-сервера SOCKS приведет к
  все TCP-соединения должны проходить через этот прокси, если другие прокси
  указаны. Если SOCKS поддерживается реализацией Java SE,
  будут использоваться следующие свойства:

  • socksProxyHost (по умолчанию: <нет>)
    Имя хоста или адрес прокси-сервера.

  • socksProxyPort (по умолчанию: 1080)
    Номер порта прокси-сервера.

  • socksProxyVersion (по умолчанию: 5)
    Версия протокола SOCKS, поддерживаемая сервером. В
    по умолчанию 5 с указанием SOCKS V5, альтернативно
    4 можно указать для SOCKS V4. Установка свойства
    к значениям, отличным от указанных, ведет к неопределенному поведению.

  • java.net.socks.username (по умолчанию: <нет>)
    Имя пользователя для использования, если сервер SOCKSv5 запрашивает аутентификацию
    и нет java.net.Authenticator был найден.

  • java.net.socks.password (по умолчанию: <нет>)
    Пароль для использования, если сервер SOCKSv5 запрашивает аутентификацию
    и экземпляр java.net.Authenticator не найден.

    Обратите внимание, что если аутентификация не предусмотрена ни одним из указанных выше
    properties или Authenticator, а прокси требуется, то
    свойство user.name будет использоваться без пароля.

• Java.net.useSystemProxies (по умолчанию: false)
  В последних системах Windows и в системах Gnome 2.x возможно
  сообщить стеку java.net, установив для этого свойства значение true , чтобы использовать
  настройки системного прокси (обе эти системы позволяют устанавливать прокси
  глобально через их пользовательский интерфейс). Обратите внимание, что это свойство
  проверял только один раз при запуске.

Разные свойства HTTP

• http.agent (по умолчанию: «Java / <версия>»)
  Определяет строку, отправляемую в заголовке запроса User-Agent в http.
  Запросы.Обратите внимание, что строка «Java / <версия>» будет
  быть добавленным к указанному в свойстве (например, если
  -Dhttp.agent = ”foobar”, заголовок User-Agent будет
  содержать «foobar Java / 1.5.0», если версия виртуальной машины
  1.5.0). Это свойство проверяется только один раз при запуске.

• http.keepalive (по умолчанию: true)
  Указывает, должны ли поддерживаться постоянные соединения. Они улучшают
  производительность, позволяя повторно использовать базовое соединение сокета
  для нескольких HTTP-запросов.Если установлено значение true, то постоянный
  соединения будут запрашиваться с серверами HTTP 1.1.

• http.maxConnections (по умолчанию: 5)
  Если HTTP keepalive включен (см. Выше), это значение определяет
  максимальное количество неактивных соединений, которые будут одновременно сохраняться
  живые, по назначению.

• http.maxRedirects (по умолчанию: 20)
  Это целое значение определяет максимальное число для данного запроса,
  перенаправлений HTTP, за которыми будет автоматически следовать
  обработчик протокола.

• http.auth.digest.validateServer (по умолчанию: false)

• http.auth.digest.validateProxy (по умолчанию: false)

• http.auth.digest.cnonceRepeat (по умолчанию: 5)

  Эти 3 свойства изменяют поведение дайджеста HTTP.
  механизм аутентификации. Дайджест-аутентификация обеспечивает ограниченное
  возможность сервера аутентифицировать себя перед клиентом (т.е.
  Доказав, что знает пароль пользователя).Однако не все HTTP
  серверы поддерживают эту возможность и по умолчанию она отключена. В
  первые два свойства могут быть установлены в значение true, чтобы принудительно выполнить эту проверку для
  аутентификация с использованием исходного или прокси-сервера соответственно.

  Обычно нет необходимости менять третье свойство. Это
  определяет, сколько раз повторно используется значение cnonce. Это может быть
  полезно, когда используется алгоритм MD5-sess. Увеличение этого
  значение снижает вычислительные затраты как на клиенте, так и на сервере
  за счет уменьшения количества материала, который необходимо хешировать для каждого
  HTTP-запрос.

• http.auth.ntlm.domain (по умолчанию: <нет>)
  NTLM — еще одна схема аутентификации. Он использует
  java.net.Authenticator класс для получения имен пользователей и паролей, когда
  они нужны. Однако NTLM также необходимо доменное имя NT. Есть
  3 варианта указания этого домена:

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

  2. Имя домена может быть закодировано в имени пользователя с помощью
     перед доменным именем, за которым следует обратная косая черта ‘\’ перед
     имя пользователя.С помощью этого метода существующие приложения, использующие
     класс аутентификатора не нужно изменять, если пользователи
     осведомлены о том, что необходимо использовать это обозначение.

  3. Если доменное имя не указано, как в способе 2) и эти
     свойство определено, то его значение будет использоваться в домене
     имя.

Все эти свойства проверяются только один раз при запуске.

Адресный кэш

Пакет java.net-пакет при разрешении имен использует адрес
кеш как по соображениям безопасности, так и производительности. Любой адрес
попытка разрешения, будь то прямая (имя на IP-адрес) или обратная (IP
адрес для имени), результат будет кэширован, независимо от того, был ли он
успешно или нет, так что последующие идентичные запросы не будут
необходимо получить доступ к службе имен. Эти свойства позволяют некоторым
настройка того, как работает кеш.

• networkaddress.cache.ttl (по умолчанию: см. Ниже)
  Значение представляет собой целое число, соответствующее количеству успешных секунд
  поиск по именам будет храниться в кеше.Значение -1 или любое другое
  отрицательное значение в этом отношении означает «кэш навсегда»
  policy, а значение 0 (ноль) означает отсутствие кеширования. Значение по умолчанию
  равно -1 (навсегда), если установлен менеджер безопасности, а реализация
  специфичен, если не установлен менеджер безопасности.

• networkaddress.cache.negative.ttl (по умолчанию: 10)
  Значение — целое число, соответствующее количеству секунд
  неудачный поиск имени будет сохранен в кеше. Значение -1,
  или любое отрицательное значение означает «кэшировать навсегда», а
  значение 0 (ноль) означает отсутствие кеширования.

Поскольку эти 2 свойства являются частью политики безопасности, они
не устанавливается параметром -D или API System.setProperty (),
вместо этого они установлены в файле политики безопасности JRE lib / security / java.security .

Сценарий на этой странице отслеживает трафик веб-страницы, но никоим образом не изменяет содержимое.

.

Как пользоваться и где взять прокси Instagram?

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

Зачем нужен прокси для автоматизации Instagram?

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

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

Где взять прокси для Инстаграм?

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

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

Какие прокси-провайдеры рекомендуются для пользователей из Китая?

Instagram, Facebook, Twitter, Wikipedia и многие другие зарубежные интернет-инструменты и сервисы запрещены к доступу в Китае.Великий брандмауэр блокирует IP-адреса назначения и проверяет все отправленные и полученные данные. Его невозможно обойти, используя обычные методы, такие как подключение через простые открытые прокси (протоколы HTTP и SOCKS) и широко известные протоколы, такие как OpenVPN, L2TP и PPTP.

Следующие поставщики VPN обеспечивают обход цензуры и успешное подключение к Instagram с новым IP-адресом.

Как подключить инстаграм-аккаунты через прокси?

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

1. Запустить планировщик роста / комбинирования.
2. Войдите в свой аккаунт в Instagram.
3. Go Инструменты > Настройки > Прокси-сервер .

4. В окне прокси есть две категории: Общий прокси и Прокси учетной записи .

   Общий прокси-сервер предназначен для изменения общего IP-адреса, используемого всеми аккаунтами Instagram, авторизованными в Combin.Прокси-сервер учетной записи предназначен для настройки отдельных прокси для некоторых или всех учетных записей. Последнее необходимо для безопасной автоматизации активности нескольких учетных записей Instagram.

   Включить переключатель рядом с одной из учетных записей Instagram из списка

5. Выберите тип хоста и заполните поля, касающиеся хоста, порта и входа в систему через прокси.

6. Нажмите Сохранить .

7. Повторите для всех ваших учетных записей Instagram.

.Ссылка на прокси

— v0.10.x | Kong

Осторожно! Вы просматриваете документацию по поиску устаревшей версии Kong Kong Gateway. Иди сюда
для поиска последней версии в документации.

Приблизительное время прочтения:

25 минут

Введение

Kong прослушивает трафик на четырех портах, которые по умолчанию:

• : 8000 , на котором Kong прослушивает входящий HTTP-трафик от ваших клиентов,
  и пересылает его в ваши вышестоящие службы. Это тот порт, который интересует
  нас в этом руководстве.
• : 8443 , на котором Kong прослушивает входящий трафик HTTPS. Этот порт имеет
  поведение аналогично порту : 8000 , за исключением того, что он ожидает трафик HTTPS
  только. Этот порт можно отключить через файл конфигурации.
• : 8001 , на котором Admin API, используемый для настройки Kong, прослушивает.
• : 8444 , на котором Admin API прослушивает HTTPS-трафик.

В этом документе мы рассмотрим возможности маршрутизации Kong, подробно объясняя
как входящие запросы на порт : 8000 проксируются в настроенный восходящий поток
service в зависимости от их заголовков, URI и метода HTTP.

Терминология

• API : этот термин относится к API компании Kong. Вы настраиваете свои API,
  которые указывают на ваши собственные вышестоящие службы через Admin API.
• Плагин : относится к «плагинам» Kong, которые являются частями бизнес-логики.
  которые выполняются в жизненном цикле прокси. Плагины можно настроить через
  Admin API — глобально (весь входящий трафик) или отдельно для каждого API.
• Клиент или: Относится к нижестоящему клиенту , отправляющему запросы в Kong’s
  порт прокси.
• Служба разведки и добычи : относится к вашему собственному API / службе, стоящей за Kong, к
  какие клиентские запросы пересылаются.

Вернуться к TOC

Обзор

С точки зрения высокого уровня Kong будет прослушивать HTTP-трафик на своем
настроенный порт прокси ( 8000 по умолчанию), узнайте, какая восходящая служба
запрашивается, запустите настроенные плагины для этого API и перенаправьте HTTP
запросить апстрим для вашего собственного API или сервиса.

Когда клиент делает запрос к прокси-порту, Kong решает, к какому
восходящий сервис или API для маршрутизации (или пересылки) входящего запроса, в зависимости от
о конфигурации API в Kong, которая управляется через Admin API.Вы можете
настраивать API с различными свойствами, но три важных для маршрутизации
входящий трафик — это хостов , uris и методы .

Если Kong не может определить, к какому восходящему API следует отправить данный запрос
Routed, Kong ответит:

  HTTP / 1.1 404 Не найдено
Тип содержимого: приложение / json
Сервер: kong / 

{
    "message": "API с этими значениями не найдено"
}
  

Вернуться к TOC

Напоминание: как добавить API в Kong

Краткое руководство по добавлению API объясняет, как работает Kong
настраивается через Kong Admin API, работающий по умолчанию на порту 8001 .Добавить API в Kong так же просто, как отправить HTTP-запрос:

  $ curl -i -X ​​POST http: // localhost: 8001 / apis / \
    -d 'имя = мой-api' \
    -d 'upstream_url = http: //my-api.com' \
    -d 'hosts = example.com' \
    -d 'uris = / my-api' \
    -d 'методы = GET, HEAD'
HTTP / 1.1 201 Создано
...
  

Этот запрос указывает Kong зарегистрировать API с именем «my-api», доступный по адресу
«Http://example.com». Он также определяет различные свойства маршрутизации, хотя обратите внимание
что требуется только один из хостов , uris и методов .

Добавление такого API означало бы, что вы настроили Kong для проксирования всех входящих
запросы, соответствующие указанным хостам , uris и методы к
http://my-api.com . Kong — это прозрачный прокси-сервер, который пересылает
запрос к вашему восходящему сервису без изменений, за исключением добавления
различных заголовков, таких как Connection .

Вернуться к TOC

Возможности маршрутизации

Давайте теперь обсудим, как Kong сопоставляет запрос с настроенными хостами , uris
и методы свойства (или поля) вашего API.Обратите внимание, что все три из них
поля — необязательные , но должно быть указано не менее , одно из них должно быть указано. Для
запрос клиента на соответствие API:

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

Давайте рассмотрим несколько примеров.Рассмотрим API, настроенный следующим образом:

  {
    "name": "my-api",
    "upstream_url": "http://my-api.com",
    "hosts": ["example.com", "service.com"],
    "uris": ["/ foo", "/ bar"],
    "методы": ["ПОЛУЧИТЬ"]
}
  

Некоторые из возможных запросов, соответствующих этому API, могут быть:

  GET / foo HTTP / 1.1
Хост: example.com
  

  GET / бар HTTP / 1.1
Хост: service.com
  

  GET / foo / hello / мир HTTP / 1.1
Хост: пример.com
  

Все три запроса удовлетворяют всем условиям, установленным в API.
определение.

Однако следующие запросы не соответствуют заданным условиям:

  GET / HTTP / 1.1
Хост: example.com
  

  POST / foo HTTP / 1.1
Хост: example.com
  

  GET / foo HTTP / 1.1
Хост: foo.com
  

Все три запроса удовлетворяют только двум из настроенных условий. В
URI первого запроса не соответствует ни одному из настроенных uris , то же самое для
HTTP-метод второго запроса и заголовок Host третьего запроса.

Теперь, когда мы понимаем, как hosts , uris и работают со свойствами
вместе, давайте изучим каждое свойство по отдельности.

Вернуться к TOC

Маршрутизация запроса на основе его заголовка Host — самый простой способ
прокси-трафик через Kong, так как это предполагаемое использование HTTP-хоста
заголовок. Kong позволяет легко сделать это с помощью поля hosts объекта API.

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

  $ curl -i -X ​​POST http: // localhost: 8001 / apis / \
    -d 'имя = мой-api' \
    -d 'upstream_url = http: // мой-api.com '\
    -d 'hosts = my-api.com, example.com, service.com'
HTTP / 1.1 201 Создано
...
  

Для удовлетворения условия хостов этого API любой входящий запрос от
теперь у клиента должен быть установлен один из заголовков Host:

или:

или:

Вернуться к TOC

Использование подстановочных имен хостов

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

Подстановочные имена хостов должны содержать только одну звездочку в крайнем левом углу
или крайняя правая метка домена. Примеры:

• * .example.com допускает такие значения Host, как a.example.com и
  x.y.example.com для соответствия.
• example. * разрешит такие значения Host, как example.com и example.org
  чтобы соответствовать.

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

  {
    "name": "my-api",
    "upstream_url": "http: // my-api.com ",
    "hosts": ["* .example.com", "service.com"]
}
  

Что позволит следующим запросам соответствовать этому API:

  GET / HTTP / 1.1
Хост: an.example.com
  

  GET / HTTP / 1.1
Хост: service.com
  

Вернуться к TOC

Свойство preserve_host

При проксировании Kong по умолчанию устанавливает хост восходящего запроса.
заголовок к имени хоста свойства upstream_url API.В
preserve_host Поле принимает логический флаг, указывающий Конгу не делать этого.

Например, если свойство preserve_host не изменено, а API
настроен так:

  {
    "name": "my-api",
    "upstream_url": "http://my-api.com",
    "hosts": ["service.com"],
}
  

Возможный запрос от клиента к Конгу может быть:

  GET / HTTP / 1.1
Хост: service.com
  

Kong извлекает значение заголовка Host из имени хоста API
upstream_url и отправит следующий запрос в ваш апстрим
сервис:

  GET / HTTP / 1.1
Хост: my-api.com
  

Однако, явно настроив свой API с preserve_host = true :

  {
    "name": "my-api",
    "upstream_url": "http://my-api.com",
    "hosts": ["service.com"],
    "preserve_host": правда
}
  

И при том же запросе от клиента:

  GET / HTTP / 1.1
Хост: service.com
  

Kong сохранит Хост по запросу клиента и отправит следующие
запрос в службу разведки и добычи:

  GET / HTTP / 1.1
Хост: service.com
  

Вернуться к TOC

URI запроса

Другой способ для Kong направить запрос к данной восходящей службе — это
укажите URI запроса через свойство uris . Чтобы удовлетворить это поле
условие, URI запроса клиента должен иметь префикс с одним из значений
поля uris .

Например, в API, настроенном так:

  {
    "name": "my-api",
    "upstream_url": "http: // my-api.com ",
    "uris": ["/ service", "/ hello / world"]
}
  

Следующие запросы будут соответствовать настроенному API:

  GET / сервис HTTP / 1.1
Хост: my-api.com
  

  GET / service / resource? Param = значение HTTP / 1.1
Хост: my-api.com
  

  GET / привет / мир / ресурс HTTP / 1.1
Хост: something.com
  

Для каждого из этих запросов Kong обнаруживает, что их URI имеет префикс одного из
значения uris API.По умолчанию Kong пересылает запрос
восходящий поток с нетронутым и тем же URI .

При проксировании с префиксами URI самые длинные URI оцениваются первыми .
Это позволяет вам определять два API с двумя URI: / service и
/ service / resource и убедитесь, что первый не «затеняет» второй.

Вернуться к TOC

strip_uri свойство

Может быть желательно указать префикс URI для соответствия API, но не
включить его в восходящий запрос.Для этого используйте логическое значение strip_uri
свойство, настроив API следующим образом:

  {
    "name": "my-api",
    "upstream_url": "http://my-api.com",
    "uris": ["/ service"],
    "strip_uri": правда
}
  

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

  GET / служба / путь / к / ресурсу HTTP / 1.1
Хост:
  

приведет к тому, что Kong отправит следующий запрос в вышестоящую службу:

  GET / путь / к / ресурсу HTTP / 1.1
Хост: my-api.com
  

Вернуться к TOC

Запросить метод HTTP

Начиная с Kong 0.10, запросы клиентов также могут маршрутизироваться в зависимости от их
HTTP-метод, указав методы поле. По умолчанию Kong будет маршрутизировать
запрос к API независимо от его HTTP-метода. Но когда это поле установлено,
будут сопоставлены только запросы с указанными HTTP-методами.

Это поле также может принимать несколько значений. Вот пример API, позволяющего
маршрутизация через методы GET и HEAD HTTP:

  {
    "name": "api-1",
    "upstream_url": "http://my-api.com",
    "методы": ["ПОЛУЧИТЬ", "ГОЛОВУ"]
}
  

Такой API будет соответствовать следующим запросам:

  HEAD / ресурс HTTP / 1.1
Хост:
  

Но не соответствует запросу POST или DELETE .Это позволяет гораздо больше
детальность при настройке API и плагинов. Например, можно было представить
два API, указывающих на одну и ту же восходящую службу: один API, позволяющий неограниченное количество
неаутентифицированные запросы GET и второй API, разрешающий только аутентифицированные
и запросы POST с ограничением скорости (путем применения аутентификации и скорости
ограничение плагинов на такие запросы).

Вернуться к TOC

Приоритеты маршрутизации

API может определять правила сопоставления на основе своих хостов , uris и методов
поля.Чтобы Kong сопоставил входящий запрос с API, все существующие поля
должен быть доволен. Однако Kong допускает некоторую гибкость, позволяя
два или более API, которые должны быть настроены с полями, содержащими одинаковые значения — когда
это происходит, Конг применяет правило приоритета.

Правило таково: при оценке запроса Kong сначала попытается
чтобы соответствовать API с наибольшим количеством правил .

Например, два API настроены следующим образом:

  {
    "name": "api-1",
    "upstream_url": "http: // my-api.com ",
    "hosts": ["example.com"]
},
{
    "имя": "апи-2",
    "upstream_url": "http://my-api-2.com",
    "hosts": ["example.com"],
    "методы": ["POST"]
}
  

api-2 имеет поле hosts и поле методов , поэтому он будет
сначала оценил Конг. Таким образом мы избегаем «затенения» вызовов api-1.
предназначен для api-2.

Таким образом, этот запрос будет соответствовать api-1:

  GET / HTTP / 1.1
Хост: example.com
  

И этот запрос будет соответствовать api-2:

  POST / HTTP / 1.1
Хост: example.com
  

Следуя этой логике, если третий API должен был быть настроен с полем hosts ,
поле method и поле uris , оно будет сначала оценено Kong.

Вернуться к TOC

Поведение при проксировании

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

Вернуться к TOC

1. Балансировка нагрузки

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

До версии Kong 0.10, обычно, Kong отправлял прокси-запросы на
upstream_url и требуется балансировка нагрузки между несколькими экземплярами восходящего потока
внешний балансировщик нагрузки.

Дополнительную информацию о добавлении балансировки нагрузки в API можно найти по
обратитесь к Справочнику по балансировке нагрузки.

Вернуться к TOC

2. Исполнение плагинов

Kong расширяется с помощью «плагинов», которые подключаются к
жизненный цикл запроса / ответа прокси-запросов. Плагины могут выполнять
различные операции в вашей среде и / или преобразования на прокси
запрос.

Плагины

можно настроить для работы глобально (для всего проксируемого трафика) или на
на основе API путем создания конфигурации плагина
через Admin API.

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

Вернуться к TOC

3. Таймауты проксирования и восходящего потока

После того, как Kong выполнил всю необходимую логику (включая плагины), он готов
для пересылки запроса в вышестоящую службу. Это делается через Nginx
ngx_http_proxy_module. Начиная с Kong 0,10 таймаут
продолжительность соединений между Kong и вашими вышестоящими сервисами может быть
настраивается с помощью этих трех свойств объекта API:

• upstream_connect_timeout : определяет в миллисекундах тайм-аут для
  установление соединения с вашей восходящей службой.По умолчанию 60000 .
• upstream_send_timeout : определяет в миллисекундах тайм-аут между двумя
  последовательные операции записи для передачи запроса вашему апстриму
  служба. По умолчанию 60000 .
• upstream_read_timeout : определяет в миллисекундах тайм-аут между двумя
  последовательные операции чтения для получения запроса от вашего апстрима
  служба. По умолчанию 60000 .

Kong отправит запрос по HTTP / 1.1 и установите следующие заголовки:

• Хост: , как описано ранее в этом документе.
• Соединение: keep-alive , чтобы разрешить повторное использование восходящих соединений
• X-Real-IP: <$ proxy_add_x_forwarded_for> , где $ proxy_add_x_forwarded_for
  переменная с тем же именем, предоставленная
  ngx_http_proxy_module.
• X-Forwarded-Proto: <протокол> , где <протокол> — протокол, используемый
  клиент.

Все остальные заголовки запросов пересылаются Kong как есть.

Одно исключение сделано при использовании протокола WebSocket. Если так, Конг
установит следующие заголовки, чтобы разрешить обновление протокола между
клиент и ваши разведывательные услуги:

• Подключение: Обновление
• Обновление: websocket

Дополнительная информация по этой теме представлена ​​в
[Proxy WebSocket traffic] раздел [proxy-websocket].

Вернуться к TOC

4. Ошибки и повторные попытки

При возникновении ошибки во время проксирования Kong будет использовать базовый
Механизм повторных попыток Nginx передать запрос на
следующий апстрим.

Здесь есть два настраиваемых элемента:

1. Количество повторных попыток: это можно настроить для каждого API с помощью повторений
   свойство объекта API . Подробнее см. В API управления
   подробности об этом.

2. Что именно представляет собой ошибку: здесь Kong использует значения по умолчанию Nginx, которые
   означает ошибку или тайм-аут при установке соединения с
   server, передавая ему запрос или читая заголовок ответа.

Второй вариант основан на Nginx
директива proxy_next_upstream. Этот вариант не
настраивается напрямую через Kong, но может быть добавлен с помощью пользовательского Nginx
конфигурация. См. Справку по конфигурации для
подробнее.

Вернуться к TOC

5. Ответ

Kong получает ответ от вышестоящей службы и отправляет его обратно в
нижестоящий клиент в потоковом режиме. В этот момент Конг выполнит
последующие плагины, добавленные к этому конкретному API, которые реализуют ловушку в
header_filter фаза.

После выполнения фазы header_filter всех зарегистрированных подключаемых модулей
следующие заголовки будут добавлены Kong, и полный набор заголовков будет отправлен на
клиент:

• Через: kong / x.x.x , где x.x.x — используемая версия Kong.
• X-Kong-Proxy-Latency: , где latency — время в миллисекундах.
  между Kong получением запроса от клиента и отправкой запроса на
  ваш восходящий сервис.
• X-Kong-Upstream-Latency: , где latency — время в
  миллисекунды, которые Kong ждал первый байт восходящей службы
  ответ.

Как только заголовки будут отправлены клиенту, Kong начнет выполнение
зарегистрированные плагины для этого API, реализующие хук body_filter . Эта
hook может быть вызван несколько раз из-за потоковой природы самого Nginx.
Каждый фрагмент восходящего ответа, который успешно обрабатывается таким
body_filter хуков отправляется обратно клиенту.Вы можете найти дополнительную информацию
о хуке body_filter в разработке плагина
руководство.

Вернуться к TOC

Настройка резервного API

В качестве практического варианта использования и примера гибкости, предлагаемой Kong’s
возможности проксирования, давайте попробуем реализовать «резервный API», чтобы в
Чтобы Конг не ответил HTTP 404 , «API не найден», мы можем
перехватывать такие запросы и передавать их в специальный вышестоящий сервис, или
применить к нему плагин (такой плагин может, например, завершить запрос
с другим кодом состояния или ответом без проксирования запроса).

Вот пример такого резервного API:

  {
    "name": "root-fallback",
    "upstream_url": "http://dummy.com",
    "uris": ["/"]
}
  

Как вы можете догадаться, любой HTTP-запрос, сделанный в Kong, действительно будет соответствовать этому API,
поскольку все URI имеют префикс корневого символа /. Как мы знаем из
[Request URI] [proxy-request-uri] раздел, самые длинные URI оцениваются первыми
от Конга, поэтому URI / в конечном итоге будет оцениваться Конгом последним, и
эффективно предоставить «запасной» API, подобранный только в крайнем случае.

Вернуться к TOC

Настройка SSL для API

Kong предоставляет способ динамического обслуживания SSL-сертификатов для каждого соединения
основание. Начиная с версии 0.10, плагин SSL был удален и сертификаты SSL
напрямую обрабатываются ядром и настраиваются через Admin API. Твой
клиентская HTTP-библиотека должна поддерживать расширение Server Name Indication для
воспользуйтесь этой функцией.

Сертификаты SSL

обрабатываются двумя ресурсами Kong Admin API:

• / сертификаты , в которых хранятся ваши ключи и сертификаты.
• / snis , который связывает зарегистрированный сертификат с именем сервера
  Индикация.

Вы можете найти документацию по этим двум ресурсам в
Справочник по API администратора.

Вот как настроить сертификат SSL для данного API: сначала загрузите свой
SSL-сертификат и ключ через Admin API:

  $ curl -i -X ​​POST http: // localhost: 8001 / сертификаты \
    -F "cert=@/path/to/cert.pem" \
    -F "key=@/path/to/cert.key" \
    -F "snis = ssl-example.com, other-ssl-example.com "
HTTP / 1.1 201 Создано
...
  

Параметр формы snis — это сахарный параметр, напрямую вставляющий SNI и
Связывание с ним загруженного сертификата.

Теперь вы должны зарегистрировать следующий API в Kong. Мы направим запросы на
этот API с использованием заголовка Host для удобства:

  $ curl -i -X ​​POST http: // localhost: 8001 / apis \
    -d "имя = ssl-api" \
    -d "upstream_url = http: //my-api.com" \
    -d "hosts = ssl-example.com, other-ssl-example.com "
HTTP / 1.1 201 Создано
...
  

Теперь вы можете ожидать, что API будет обслуживаться через HTTP с помощью Kong:

  $ curl -i https: // локальный: 8443 / \
  -H "Хост: ssl-example.com"
HTTP / 1.1 200 ОК
...
  

Вернуться к TOC

https_only свойство

Если вы хотите, чтобы API обслуживался только через HTTPS, вы можете сделать это, включив
его https_only свойство:

  $ curl -i -X ​​POST http: // localhost: 8001 / apis \
    -d "name = ssl-only-api" \
    -d "upstream_url = http: // example.com "\
    -d "hosts = my-api.com" \
    -d "https_only = true"
HTTP / 1.1 201 Создано
...
  

При такой настройке вашего API Kong откажется от прокси-трафика для него.
без HTTPS. Запрос Kong по простому HTTP, нацеленный на этот API,
проинструктируйте своих клиентов перейти на HTTPS:

  $ curl -i http: // локальный: 8000 \
    -H "Хост: my-api.com"
HTTP / 1.1 426
Тип содержимого: приложение / json; charset = utf-8
Передача-кодирование: фрагментированное
Подключение: Обновление
Обновление: TLS / 1.2, HTTP / 1.1
Сервер: kong / x.x.x

{"message": "Пожалуйста, используйте протокол HTTPS"}
  

Вернуться к TOC

Свойство http_if_terminated

Если вы хотите учитывать заголовок X-Forwarded-Proto ваших запросов, когда
для обеспечения трафика только HTTPS, включите свойство http_if_terminated вашего
Определение API.

Следуя предыдущему примеру, если мы обновим наш HTTPS-only API:

  $ curl -i -X ​​ПАТЧ http: // localhost: 8001 / apis / ssl-only-api \
    -d "http_if_terminated = истина"
HTTP / 1.1 200 ОК
...
  

И мы делаем запрос с заголовком X-Forwarded-Proto (при условии, что это
исходящий от доверенного клиента ):

  $ curl -i http: // локальный: 8000 \
    -H "Хост: my-api.com" \
    -H "X-Forwarded-Proto: https"
HTTP / 1.1 200 ОК
...
  

Kong теперь проксирует этот запрос, потому что он предполагает, что завершение SSL было
достигнутый предыдущим компонентом вашей архитектуры.

Вернуться к TOC

Прокси-трафик WebSocket

Kong поддерживает трафик WebSocket благодаря базовой реализации Nginx.Если вы хотите установить соединение WebSocket между клиентом и вашим
восходящие сервисы с по Kong, вы должны установить рукопожатие WebSocket.
Это делается с помощью механизма обновления HTTP. Это то, что просит ваш клиент
сделано для Конга будет выглядеть так:

  GET / HTTP / 1.1
Подключение: Обновление
Хост: my-websocket-api.com
Обновление: WebSocket
  

Это заставит Kong перенаправить заголовки Connection и Upgrade на ваш
восходящий сервис, вместо того, чтобы отклонять их из-за поэтапного характера
стандартный HTTP-прокси.

Вернуться к TOC

WebSocket и TLS

Kong будет принимать соединения ws и wss на своих соответствующих http и
https портов. Чтобы принудительно подключать TLS от клиентов, установите https_only
свойство API до true .

При настройке API для указания на ваш вышестоящий WebSocket
сервис, вам следует тщательно выбрать протокол, который вы хотите использовать между Kong
и восходящий поток. Если вы хотите использовать TLS ( wss ), тогда исходящий WebSocket
сервис должен быть определен с использованием протокола https в API upstream_url
свойство и правильный порт (обычно 443).Для подключения без TLS ( ws ),
модель

.