Тепер безпечніше ставити Cloudflare перед Shopify: що виправив O2O і що досі означають попередження.

Швидкий старт: зробіть це у своєму магазині

Якщо ви прийшли по кроки, ось вони. Уся конфігурація це проксований CNAME у Cloudflare, той самий домен, підключений у Shopify, і один перемикач HTTPS, якого не варто чіпати. Решта статті пояснює, чому кожен крок важливий і як переконатися, що він утримався, але це і є вся конфігурація.

Краще подивитися: Field Notes: Cloudflare in front of Shopify охоплює те саме за три хвилини, з повною транскрипцією на сторінці.

Крок 1 у панелі Cloudflare: обидва записи це CNAME на shops.myshopify.com зі статусом проксі Proxied.

Значення clawmart.digital, що наводяться в цій статті, взяті з живого тестового магазину, який ми ведемо на повністю робочому екземплярі Shopify, а не з макета. Кожен скриншот, запис і тест нижче походять із того магазину.

Попередження на працюючому магазині

Ваш домен Shopify показано як підключений, чекаут працює, замочок SSL на місці. Прямо під цим зеленим статусом сидить бурштинове попередження, що на вашому домені є проксі Cloudflare, яке Shopify не підтримує. Обидва твердження істинні одночасно, і саме на цій суперечності застрягає більшість продавців.

Це одне з найзаплутаніших повідомлень в інфраструктурі ecommerce, бо воно і не хибне, і не зовсім точне. Роками ставити Cloudflare перед Shopify було справді поганою ідеєю, яка ламала магазини конкретним, передбачуваним чином. Потім Cloudflare випустив функцію маршрутизації, яка виправила рівно те, що ламалося, а Shopify досі каже вам цього не робити. У цьому розриві, між виправленням, що працює, і вендором, який його не схвалює, і живе тривога «чи не зламається зараз мій магазин».

Тож ось практична версія: що саме ламалося, що виправив O2O, єдине налаштування, яке досі покладе ваш сайт, якщо ви його пропустите, і як вирішити, чи потрібне щось із цього вашому магазину.

Чому раніше це ламалося: дві помаранчеві хмари

Cloudflare показує проксований домен як помаранчеву хмару. Трафік до цього домену проходить через мережу Cloudflare, перш ніж дійти до вашого origin. Заковика з Shopify в тому, що Shopify сам працює на Cloudflare. Тож коли ви спрямовуєте свій домен з помаранчевою хмарою на Shopify, запит приходить до Cloudflare з двома зонами, які обидві на нього претендують: вашою і зоною Shopify. Дві помаранчеві хмари, одна на одній.

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

Найгострішим краєм був SSL. Shopify видає й оновлює ваш сертифікат через Let's Encrypt, а Let's Encrypt доводить, що домен належить вам, за допомогою перевірки ACME, яка обслуговується за конкретним шляхом:

Якщо проксі перед Shopify перехоплює, кешує або перенаправляє цей шлях, перевірка ніколи не завершується. Немає завершеної перевірки, немає сертифіката. А оскільки сертифікати оновлюються за розкладом, це часто збоїло тихо: магазин тижнями чудово працював на наявному сертифікаті, а потім ставав незахищеним того дня, коли той спливав. Ось чому стара порада була одним прямим рядком: зробіть хмару сірою, лише DNS, приберіть проксі Cloudflare зі шляху.

Що змінив Orange-to-Orange

Orange-to-Orange, або O2O, це відповідь Cloudflare на проблему двох зон, і вона є частиною продукту під назвою Cloudflare for SaaS. Cloudflare відкрив цей продукт для всіх клієнтів у 2021 році, із загальною доступністю в жовтні, тож O2O це усталений маршрут із роками за плечима, а не свіжий експеримент. Механізм простий: коли ваша проксована зона спрямовує CNAME на сервіс, який теж є клієнтом Cloudflare for SaaS, Cloudflare розпізнає ціль і перестає трактувати дві зони як конфлікт. Він маршрутизує запит спочатку через вашу зону, потім через зону провайдера, у визначеному порядку, і подвійне проксі стає передачею естафети.

Вам не треба вірити на слово, що O2O увімкнувся. Створіть CNAME з увімкненим проксі, і Cloudflare поставить невелику іконку Shopify поруч із записом. Ця іконка і є підтвердженням розпізнавання: він знає, куди йде трафік. Cloudflare також виконує специфічне для провайдера прибирання у фоні, зокрема вимикає Workers і Snippets на шляху /checkout, щоб ніщо з того, що ви запускаєте на edge, не могло втрутитися в оплату.

Ви додаєте цей запис у панелі Cloudflare в розділі DNS, далі Records. Натисніть Add record, встановіть Type на CNAME, Target на shops.myshopify.com, а Proxy status на Proxied, щоб хмара стала помаранчевою. Іконка Shopify з'являється поруч із записом, щойно Cloudflare розпізнає ціль як одного зі своїх SaaS-клієнтів.

Робота з єдиним винятком: SSL

O2O виправив конфлікт маршрутизації. Він не виправив SSL, бо SSL ніколи насправді не був проблемою маршрутизації. Це було проксі, що торкається єдиного шляху, яким Shopify оновлює сертифікати. У правильно налаштованому магазині майже все це тепер працює саме, тож корисно знати, що є автоматичним, а потім перевірити короткий список того, що ним не є.

Що тепер відбувається автоматично

Ваш магазин несе два сертифікати, і обидва оновлюються без вас. Оскільки домен проксований, сертифікат, який бачать відвідувачі, це власний edge-сертифікат Cloudflare, який Cloudflare валідує через DNS і оновлює самостійно, тож шлях ACME його ніколи не торкається. За ним Shopify тримає окремий origin-сертифікат для відрізка від Cloudflare до Shopify, оновлюваний через Let's Encrypt, і ваш режим шифрування Full створений саме для того, щоб йому довіряти. Shopify також виконує перехід з HTTP на HTTPS на власному origin, тож відвідувачі потрапляють на захищене з'єднання незалежно від того, чи ворухне Cloudflare пальцем.

Цей origin-сертифікат оновлюється через ACME, автоматизований обмін, яким Let's Encrypt підтверджує, що домен під вашим контролем. Він просить те, що відповідає за ваш домен, віддати одноразовий токен за шляхом вище, простим HTTP, і Shopify виконує весь обмін у фоні. Саме тому ви про це ніколи не думаєте. Конфігурація лишається справною рівно доти, доки цей один шлях лишається доступним.

Єдине, що це ламає

Усе це автоматичне оновлення тримається на одному налаштуванні Cloudflare, яке має лишатися вимкненим, а в багатьох конфігураціях воно увімкнене за замовчуванням.

Тож виправлення здебільшого зводиться до того, щоб не вмикати цей перемикач і дати origin-перенаправленню Shopify виконати підвищення, яке воно вже й так робить. Якщо ви хочете, щоб Cloudflare теж примусово вмикав HTTPS на своєму edge, використайте правило перенаправлення, яке пропускає шлях перевірки, а не Always Use HTTPS.

Що варто вибірково перевірити

Усе, що нижче, живе в панелі Cloudflare. Увійдіть на dash.cloudflare.com, виберіть свій акаунт і клацніть домен, щоб відкрити його зону. Кожен пункт це шлях у лівій бічній панелі цієї зони.

Один сусід на тій сторінці Edge Certificates збиває людей з пантелику: Automatic HTTPS Rewrites безпечно лишати увімкненим. Воно лише переписує посилання на ресурси з http на https, щоб уникнути попереджень про змішаний контент, а це зовсім не те саме, що Always Use HTTPS із примусовим перенаправленням усієї сторінки. Opportunistic Encryption і TLS 1.3 теж можуть лишатися увімкненими. Always Use HTTPS це єдиний перемикач на тому екрані, який має лишатися вимкненим.

Далі підтвердіть це ззовні, не чекаючи, поки оновлення зазнає невдачі. Запросіть шлях перевірки простим HTTP і прочитайте відповідь:

curl -sI http://clawmart.digital/.well-known/acme-challenge/test

Дійти до Shopify це і є перемога, а 404 для вигаданого токена саме те, що треба. Перенаправлення 301 або 308 на HTTPS означає, що Always Use HTTPS або якесь всеохопне правило досі поглинає цей шлях. Після цього перевірте статус SSL у розділі Settings → Domains в адмінці Shopify, а протягом наступних тижнів простежте, як дата спливання origin-сертифіката сама рухається вперед. Сертифікат, який оновлюється, коли його ніхто не чіпає, і є сигналом, що конфігурація тримається.

Запускайте цей тест знову після будь-якої зміни ваших DNS або налаштувань Cloudflare, а не лише під час першого налаштування. Користувач Shopify Community на ім'я Hardeep підняв це в гілці про цю статтю, і це збігається з тим, як такі конфігурації ламаються насправді. Налаштування було правильним у перший день, хтось відредагував правило або запис через місяці, і ніхто повторно не перевірив шлях перевірки, аж поки сертифікат тихо не оновився.

Одну пастку варто назвати прямо: сертифікат, який сьогодні показано як виданий, каже вам, що видався поточний, а не що видасться наступний. Сертифікати Let's Encrypt оновлюються приблизно кожні шістдесят до дев'яноста днів, тож магазин, який виглядає цілком здоровим, може просто ще не дійти до дати оновлення. Це, плюс той факт, що чимало магазинів взагалі ніколи не вмикали Always Use HTTPS, і є причиною, чому багато з них працюють так місяцями без жодної проблеми, і чому збій, коли він приходить, спантеличує. Нічого не змінилося, крім сертифіката, який тихо не оновився.

Оцініть це у правильній вазі. Це дешева страховка від нечастого, але тихого збою, а не ознака того, що ваш магазин ось-ось зламається. Зробіть двохвилинне налаштування, проженіть тест, і ви закрили ту єдину прогалину під час оновлення, яку справді важко помітити.

Shopify досі не схвалить це, тому що…

Документація Shopify більше не відмахується від «проксі» загалом. Вона прямо називає O2O:

«Конфігурації з проксі Cloudflare, включно з O2O, не підтримуються Shopify. Хоча ваш магазин може здаватися таким, що працює коректно, ця конфігурація може зламатися будь-якої миті.»

Це не застаріле попередження про вирішену проблему. Це чинна, свідома позиція, і дві з причин за нею тримаються навіть після O2O:

Власна документація Shopify додає третю причину, виявлення ботів, стверджуючи, що трафік через Cloudflare доходить до нього зі зміненими атрибутами запиту. На практиці це найслабша з трьох: Cloudflare керує однією з найбільших мереж керування ботами, що взагалі існують, тож більшість магазинів отримують на edge значно більше фільтрації ботів, ніж Shopify втрачає в сигналі. Це єдиний пункт зі списку Shopify, де проксі радше допоможе, ніж зашкодить.

Чи не занадто суворе це попередження?

Трохи, і це зрозуміло. Панель позначає працюючий, підключений магазин бурштиновим «Issue» і сухою фразою «not supported», що звучить важче за реальні сценарії збою, більшості з яких можна уникнути правильною конфігурацією. Продавець читає «Issue» і чує «ваш магазин ось-ось зламається», тоді як Shopify має на увазі щось ближче до «ми за це не ручаємося».

Але «не підтримується» це не «не працює», і різниця має значення. Це означає, що Shopify не гарантуватиме, не діагностуватиме і не братиме відповідальності за поведінку в шарі, який він не контролює. Для платформи, що володіє вашим чекаутом і вашим аптаймом, це розумна межа, навіть якщо банер проводить її грубо. Позначка каже вам, що Shopify не стоятиме за цією конфігурацією. Вона не каже вам, що конфігурація збоїть.

Багато магазинів Shopify працюють саме так

Вам не обов'язково вірити на слово одному тестовому магазину. Проксі Cloudflare перед Shopify це не маргінальна конфігурація: чимало відомих брендів тримають її в продакшені щодня. Наведені нижче назви це живі приклади, які ми перевірили вручну, кожен з них наразі віддає свою вітрину через проксі Cloudflare із Shopify позаду.

Перевірено в липні 2026 року шляхом запиту до кожного домену і підтвердження відповіді проксі Cloudflare разом із маркерами вітрини Shopify. Конфігурація магазину може змінитися будь-коли, тож сприймайте це як зріз, а не як схвалення з боку перелічених брендів.

Що edge дає вам такого, чого не дає Shopify

Shopify уже постачає CDN, SSL-сертифікати і захист від DDoS у кожному тарифі, як також зазначив Hardeep у гілці спільноти. Проксі не є тим, що робить ваш магазин швидким, зашифрованим чи здатним поглинути напад, і якщо ви шукали саме це, воно у вас уже є. Далі йде вужчий набір речей, яких Shopify вам не дає.

Причина прийняти цей компроміс не в самому проксі. Вона в шарі, який проксі ставить перед вашим магазином, у програмованому edge, який Shopify вам не відкриває. Найбільше значення мають три можливості, і третьої більшість магазинів не бачить узагалі.

Нічого з цього не йде в комплекті з тарифом Shopify, бо нічого з цього не живе всередині Shopify. Воно живе на один крок раніше, на edge, і це і є вся причина, чому продавець узагалі візьметься за непідтримуване проксі.

Одне застереження: кешування на edge не вмикається саме. Cloudflare може тримати статичні файли на кшталт таблиць стилів і зображень на своєму edge і віддавати їх із найближчого сервера замість того, щоб тягнути їх із Shopify на кожен візит, але проксований магазин Shopify не кешує самостійно, а стандартне чи неправильно окреслене правило кешу може придушити це повністю, тож файли, позначені як кешовані на рік, проходять наскрізь недоторканими. Власна мережа Shopify тримає вітрину швидкою в будь-якому разі, тож сприймайте edge-кешування як бонус до швидкості, який ви вмикаєте свідомо. Режим шифрування, що запобігає старим проблемам із SSL, ви підтверджуєте в конфігураціях SSL/TLS, на тому самому екрані, що й кнопка Configure, описана раніше; кешування налаштовується у власному розділі, тож варто перевірити обидва, поки ви в панелі, бо саме кешування є тим налаштуванням, яке найімовірніше лишає швидкість невикористаною.

Про що вас застереже розробник

Хороший розробник не пропустить це без питань, і питання справедливі. Жодне з них не є причиною уникати такої конфігурації, але кожне варто підтвердити на власному магазині, а не приймати на віру. Це не додаткова робота: це те саме тестування, яке ви запустили б після будь-якої зміни інфраструктури, і воно є частиною підтримання магазину в доброму стані. Ми тестуємо обидві наведені нижче речі на магазині, який ведемо, і вам варто теж.

Затримка на передачі

Перше питання це швидкість: чи додає маршрутизація через вашу зону Cloudflare перед власною зоною Shopify помітний час? Не має, бо обидві зони вже сидять в одній мережі Cloudflare, тож передача відбувається всередині цієї мережі, а не через відкритий інтернет. Ми виміряли це на clawmart.digital, проксованому тестовому магазині, проти сирих ендпоінтів Shopify myshopify.com з тієї самої машини. Проксований магазин відповідав на edge приблизно за 150 до 200 мілісекунд, у тій самій смузі, що й непроксовані ендпоінти Shopify поруч. Додатковий стрибок губився у звичайному розкиді між запусками.

Коли проксований магазин Shopify справді здається повільним, причина майже завжди у важкій темі або повільному сторонньому застосунку, а не в проксі. Виміряйте, перш ніж звинувачувати edge. Час до першого байта, запущений кілька разів з однієї локації, дає найшвидшу картину:

curl -o /dev/null -s -w "ttfb: %{time_starttransfer}s  total: %{time_total}s\n" https://clawmart.digital/

Порівняйте це з базовою лінією на сірій хмарі (лише DNS), або зі своєю адресою myshopify.com, або із запуском WebPageTest. Різниця в кілька мілісекунд означає, що проксі не є вашим вузьким місцем. Сотні мілісекунд означають, що ним є тема і стек застосунків, і саме туди варто вкласти час: підрізання теми, відключення застосунків, якими ви більше не користуєтеся, і виправлення того, як завантажуються зображення, зрушать цифру набагато сильніше, ніж будь-що, що ви налаштуєте на edge.

Застосунки в чекауті

Друге питання це чекаут: чи втрутиться проксі в застосунки checkout extensibility, оплату або скрипти, які виконуються на найважливішому кроці? За задумом не має. Маршрутизація O2O від Cloudflare вимикає Workers і Snippets саме на шляху /checkout, щоб ніщо з того, що ви запускаєте на edge, не могло торкнутися оплати. У нашому тестуванні жоден із популярних застосунків checkout extensibility не поводився неналежно за такої конфігурації. Це наш досвід, а не гарантія для кожного застосунку на ринку, тож завжди проганяйте повний чекаут самостійно.

Проведіть справжнє замовлення з увімкненими застосунками: підтвердіть, що знижки, логіка доставки, апсели й будь-які післяпродажні розширення спрацьовують так само, як без проксі, і що замовлення потрапляє в Shopify з очікуваними атрибутами. Якщо застосунок збирається поводитися неналежно, це вилізе саме тут, на вашому тестовому замовленні, задовго до того, як із цим зустрінеться клієнт.

Чи працюватимуть далі ваші функції Shopify?

Це питання, яке продавці ставлять просто перед тим, як відступити: якщо Cloudflare сидить попереду, чи поводитимуться так само речі, якими я керую всередині Shopify? Найбільше тривоги викликають URL-перенаправлення, бо ними керують в адмінці Shopify, вони важать для SEO, і не очевидно, чи проксі попереду закешує, перепише або поглине їх.

Тож ми протестували це на проксованому магазині, а не міркували про це. Ми створили 301 в адмінці Shopify з /pages/redirect-test-20260727 на головну, підтвердили, що до того шлях повертав 404, тож нічого реального не постраждало, перевірили це з кількох боків, а потім видалили.

Специфічна для Cloudflare відповідь у тому останньому рядку. Він пропускав перенаправлення наскрізь і ніколи їх не кешував, тож ваша логіка перенаправлень лишається цілком під контролем Shopify. І це теж не везіння: Shopify надсилає cache-control: private, no-store на самому 301, тож Cloudflare не закешував би його, навіть якби ви попросили. Рядки запиту виживають, apex працює, і простий HTTP працює.

Одна деталь із прибирання варта уваги, бо вона виглядає як проблема Cloudflare, а нею не є. Після того як ми видалили перенаправлення, гола URL-адреса ще близько тридцяти секунд віддавала старий 301, тоді як версія тієї самої URL-адреси з обходом кешу вже повертала 404. Це один edge-вузол Shopify тримав застарілу копію, а не Cloudflare: cf-cache-status увесь час лишався DYNAMIC, а варіант із рядком запиту був коректним одразу. Воно вирішилося саме. Тож після зміни або видалення перенаправлення дайте йому хвилину, перш ніж робити висновок, що воно не спрацювало, і тестуйте з обходом кешу, якщо не впевнені.

Це також в'яжеться із застереженням про кешування вище, і працює в обидва боки. З вимкненим edge-кешуванням зміни перенаправлень набувають чинності миттєво, що є випадковим плюсом. Якщо пізніше ви ввімкнете кешування HTML на edge, перенаправлення теж можуть кешуватися там, і ваші правки перестануть з'являтися одразу. Якщо підете цим шляхом, виключіть шляхи перенаправлень із правила кешу або вбудуйте крок очищення кешу в той інструмент, яким ви масово керуєте перенаправленнями.

Налаштування до того, як магазин стане публічним

Вам не потрібна запущена вітрина, щоб налаштувати і протестувати будь-що з цього. Часто розумніше зробити це, поки магазин ще приватний, щоб виявлення O2O, видача SSL і тест чекауту відбулися там, куди не забреде жоден клієнт. Єдина вимога це платний тариф Shopify, бо власні домени недоступні на безкоштовному пробному періоді. Утім, запускати магазин не обов'язково: платного тарифу за сторінкою з паролем достатньо для всього налаштування. Якщо ви на безкоштовному партнерському dev-магазині, який обмежує власні домени, спершу переведіть його на платний тариф, а потім виконайте ті самі кроки.

То чи варто це запускати?

Перетворіть це з так-чи-ні на рішення про те, що вам потрібно на edge, бо тільки це виправдовує компроміс.

Користувачі Shopify Community Steve_TopNewYork і sophia24 обидва зупинилися саме на цій третій причині в тій самій гілці, і це та ціна, яку продавці недооцінюють. Проксі рідко є тим, що ламається, але щойно воно опиняється на шляху, це ще один шар, який доведеться виключати о другій ночі, коли чекаут поводиться дивно, а ви ще не знаєте чому. Це реальний податок на малу команду, і платити його варто лише за функцію, яку ви можете назвати.

Якщо ви все ж це запускаєте, ставтеся до чеклиста як до обов'язкового: проксований CNAME на shops.myshopify.com, підтвердьте, що з'явилася іконка Shopify, залиште Always Use HTTPS вимкненим, виключіть шлях ACME зі свого HTTPS-перенаправлення і перевіряйте дату оновлення сертифіката так само, як перевіряли б, що резервна копія справді створилася. Налаштоване так, чимало магазинів працюють із Cloudflare перед Shopify без драм. Пропустіть ці кроки, і ви налаштували рівно ту тиху поломку, якій попередження і намагається запобігти.

Коротка версія, на відео: Field Notes: Cloudflare in front of Shopify проходить через те, що виправив O2O, і дві речі, які edge-сервіс показує вам, а Shopify ні.

Поширені запитання

Чи безпечно ставити Cloudflare перед магазином Shopify?

Це значно життєздатніше, ніж раніше, але Shopify офіційно цього не підтримує, тож це зважений вибір, а не безризиковий. Проблему маршрутизації, яка колись ламала магазини, а саме конфлікт двох зон Cloudflare, вирішила функція Orange-to-Orange (O2O) від Cloudflare. За правильної конфігурації, тобто проксований CNAME на shops.myshopify.com, вимкнений Always Use HTTPS і шлях перевірки ACME, виключений з будь-якого HTTPS-перенаправлення, чимало магазинів працюють так надійно. Власна документація Shopify досі стверджує, що конфігурації з проксі Cloudflare, включно з O2O, не підтримуються і можуть зламатися будь-якої миті, бо Shopify не може гарантувати поведінку проксі-шару, який він не контролює. Чесний підсумок: технічно справне, коли налаштоване правильно, офіційно не підтримуване, і краще залишити його для магазинів, яким потрібно на edge щось таке, чого Shopify не дає.

Що таке Orange-to-Orange (O2O)?

Orange-to-Orange це функція маршрутизації Cloudflare для випадку, коли клієнт Cloudflare спрямовує свій проксований домен на сервіс, який теж є клієнтом Cloudflare. Проксі Cloudflare показано в панелі як помаранчеву хмару, тож дві накладені зони Cloudflare це orange-to-orange. Shopify є клієнтом Cloudflare for SaaS, тож магазин Shopify це саме такий випадок. До O2O Cloudflare не міг надійно визначити, якій зоні має належати запит, і вони конфліктували. O2O виявляє, що ціль CNAME належить іншому клієнту Cloudflare, і маршрутизує запит спочатку через вашу зону, потім через зону провайдера, по порядку. Ви можете підтвердити, що це працює, коли поруч із записом CNAME у вашій панелі Cloudflare з’являється невелика іконка Shopify.

Чому Shopify каже, що Cloudflare не підтримується?

Документація Shopify наводить три головні причини. Дві з них добре тримаються. Перша, SSL: Shopify видає й оновлює сертифікати через Let’s Encrypt за допомогою HTTP-перевірки ACME, і будь-яке проксі попереду це ще одна річ, яка може завадити цій валідації. Друга, реагування на інциденти: коли з власною інфраструктурою Shopify виникає проблема, додаткові проксі перед магазином ускладнюють Shopify перемаршрутизацію в обхід, що радше підвищує вашу вразливість до простоїв, ніж знижує. Третя, виявлення ботів, слабша: Shopify стверджує, що трафік через Cloudflare приходить зі зміненими атрибутами запиту, але Cloudflare керує однією з найбільших у світі мереж керування ботами, тож більшість магазинів отримують на edge більше фільтрації ботів, ніж Shopify втрачає в сигналі. Жодна з цих причин не означає, що конфігурація не може працювати. Вони означають, що Shopify не візьме на себе відповідальність за поведінку в шарі, який йому не належить.

Чому мій SSL-сертифікат Shopify збоїть за Cloudflare?

Майже завжди через налаштування Always Use HTTPS. Shopify підтверджує право власності на домен і оновлює SSL-сертифікати, відповідаючи на перевірку, що обслуговується за шляхом /.well-known/acme-challenge/. Always Use HTTPS примусово перенаправляє кожен запит, включно з цим шляхом, тож перевірка ніколи не завершується, і сертифікат неможливо ні видати, ні оновити. Магазин продовжує працювати на наявному сертифікаті, доки той не спливе, а потім домен стає незахищеним або перестає з’єднуватися. Виправлення, яке документує Cloudflare, полягає в тому, щоб залишити Always Use HTTPS вимкненим, а натомість створити правило перенаправлення, яке примусово вмикає HTTPS для всього, крім шляху /.well-known/acme-challenge/.

Чи треба ставити нагадування в календарі, щоб перевіряти оновлення SSL і магазин не зламався?

Ні, якщо все налаштовано правильно. Оновлення задумане так, щоб працювати саме по собі. Сертифікат, який насправді бачать ваші відвідувачі, це власний edge-сертифікат Cloudflare, який Cloudflare валідує через DNS і оновлює автоматично, тож він взагалі ніколи не залежить від шляху перевірки ACME. За ним origin-сертифікат Shopify оновлюється через Let’s Encrypt у фоні, і це працює доти, доки Always Use HTTPS вимкнено, а шлях /.well-known/acme-challenge/ не перенаправляється. Проженіть одноразовий тест curl після налаштування, щоб підтвердити, що цей шлях повертає 404, а не перенаправлення, і автоматичне оновлення матиме все потрібне. Якщо хочете підстрахуватися, правильний інструмент це не ручне нагадування в календарі, на яке ви маєте реагувати, а автоматичний монітор строку дії SSL, який надішле вам лист, щойно до спливання сертифіката залишиться пара тижнів. Так ніщо не залежатиме від того, чи згадаєте ви дату.

Як я дізнаюся про проблему з сертифікатом до того, як вона покладе магазин?

Налаштуйте моніторинг, щоб вам повідомили, а не щоб ви дізналися від клієнта. Безкоштовний монітор SSL і доступності, як-от UptimeRobot, Better Uptime чи подібний сервіс, може стежити за доменом і сповістити вас за кілька днів до спливання сертифіката або в ту мить, коли HTTPS почне збоїти. Сам Cloudflare теж може надсилати сповіщення про проблеми із сертифікатами й origin з розділу Notifications у панелі. З будь-яким із цих засобів тихий збій оновлення, який і є єдиним реальним ризиком цієї конфігурації, перестає бути тихим: ви отримуєте лист із запасом у кілька тижнів, задовго до того, як замочок зламається для покупців.

Чи працюють URL-перенаправлення Shopify за проксі Cloudflare?

Так. Ми протестували це від початку до кінця на проксованому магазині: 301, створений в адмінці Shopify, запрацював одразу без очікування поширення, повернув коректний 301 і заголовок location, довів до 200 на цілі за один стрибок, зберіг рядки запиту на кшталт ?utm_source=test і працював з apex-домену та через простий HTTP. Cloudflare пропускав перенаправлення наскрізь і ніколи його не кешував, повідомляючи cf-cache-status: DYNAMIC на кожному запиті, тож ваша логіка перенаправлень лишається цілком під контролем Shopify. Shopify також надсилає cache-control: private, no-store на самому 301, тож Cloudflare не закешував би його, навіть якби ви це налаштували. Одне застереження: після зміни або видалення перенаправлення edge-вузол Shopify може віддавати застарілу копію близько тридцяти секунд, тож дайте йому хвилину і протестуйте з обходом кешу, перш ніж робити висновок, що не спрацювало. Якщо пізніше ви ввімкнете кешування HTML на edge Cloudflare, виключіть шляхи перенаправлень або додайте крок очищення кешу, бо перенаправлення можуть кешуватися і там.

Чи можна налаштувати Cloudflare на магазині Shopify, який ще не публічний?

Так, і часто це найрозумніший спосіб. Вам не потрібна запущена вітрина, потрібен лише платний тариф Shopify, оскільки власні домени недоступні на безкоштовному пробному періоді. Тримайте магазин за сторінкою з паролем у розділі Online Store, далі Preferences, створіть у Cloudflare той самий проксований CNAME на shops.myshopify.com, використавши хост, який ви не віддаєте в продакшені, наприклад staging-піддомен, і підключіть цей хост у Shopify в розділі Settings, далі Domains. Shopify видає SSL, а панель Cloudflare показує іконку Shopify, щойно вмикається Orange-to-Orange, і все це поки публіка бачить лише сторінку з паролем. Проженіть тест curl для ACME і повний тестовий чекаут з увімкненими застосунками, а коли все пройде, приберіть пароль і зробіть свій справжній домен основним. Ви запускаєтеся на конфігурації, яку вже перевірили. Якщо ви на безкоштовному партнерському dev-магазині, який обмежує власні домени, спершу переведіть його на платний тариф.