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

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

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

proxy: false

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

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

Некоторые вещи, на которые стоит обратить внимание:

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

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

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

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

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,

Ответы

Ответ 1

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

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

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

tunnel : true

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

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

Ответ 3

Вы используете http -scheme для своего запроса, но если веб-сервер перенаправляет 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.

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