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

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

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

Вместо этого вы можете использовать https://en.wikipedia.org/wiki/HTTP_tunnel, установив:

tunnel : true

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

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

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

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

После деактивации моей старой учетной записи я хотел вернуться и дать фактический ответ на этот вопрос, теперь я полностью понимаю ответ. То, о чем я спрашивал год назад, было невозможно. Антибот снимал отпечатки пальцев через TLS ClientHello (и даже немного на уровне TCP/фрейма).

Для начала я написал свою оболочку под названием request-curl, которая обернула двоичные файлы libcurl/curl в единую библиотеку с тем же форматом, что и request-promise, это дало мне гораздо больший контроль над запросом (предотвращение кодирования, поддержка http2/proxy и дальнейший контроль сеанса/TLS). ) это все еще позволило мне достичь 687-го рейтинга самых популярных ClientHello (https://client.tlsfingerprint.io:8443/). Это было недостаточно хорошо.

Пришлось пошевелить языком. NodeJS — это слишком высокоуровневый язык, чтобы обеспечить действительно глубокий контроль (приходилось изменять пакеты, отправляемые с уровня 3). Итак, как ответ на мой вопрос.

Это пока невозможно сделать в NodeJS, не говоря уже о сейчас неподдерживаемой библиотеке request.js.

Для тех, кто читает это, если вы хотите подделывать идеальные запросы для обхода защиты от ботов, вы должны перейти на другой язык: я рекомендую utls в Golang или BouncyCastle в C#. Удачи вам, поскольку мне потребовался год, чтобы на самом деле узнать, как это сделать. Даже тогда у этих языков есть больше внутренних проблем и функций, которые они еще не предполагают (Go не поддерживает «базовый» порядок заголовков, вам нужно исправлять/модифицировать внутренние компоненты и т. д., utls не легко поддерживает прокси). У этого списка нет конца.

Если вы еще не слишком углубились в это, это чертовски кроличья нора, и я рекомендую вам не входить в нее.

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

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

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

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

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

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

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

Ссылка на реализацию node.js:

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

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

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

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

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

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

EDIT:
Согласно его странице @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.

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