> For the complete documentation index, see [llms.txt](https://docs.iexexchanger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.iexexchanger.com/help-center/ai-docs/komanda-dostup-i-bezopasnost/security-settings/cloudflare.md).

# Подключение Cloudflare

Cloudflare можно поставить перед клиентским сайтом и панелью управления как обратный прокси. Правильная настройка скрывает прямой адрес веб-сервера, фильтрует нежелательный трафик и при этом сохраняет реальный IP посетителя в iEXExchanger.

Для изменения доверенных прокси требуется критичное право «Настройки безопасности». DNS, сертификат и сетевые ограничения должен менять технический специалист, у которого есть доступ к Cloudflare, хостингу и аварийному каналу входа на сервер.

{% hint style="warning" %}
Не закрывайте прямой доступ к серверу, пока не проверены DNS, HTTPS, панель управления, callback, чат и реальный IP. Ошибка в списке разрешённых адресов может сделать клиентский сайт и панель недоступными.
{% endhint %}

## Что подготовить

До переключения трафика зафиксируйте:

* адрес сервера, на который сейчас указывают веб-домены;
* домен клиентского сайта, например `https://ваш_домен`;
* технический домен панели управления, например `https://app.ваш_домен`;
* действующий сертификат на сервере для обоих доменов;
* все callback-домены и внешние сервисы, которые обращаются к обменному пункту;
* резервный способ вернуть прежние DNS-записи и открыть сервер вне Cloudflare.

Сделайте резервную копию текущих DNS-записей. Не переносите автоматически устаревшие записи и не публикуйте адрес сервера в TXT-записях, комментариях или документации.

## DNS и проксирование

В Cloudflare создайте или проверьте веб-записи для `ваш_домен` и `app.ваш_домен`. Записи A, AAAA или CNAME, которые обслуживают HTTP и HTTPS, переведите в состояние Proxied только после проверки правильного адреса сервера. В этом режиме веб-трафик проходит через сеть Cloudflare; состояние DNS only раскрывает фактический адрес назначения и не применяет HTTP-защиту Cloudflare. Подробности приведены в [официальном описании Proxy status](https://developers.cloudflare.com/dns/proxy-status/).

Записи электронной почты, подтверждения владения доменом и других не-веб-сервисов оставляйте в требуемом для их поставщика режиме. Не включайте проксирование для записи только потому, что она находится в той же DNS-зоне.

После изменения проверьте оба домена через независимый DNS-резолвер. Проксируемый веб-домен должен возвращать адреса Cloudflare, а не адрес сервера.

## HTTPS между Cloudflare и сервером

На сервере должен быть установлен действующий сертификат, который покрывает каждый проксируемый домен. Затем в Cloudflare откройте SSL/TLS и выберите Full (strict). В этом режиме Cloudflare проверяет срок, доверенную цепочку и соответствие имени сертификата; требования перечислены в [официальной инструкции Full (strict)](https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/).

Не используйте Flexible для рабочего обменного пункта: соединение от Cloudflare до сервера в таком режиме не даёт требуемой сквозной защиты. Не включайте HSTS до успешной проверки всех доменов и поддоменов, потому что ошибочное правило будет сохраняться в браузерах.

## Кеш и динамические страницы

Статические изображения, стили и скрипты можно отдавать через кеш Cloudflare. Панель управления, авторизация, карточки заявок, расчёт обмена, callback, персональные страницы и ответы с пользовательской сессией не должны принудительно кешироваться.

Если в Cloudflare ранее создавались Cache Rules или правило Cache Everything:

1. Добавьте правило Bypass cache для `app.ваш_домен`.
2. Добавьте исключения для подтверждённых техническим специалистом динамических адресов клиентского сайта.
3. Не придумывайте маски API и callback: возьмите фактические адреса из настроек подключённых сервисов.
4. Проверьте порядок правил, чтобы более широкое правило кеширования не отменяло исключение.
5. Для остальных ответов сохраняйте директивы кеширования, которые отдаёт сервер.

Cloudflare позволяет исключить совпавшие запросы через Bypass cache; поля и поведение правил описаны в [официальном справочнике Cache Rules](https://developers.cloudflare.com/cache/how-to/cache-rules/settings/).

## WebSocket и чат

Для чата и обновлений в реальном времени откройте Network в Cloudflare и убедитесь, что WebSockets включён. Cloudflare поддерживает проксируемые WebSocket-соединения, но первоначальный запрос может быть заблокирован правилами WAF или ограничения частоты. См. [официальную инструкцию WebSockets](https://developers.cloudflare.com/network/websockets/).

После переключения отправьте сообщение клиента и ответ оператора без обновления страницы. Если сообщения появляются только после ручного обновления, проверьте событие блокировки в Cloudflare, адрес WebSocket, сертификат и доступность канала на сервере.

## Доверенные прокси в панели управления

Откройте:

**«Настройки» — «Общие настройки» — «Основные» — «Безопасность» — «Общее»**

Найдите поле «Выберите установленную защиту от DDOS» и выполните настройку:

1. Нажмите «Управление».
2. Выберите «Новый файл».
3. В поле «Название файла» задайте короткое системное имя, например `cloudflare`.
4. В поле «IP-адреса и CIDR-подсети» внесите полный актуальный список IPv4 и IPv6 Cloudflare.
5. Нажмите «Сохранить файл».
6. Закройте окно управления и выберите созданный файл в поле защиты от DDOS.
7. Сохраните настройки страницы.
8. Нажмите «Обновить IP-адреса», чтобы применить сохранённый список.

Не копируйте диапазоны из старой инструкции. Используйте [актуальный официальный список Cloudflare](https://www.cloudflare.com/ips/) и пересматривайте его при уведомлении поставщика об изменении адресов.

Система должна доверять заголовку с IP посетителя только тогда, когда запрос пришёл от выбранной подсети прокси. Cloudflare передаёт исходный адрес посетителя в `CF-Connecting-IP`; назначение заголовка описано в [официальном справочнике HTTP headers](https://developers.cloudflare.com/fundamentals/reference/http-headers/).

Режим совместимости с доверием к любому прокси не является обычной настройкой Cloudflare. Его можно временно использовать только при полностью закрытом прямом доступе к серверу и документированной цепочке прокси.

## Ограничение прямого доступа к серверу

После полной проверки разрешите веб-трафик к серверу от актуальных сетей Cloudflare и от подтверждённых партнёров, которым нужен прямой доступ. Затем можно закрыть остальные прямые обращения к веб-портам. Cloudflare рекомендует разрешать свои диапазоны на origin-сервере и блокировать обход прокси; см. [официальное руководство по IP-адресам Cloudflare](https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/).

Перед блокировкой учтите callback платёжных сервисов, мониторинг, резервный канал поддержки, балансировщик и другие доверенные узлы. Изменение сетевого экрана выполняйте по отдельному плану возврата. Не используйте настройку ограничения панели по IP как замену сетевому экрану сервера.

## Сквозная проверка

1. Откройте `https://ваш_домен` в приватном окне и создайте тестовый расчёт.
2. Войдите через `https://app.ваш_домен` и проверьте второй фактор, если он включён.
3. Сверьте IP новой авторизации с фактическим внешним IP устройства. В журнале не должен отображаться адрес Cloudflare.
4. Создайте безопасную тестовую заявку и проверьте переходы между её страницами.
5. Выполните тест callback штатным средством провайдера без реального платежа.
6. Проверьте клиентский чат и ответ оператора без обновления страницы.
7. Проверьте загрузку разрешённого тестового файла.
8. Выйдите из панели и убедитесь, что приватная страница не открывается из кеша.
9. Повторите проверку из другой сети, например через мобильный интернет.
10. Только после этого ограничивайте прямой доступ к серверу.

## Диагностика

| Признак                                    | Вероятная область                            | Что проверить                                                      |
| ------------------------------------------ | -------------------------------------------- | ------------------------------------------------------------------ |
| Ошибка 521                                 | Сервер отклоняет соединение                  | Работу веб-сервера, порт HTTPS и разрешение сетей Cloudflare       |
| Ошибка 522                                 | Cloudflare не дождался соединения            | Адрес origin-сервера, его нагрузку, маршрут и сетевой экран        |
| Ошибка 525                                 | Не завершилось TLS-согласование              | Сертификат, порт HTTPS, SNI, поддерживаемые шифры и журнал сервера |
| Ошибка 526                                 | Сертификат origin-сервера не прошёл проверку | Срок, имя домена, доверенную цепочку и режим Full (strict)         |
| В журнале один IP для разных клиентов      | Не применён доверенный прокси                | Выбранный файл, полноту диапазонов и действие «Обновить IP-адреса» |
| Панель или заявка показывает старые данные | Кешируется динамический ответ                | Cache Rules, порядок правил, cookies и заголовок `CF-Cache-Status` |
| Чат работает только после обновления       | Нет соединения реального времени             | WebSockets, WAF, сертификат, origin-сервер и адрес канала          |

Назначение ошибок Cloudflare 521, 522, 525 и 526 приведено в [официальном справочнике ошибок 5xx](https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/). При обращении к хостингу сохраните код ошибки, время с часовым поясом, проблемный URL и Ray ID со страницы Cloudflare.

## Безопасный возврат

Если после включения Cloudflare недоступны денежные или клиентские операции, остановите изменения и вернитесь к последнему проверенному состоянию:

1. Отмените последнее правило WAF или кеша, если сбой начался сразу после него.
2. Верните прежний DNS-режим только для затронутой записи.
3. Восстановите прежний файл доверенных прокси или очистите выбор, если трафик снова идёт напрямую.
4. Верните прежние правила сетевого экрана по подготовленному плану.
5. Повторите сквозную проверку и зафиксируйте причину инцидента.

Не ослабляйте TLS, не доверяйте всем прокси и не отключайте защиту панели как постоянный способ устранить ошибку.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.iexexchanger.com/help-center/ai-docs/komanda-dostup-i-bezopasnost/security-settings/cloudflare.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.