Як налаштувати Cloudflare, щоб він не блокував завантаження фіду та зображень?#

Чому Cloudflare блокує Mergado, хоча його IP-адресу дозволено#

Якщо ваш інтернет-магазин використовує Cloudflare, може статися, що Mergado (або якесь із його розширень, наприклад Feed Image Editor) не зможе завантажити ваш фід або зображення товарів, навіть якщо ви вже додали його IP-адресу до білого списку.

Причина в тому, що Cloudflare може оцінити автоматичне завантаження фіду не як звичайний доступ, а як підозрілий трафік, і заблокувати його або показати йому так звану перевірку безпеки (challenge). Тобто сторінку на зразок “Just a moment…”, яку вміє пройти лише браузер із JavaScript, а не автоматизоване завантаження. Це стосується передусім таких функцій Cloudflare:

Bot Fight Mode / Super Bot Fight Mode,
Managed Challenge (керована перевірка),
Browser Integrity Check,
Hotlink Protection,
Security Level,
WAF Managed Rules.

Просте додавання IP-адреси до старіших IP Access Rules (білий список) ці функції часто не вимикає. До того ж ми помічаємо, що Cloudflare на деяких облікових записах поступово прибирає цю можливість і замінює її гнучкішим інструментом WAF Custom Rules. Ця інструкція показує, як за його допомогою налаштувати надійний виняток для Mergado.

Які IP-адреси потрібно дозволити#

81.31.39.112 – IP-адреса, з якої Mergado завантажує ваш вхідний фід.
81.31.39.116 – IP-адреса, яку використовують деякі розширення, що завантажують зображення товарів (наприклад, Feed Image Editor, Bidding Fox, Pricing Fox, Fox Data+).

Якщо ви використовуєте й інші розширення Mergado, перевірте їхню IP-адресу в статті Які IP-адреси використовує Mergado та його розширення?

Крок за кроком: налаштування винятку в Cloudflare#

а. Створіть нове правило Custom Rule#

Увійдіть у керування своїм доменом у Cloudflare.
У лівому меню перейдіть до Security → WAF → Custom rules (або лише Security rules, залежно від версії інтерфейсу).
Натисніть Create rule.

б. Налаштуйте умову для Mergado#

У розділі “When incoming requests match…” налаштуйте умову так, щоб вона відповідала обом IP-адресам Mergado, наприклад:

(ip.src eq 81.31.39.112) or (ip.src eq 81.31.39.116)

Радимо не прив’язувати умову додатково до конкретного шляху (URI Path) чи методу HTTP. Що простіша умова, то менший ризик помилки, а оскільки йдеться лише про дві конкретні довірені IP-адреси, це жодним чином не знижує захист від решти трафіку.

Стережіться друкарських помилок. Легко може статися, що в текстове поле випадково потрапить зайвий пробіл (наприклад, " /feed.xml" замість "/feed.xml") або неправильна цифра в IP-адресі. Така умова потім ніколи нічого не знайде, правило ніколи не спрацює, а ви шукатимете проблему деінде. Завжди перевіряйте остаточний вигляд у полі Expression Preview під умовою.

в. Налаштуйте дію Skip і позначте всі компоненти #

У розділі „Then take action…“ виберіть дію Skip.
Позначте абсолютно всі варіанти під „WAF components to skip“:
- All remaining custom rules
- All rate limiting rules
- All managed rules
- All Super Bot Fight Mode Rules
Розгорніть також „More components to skip“ і позначте ще й ці:
- Zone Lockdown
- User Agent Blocking
- Browser Integrity Check
- Hotlink Protection
- Security Level
- Rate limiting rules (Previous version)
- Managed rules (Previous version)

Досить, щоб непозначеним залишився один-єдиний пункт, – і саме він може й далі блокувати завантаження.

г. Поставте правило на перше місце#

У розділі „Place at“ виберіть, щоб правило оцінювалося першим (або одразу після інших технічних правил, не пов’язаних із безпекою). Cloudflare оцінює власні правила в порядку згори донизу, і щойно якесь попереднє правило заблокує запит або покаже йому перевірку, до вашого правила білого списку справа може взагалі не дійти.

Якщо у вас у Cloudflare є й інші правила безпеки (наприклад, блокування трафіку з-поза певної країни, захист від ботів тощо), перевірте, що жодне з них не розміщено вище за правило для Mergado.

д. Збережіть правило#

Натисніть Save. Зміна зазвичай набирає чинності протягом кількох секунд або хвилин.

Що робити, коли проблема не зникає навіть після налаштування правила#

Перевірте, що правило справді спрацьовує#

У Cloudflare перейдіть до Security → Events (або Security → Analytics → Events).
Відфільтруйте події за джерельною IP-адресою (81.31.39.112 або 81.31.39.116).
У конкретній події подивіться на розділ „Matched service“. Там має бути зазначено Action taken: Skip і назву вашого правила.

Якщо натомість ви бачите іншу дію (наприклад, Managed Challenge або Block) та інше правило, це означає, що ваше правило білого списку взагалі не спрацювало, і потрібно перевірити умову (крок б) або порядок правил (крок г).

Перевірте також захист на боці хостингу#

Якщо ваш інтернет-магазин працює на керованому хостингу (наприклад, Kinsta, WP Engine і подібні сервіси), він може мати власний, незалежний від Cloudflare захист від ботів, який потрібно налаштувати окремо. Навіть після правильного налаштування Cloudflare може статися, що запит на завантаження фіду чи зображення й далі завершиться помилкою 403 Forbidden, цього разу вже від хостингу, а не від Cloudflare.

У такому разі знайдіть в адмініструванні хостингу розділ захисту від ботів (наприклад, „Bot protection“) і додайте обидві IP-адреси Mergado до списку винятків (часто він називається „Always allow“ або подібно). Для деяких розширень (наприклад, Feed Image Editor) до винятків можна додати й User Agent, яким розширення себе ідентифікує: feedimageeditor/2.0.

Як зрозуміти, що блокує – Cloudflare чи хостинг#

Допоможе технічний тест відповіді сервера (наприклад, командою curl -I для конкретної URL-адреси зображення чи фіду). Вирішальним є заголовок cf-mitigated: challenge у відповіді:

Якщо він присутній, запит перехоплює Cloudflare (продовжуйте за кроками вище).
Якщо його немає, але запит однаково завершується помилкою 403, найімовірніше, ідеться про захист на боці хостингу, а не Cloudflare.

Заголовки на зразок server: cloudflare або cf-ray з’являються в кожній відповіді, яка проходить через Cloudflare, – незалежно від того, чи запит блокує Cloudflare, чи лише передає трафік далі на хостинг, тож самі по собі вони не визначають, хто запит заблокував.

Часті запитання#

Чому недостатньо додати IP-адресу Mergado до старішого білого списку (IP Access Rules)?#

IP Access Rules можуть пропустити запит усередину, але не обов’язково вимикають усі інші види захисту (Bot Fight Mode, Managed Challenge, Browser Integrity Check тощо), які однаково можуть заблокувати запит на завантаження фіду чи зображення. Тому надійніше створити правило Custom Rule з дією Skip, яке ці види захисту для відповідних IP-адрес явно вимкне.

Чи справді потрібно позначити всі компоненти в „WAF components to skip“? #

Так, радимо позначити їх усі. Правило стосується лише двох конкретних довірених IP-адрес Mergado, тож цим ви не знижуєте захист сайту від решти трафіку. Досить, щоб непозначеним залишився один-єдиний пункт, – і завантаження може й далі не вдаватися.

Я налаштував(-ла) все за інструкцією, а фід / зображення все одно не завантажуються. Що далі?#

Перевірте в Cloudflare в розділі Security → Events, яку дію та яке правило Cloudflare насправді застосував до запитів з IP 81.31.39.112 або 81.31.39.116. Якщо бачите іншу дію, ніж Skip, ще раз перегляньте умову правила (можлива друкарська помилка) і його місце серед інших правил. Якщо правило працює правильно, а ви все одно отримуєте помилку 403, може йтися про окремий захист на боці вашого хостингу.

Як дізнатися, що Mergado вже справді завантажує фід?#

У проєкті в Mergado перейдіть на сторінку History і в стовпці Event type відфільтруйте Download (або Product import). Так ви побачите записи про окремі спроби, зокрема час і кількість завантажених товарів.