← Правила Cloudflare / rules / reference

Устранение неполадок Rules

Взаимодействие редиректов с другими продуктами Cloudflare

Ваши редиректы могут конфликтовать с некоторыми продуктами и функциями Cloudflare, например с challenges. Рекомендуем исключить /cdn-cgi/* путь URI в выражении правила, чтобы избежать проблем. Либо можно исключить только подпуть, например /cdn-cgi/challenge-platform/* чтобы избежать проблем с определёнными функциями (в этом примере Cloudflare challenges).

Также рекомендуется исключить /.well-known/* путь URL, используемый несколькими сервисами проверки. См. Взаимодействие редиректов с процедурами проверки, такими как HTTP DCV, где это описано подробнее.

Взаимодействие проверок Cloudflare с функциями Rules

Если вы выполняете проверка для заданного пути URI, для которого включена одна или несколько функций Rules, следует исключить пути URI, начинающиеся с /cdn-cgi/challenge-platform/ в выражениях правил, чтобы избежать циклов challenge.

Например, определите составное выражение для правила с помощью and оператор и starts_with() функция:

<OTHER_RULE_CONDITIONS> and not starts_with(http.request.uri, "/cdn-cgi/challenge-platform/")

Взаимодействие редиректов с процедурами проверки, такими как HTTP DCV

Пути, используемые в процедурах проверки, например при проверке пользовательского имени хоста (Cloudflare for SaaS), Проверка домена Pages, или Проверка контроля домена по HTTP (DCV) может быть затронут перенаправлениями.

Рассмотрите возможность исключить /.well-known/* путь URI из вашего правила, чтобы избежать проблем.

Заголовок Content-Length удалён из ответа

Cloudflare может удалить Content-Length заголовок из ответов, отправляемых посетителям сайта. Если посетитель должен получить Content-Length заголовок, настройте сервер источника так, чтобы он включал cache-control: no-transform HTTP-заголовок в ответе.

Это правило может не применяться к вашему трафику

Если выражение вашего правила соответствует имени хоста, для которого вы не создали DNS-запись и не включили проксирование трафика через Cloudflare, появится всплывающее окно с несколькими вариантами:

Если для этого имени хоста не существует DNS-записи: Определяет, продолжить ли создание правила или создать новую проксируемую DNS запись для этого имени хоста.
Если для этого имени хоста есть DNS-запись, но трафик не проксируется: Определяет, продолжить ли создание правила или включить проксирование для существующей DNS записи.

Если вы решите создать новую DNS-запись, у неё будет rules тег и следующий связанный с ним комментарий:

Created during Cloudflare Rules deployment process for <RULE_NAME>

URL rewrites влияют на другие функции Rules, выполняемые позже

Если вы перепишете путь URI с помощью URL rewrite, это может повлиять на другие функции Rules, выполняемые позже, например Origin Rules если они включают путь URI в своё выражение фильтра.

Рассмотрите следующую конфигурацию правила источника:

Выражение правила: http.host == "example.com" and starts_with(http.request.uri.path, "/downloads/")
заголовок Host > Rewrite to: assets.example.com

Если вы настроите новый URL rewrite со следующей конфигурацией:

Выражение правила: http.host == "example.com" and starts_with(http.request.uri.path, "/downloads/")
Путь > Rewrite to > Динамический: regex_replace(http.request.uri.path, "^/downloads/", "/")

Правило Origin Rules больше не будет соответствовать /downloads/* путей, так как перезапись URL выполняется до Origin Rules, и путь URI будет изменён с "/downloads/" к "/".

Решение

Чтобы избежать этой ситуации, используйте raw-поля в выражении правила. Raw-поля остаются неизменными на протяжении всего процесса обработки запроса и не зависят от действий ранее сработавших правил.

В текущем примере можно использовать raw.http.request.uri.path поле в обоих правилах:

URL rewrite

Выражение правила: http.host == "example.com" and starts_with(raw.http.request.uri.path, "/downloads/")
Путь > Rewrite to > Динамический: regex_replace(raw.http.request.uri.path, "^/downloads/", "/")

Origin rule

Выражение правила: http.host == "example.com" and starts_with(raw.http.request.uri.path, "/downloads/")
заголовок Host > Rewrite to: assets.example.com

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

Список необработанных полей см. в Справочник полей.