Блог

Главная - Вопросы по программированию - Работники CloudFlare получают HTTPS работает на поддомене workers.dev, но не на собственном поддомене, получив ошибку 525

Работники CloudFlare получают HTTPS работает на поддомене workers.dev, но не на собственном поддомене, получив ошибку 525

#ssl #fetch #cloudflare #cloudflare-workers

Вопрос:

У меня есть простой работник, который просто выполняет выборку для конечной точки HTTPS где-то в другом месте.

Код буквально просто:

 return await fetch('https://something.com/someResource')

Когда я тестирую локально ( wrangler dev ) и даже публикую в поддомене workers, это работает нормально. Когда я завиваюсь https://foo.bar.workers.dev/myEndpoint , я получаю тот же ответ, https://something.com/someResource что и .

Однако я хочу запустить это из своего собственного домена (управляемого через cloudflare), чтобы у работника также был маршрут foo.mydomain.com/* и AAAA запись 100:: foo в соответствии с документами CloudFlare. DNS работает нормально, URL-адрес доступен, но когда я пытаюсь попасть https://foo.mydomain.com/myEndpoint в рабочие журналы CloudFlare, они показывают, что извлечение за кулисами завершается ошибкой 525 (сбой SSL-подтверждения).

Вещи, которые я пробовал, основываясь на некоторых сообщениях на форуме CloudFlare:

  • Добавьте правило страницы foo.mydomain.com/* ->> SSL Mode: full , так как мои общие настройки SSL установлены на flexible .
  • Установите заголовок хоста в выборке в исходный домен ( fetch(url, {headers: {'Host': 'something.com'}})

К вашему сведению, я не контролирую исходный сервер, так как это внешний API, с которым я работаю.

Как получилось, что один и тот же запрос работает из локального, *.workers.dev но не из моего собственного домена?

Комментарии:

1. Можете ли вы попробовать установить режим SSL на «полный» по умолчанию и использовать правила страницы, чтобы вернуть его на «гибкий» там, где вам это действительно нужно?

2. Пока это, кажется, работает, типы контента перепутались, но это нормально, я могу это исправить. Итак, я предполагаю, что работники CF игнорируют правила страницы? круто. Спасибо @KentonVarda ! Можете ли вы сделать это ответом, чтобы я мог дать им сладкие сладкие очки?

Ответ №1:

Правило вашей страницы не вступает в силу. Правило страницы предназначено для foo.mydomain.com/* , но оно должно соответствовать URL-адресу подзапроса, который в данном случае https://something.com/someResource не соответствует. Не имеет значения, соответствует ли исходный рабочий запрос-в данном случае важно, соответствует ли URL-адрес подзапроса.

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

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

(Примечание: Ошибка «Сбой SSL-квитирования» сама по себе на самом деле является известной ошибкой у рабочих, которая возникает, когда вы пытаетесь связаться с хостом за пределами вашей зоны с помощью HTTPS, но у вас установлен SSL «flexbile». Мы не используем гибкий SSL при общении с доменами, отличными от вашего собственного, но есть ошибка, из-за которой запрос завершается ошибкой вместо того, чтобы просто использовать полный SSL, как это должно быть.)

Метки: , ,