Как остановить NodeJS «Запрос» модуля изменения запроса при использовании прокси

Question

Извините, если это сбивает с толку.

Я написал скрипт, используя модуль запросов NodeJS, который запускает и выполняет функцию на веб-сайте, а затем возвращает данные.Этот скрипт прекрасно работает, когда я не использую прокси, установив для него значение false.Это не та задача, которую нельзя выполнять с помощью Selenium / puppeteer

proxy: false

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

proxy: http://xx.xxx.xx.xx:3128

Несколько замечаний:

• Я пробовал много (20+) различных прокси-провайдеров (Residential и Datacenter) и у всех есть эта проблема
• Проблема не возникает, если в моей системе установлен глобальный прокси
• Проблема не возникает, если этот прокси установлен в расширении Chrome
• Наборы шифров SSL не соответствуют Chrome, но они все равно не совпадают, если не используется прокси, поэтому я предполагаю, что это не проблема
• Очень важно поддерживать согласованность в порядке заголовка

Вопрос в основном такой.Изменяет ли модуль запроса что-либо при использовании прокси, например порядок заголовков?

Вот изображение того, что происходит, когда он проходит / терпит неудачу.

Единственная разница - это изменение прокси, которое приводит к сбою.Один запрос сделан с, один запрос сделан без.

url    : url,
simple : false,
forever: true,
resolveWithFullResponse: true,
gzip: true,
headers: {
    'Host'             : 'www.sitename.com',
    'Connection'       : 'keep-alive',
    'Upgrade-Insecure-Requests': '1',
    'User-Agent'       : 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36',
    'Accept'           : 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8',
    'Accept-encoding'  : 'gzip, deflate, br',
    'Accept-Language'  : 'en-GB,en-US;q=0.9,en;q=0.8',
},
method : 'GET',
jar: globalJar,
simple: false,
followRedirect: false,
followAllRedirects: false, 

Answer 1

Согласно документации прокси модуля запроса:

По умолчанию при прокси-трафике http запрос просто выполняет стандартный прокси-запрос http. Это можно сделать, сделав раздел URL начальной строки запроса полностью определенным адресом конечной точки.

Вместо этого вы можете использовать http туннель , установив:

tunnel : true

в настройках прокси модуля запроса.

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

Из документации:

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

Answer 2

Вы используете http -схему для вашего запроса, но если веб-сервер перенаправляет http на https и если прокси-сервер не настроен на прием перенаправлений (на https), то проблемаможет касаться только схемы, соответственно URL, который вы вводите.

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

Здесь вы можете прочитать о перенаправлениях на одном прокси-сервере (Apache Traffic Server), сценарий включает в себя больше перенаправлений, чем я описал выше:
https://docs.trafficserver.apache.org/en/4.2.x/admin/reverse-proxy-http-redirects.en.html#handling-origin-server-redirect-responses

Если вы по-прежнемустолкнуться с проблемами, серверные журналы прокси-сервера были бы полезны.

РЕДАКТИРОВАТЬ:
В соответствии с его страница @Jannes Botis связаны там существуют еще большенастройки прокси, которые могут поддерживать или нарушать желаемую функциональность, поэтому, возможно, вся проблема заключается в правильной настройке прокси-сервера.Вот несколько настроек, которые напрямую связаны с перенаправлениями:

followRedirect - follow HTTP 3xx responses as redirects (default: true). This property can also be implemented as function which gets response object as a single argument and should return true if redirects should continue or false otherwise.
followAllRedirects - follow non-GET HTTP 3xx responses as redirects (default: false)
followOriginalHttpMethod - by default we redirect to HTTP method GET. you can enable this property to redirect to the original HTTP method (default: false)
maxRedirects - the maximum number of redirects to follow (default: 10)
removeRefererHeader - removes the referer header when a redirect happens (default: false). Note: if true, referer header set in the initial request is preserved during redirect chain.

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

Answer 3

Есть несколько сценариев, о которых я могу подумать

• Прокси фактически добавляет некоторые заголовки к окончательному запросу (чтобы идентифицировать вас на сервере)
• Веб-сайт, с которым вы работаетеВы пытаетесь достичь, есть ли ваши прокси IP-адреса в черном списке (общедоступные / платные?)

Это действительно зависит от того, зачем вам нужен этот прокси

• Это из-засетевые ограничения?
• Это потому, что вы хотите скрыть исходный адрес запроса?

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

Мое предложение

Попробуйте написать собственный прокси (обратный) и разместить его где-нибудь.Вместо запроса https://target.com, на запрос к вашему http [s]: //proxy.com/ и пусть обратный прокси сделает всю работу.Кроме того, не забудьте отключить заголовки X в реализации, поскольку это изменит заголовки запроса

Ссылка для реализации node.js:

https://github.com/nodejitsu/node-http-proxy

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