Teraz bezpieczniej jest postawić Cloudflare przed Shopify: co naprawiło O2O i co nadal oznaczają ostrzeżenia.

Szybki start: zrób to w swoim sklepie

Jeśli przyszedłeś po kroki, oto one. Cała konfiguracja to proxowany rekord CNAME w Cloudflare, ta sama domena podłączona w Shopify i jeden przełącznik HTTPS, którego nie ruszasz. Reszta artykułu wyjaśnia, dlaczego każdy krok ma znaczenie i jak potwierdzić, że zadziałał, ale to jest cała konfiguracja.

Wolisz obejrzeć: Field Notes: Cloudflare in front of Shopify omawia to samo w trzy minuty, z pełną transkrypcją na stronie.

Krok 1 w panelu Cloudflare: oba rekordy to CNAME wskazujące na shops.myshopify.com ze statusem proxy Proxied.

Wartości clawmart.digital pokazywane w całym tym artykule pochodzą z działającego sklepu testowego, który prowadzimy na w pełni funkcjonalnej instancji Shopify, a nie z makiety. Każdy zrzut ekranu, rekord i test poniżej pochodzi z tego sklepu.

Ostrzeżenie na działającym sklepie

Twoja domena Shopify pokazuje się jako podłączona, checkout działa, a kłódka SSL jest na miejscu. Bezpośrednio pod tym zielonym statusem siedzi bursztynowe ostrzeżenie, że Twoja domena ma proxy Cloudflare, którego Shopify nie obsługuje. Oba są prawdziwe w tym samym czasie i to właśnie na tej sprzeczności utyka większość sprzedawców.

To jeden z najbardziej mylących komunikatów w infrastrukturze ecommerce, bo nie jest błędny, ale też nie do końca trafny. Przez lata stawianie Cloudflare przed Shopify było naprawdę złym pomysłem, który psuł sklepy w konkretny, przewidywalny sposób. Potem Cloudflare wypuścił funkcję routingu, która naprawiła dokładnie to, co się psuło, a mimo to Shopify nadal odradza takie rozwiązanie. Ta luka, między działającą poprawką a dostawcą, który jej nie firmuje, to miejsce, w którym mieszka obawa "czy mój sklep zaraz się zepsuje".

Oto więc wersja praktyczna: co faktycznie się psuło, co naprawiło O2O, jedno ustawienie, które nadal położy Twoją stronę, jeśli je przeoczysz, i jak zdecydować, czy cokolwiek z tego pasuje do Twojego sklepu.

Dlaczego kiedyś się psuło: dwie pomarańczowe chmury

Cloudflare pokazuje proxowaną domenę jako pomarańczową chmurkę. Ruch do tej domeny przechodzi przez sieć Cloudflare, zanim dotrze do Twojego origin. Haczyk w przypadku Shopify polega na tym, że Shopify samo działa na Cloudflare. Więc kiedy kierujesz swoją domenę z pomarańczową chmurką na Shopify, żądanie dociera do Cloudflare z dwiema strefami, które obie je do siebie przypisują: Twoją i strefą Shopify. Dwie pomarańczowe chmury, jedna na drugiej.

Historycznie Cloudflare nie potrafił wiarygodnie stwierdzić, która strefa powinna przejąć to żądanie, więc rozwiązywał je w złym miejscu albo zapętlał. Rezultatem był sklep, który działał połowicznie i zawodził w sposób trudny do odtworzenia.

Najostrzejszą krawędzią było SSL. Shopify wystawia i odnawia Twój certyfikat przez Let's Encrypt, a Let's Encrypt potwierdza własność domeny wyzwaniem ACME serwowanym pod konkretną ścieżką:

Jeśli proxy stojące przed Shopify przechwyci, zbuforuje lub przekieruje tę ścieżkę, wyzwanie nigdy się nie kończy. Brak ukończonego wyzwania oznacza brak certyfikatu. A ponieważ certyfikaty odnawiają się według harmonogramu, często zawodziło to po cichu: sklep działał bez zarzutu na istniejącym certyfikacie przez tygodnie, a potem tracił bezpieczne połączenie w dniu, w którym certyfikat wygasł. Dlatego dawna rada sprowadzała się do jednej stanowczej linijki: zrób chmurkę szarą, tylko DNS, usuń proxy Cloudflare ze ścieżki.

Co zmieniło Orange-to-Orange

Orange-to-Orange, w skrócie O2O, to odpowiedź Cloudflare na problem dwóch stref i element produktu o nazwie Cloudflare for SaaS. Cloudflare otworzył ten produkt dla wszystkich klientów w 2021 roku, z ogólną dostępnością w październiku, więc O2O to ustabilizowana ścieżka routingu z latami za sobą, a nie świeży eksperyment. Mechanizm jest prosty: kiedy Twoja proxowana strefa kieruje rekord CNAME na usługę, która również jest klientem Cloudflare for SaaS, Cloudflare rozpoznaje cel i przestaje traktować obie strefy jako kolizję. Kieruje żądanie najpierw przez Twoją strefę, a potem przez strefę dostawcy, w ustalonej kolejności, i podwójne proxy staje się przekazaniem pałeczki.

Nie musisz przyjmować na wiarę, że O2O zadziałało. Utwórz rekord CNAME z włączonym proxy, a Cloudflare umieści obok rekordu małą ikonę Shopify. Ta ikona to potwierdzenie wykrycia, że Cloudflare wie, dokąd zmierza ruch. Cloudflare wykonuje też w tle porządki specyficzne dla dostawcy, w tym wyłącza Workers i Snippets na ścieżce /checkout, tak aby nic, co uruchamiasz na brzegu sieci, nie mogło ingerować w płatność.

Ten rekord dodajesz w panelu Cloudflare w sekcji DNS, a następnie Records. Kliknij Add record, ustaw Type na CNAME, Target na shops.myshopify.com, a Proxy status na Proxied, tak aby chmurka zrobiła się pomarańczowa. Ikona Shopify pojawia się obok rekordu, gdy Cloudflare rozpozna cel jako jednego ze swoich klientów SaaS.

Jeden wyjątek do ogarnięcia: SSL

O2O naprawiło kolizję routingu. Nie naprawiło SSL, bo SSL nigdy nie było tak naprawdę problemem routingu. Był to problem proxy dotykającego jednej ścieżki, której Shopify używa do odnawiania certyfikatów. W poprawnie skonfigurowanym sklepie prawie wszystko dzieje się teraz samo, więc warto wiedzieć, co jest automatyczne, a potem sprawdzić krótką listę tego, co nie jest.

Co dzieje się teraz automatycznie

Twój sklep nosi dwa certyfikaty i oba odnawiają się bez Ciebie. Ponieważ domena jest proxowana, certyfikatem, który widzą odwiedzający, jest własny certyfikat brzegowy Cloudflare, walidowany przez Cloudflare po DNS i odnawiany samodzielnie, więc ścieżka ACME nigdy go nie dotyczy. Za nim Shopify utrzymuje osobny certyfikat origin dla odcinka od Cloudflare do Shopify, odnawiany przez Let's Encrypt, a Twój tryb szyfrowania Full jest tak zbudowany, by mu ufać. Shopify wykonuje też podniesienie z HTTP na HTTPS we własnym origin, więc odwiedzający lądują na bezpiecznym połączeniu niezależnie od tego, czy Cloudflare kiwnie palcem.

Ten certyfikat origin odnawia się przez ACME, zautomatyzowaną wymianę, której Let's Encrypt używa do potwierdzenia, że kontrolujesz domenę. Prosi to, co odpowiada za Twoją domenę, o wystawienie jednorazowego tokenu pod powyższą ścieżką, po zwykłym HTTP, a Shopify obsługuje całą wymianę w tle. Dlatego nigdy o tym nie myślisz. Konfiguracja pozostaje zdrowa dokładnie tak długo, jak długo ta jedna ścieżka pozostaje osiągalna.

Jedna rzecz, która to psuje

Całe to automatyczne odnawianie opiera się na jednym ustawieniu Cloudflare pozostającym wyłączonym, a w wielu konfiguracjach jest ono domyślnie włączone.

Naprawa polega więc głównie na tym, żeby tego przełącznika nie włączać i pozwolić przekierowaniu w origin Shopify wykonać podniesienie, które i tak już realizuje. Jeśli chcesz, żeby Cloudflare wymuszał HTTPS także na własnym brzegu, użyj reguły przekierowania, która pomija ścieżkę wyzwania, nigdy Always Use HTTPS.

Co warto sprawdzić

Wszystko poniżej znajduje się w panelu Cloudflare. Zaloguj się na dash.cloudflare.com, wybierz swoje konto i kliknij domenę, aby otworzyć jej strefę. Każda pozycja to ścieżka w lewym menu bocznym tej strefy.

Jeden sąsiad na stronie Edge Certificates myli ludzi: Automatic HTTPS Rewrites można spokojnie zostawić włączone. Przepisuje jedynie odnośniki do zasobów z http na https, żeby zapobiec ostrzeżeniom o mieszanej treści, co nie ma nic wspólnego z Always Use HTTPS wymuszającym przekierowanie całej strony. Opportunistic Encryption i TLS 1.3 też mogą zostać włączone. Always Use HTTPS to jedyny przełącznik na tym ekranie, który musi pozostać wyłączony.

Potem potwierdź to z zewnątrz, nie czekając, aż odnowienie zawiedzie. Poproś o ścieżkę wyzwania po zwykłym HTTP i odczytaj odpowiedź:

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

Dotarcie do Shopify to sukces, a 404 dla zmyślonego tokenu jest dokładnie tym, czego oczekujesz. Przekierowanie 301 lub 308 na HTTPS oznacza, że Always Use HTTPS albo reguła łapiąca wszystko nadal połyka tę ścieżkę. Następnie sprawdź status SSL w Settings → Domains w panelu Shopify, a przez kolejne tygodnie obserwuj, jak data wygaśnięcia certyfikatu origin sama przesuwa się do przodu. Certyfikat, który odnawia się bez ingerencji, jest sygnałem, że konfiguracja się trzyma.

Uruchom ten test ponownie po każdej zmianie w DNS lub ustawieniach Cloudflare, nie tylko przy pierwszej konfiguracji. Użytkownik Shopify Community, Hardeep, zwrócił na to uwagę w wątku o tym artykule, i pokrywa się to z tym, jak takie konfiguracje faktycznie się psują. Konfiguracja była poprawna pierwszego dnia, ktoś edytował regułę albo rekord kilka miesięcy później, i nikt nie sprawdził ponownie ścieżki wyzwania, aż certyfikat po cichu przestał się odnawiać.

Jedną pułapkę warto nazwać wprost: certyfikat pokazywany dziś jako wystawiony mówi Ci, że obecny został wydany, a nie że kolejne odnowienie się powiedzie. Certyfikaty Let's Encrypt odnawiają się mniej więcej w cyklu od sześćdziesięciu do dziewięćdziesięciu dni, więc sklep, który wygląda na całkowicie zdrowy, może być po prostu sklepem, który jeszcze nie dobił do daty odnowienia. To, plus fakt, że wiele sklepów nigdy nie włączyło Always Use HTTPS, jest powodem, dla którego mnóstwo z nich działa tak miesiącami bez potknięcia, i dlaczego awaria, gdy przychodzi, jest myląca. Nic się nie zmieniło, poza certyfikatem, który po cichu się nie odnowił.

Nadaj temu właściwą wagę. To tania polisa na rzadką, ale cichą awarię, a nie znak, że Twój sklep zaraz padnie. Zrób dwuminutową konfigurację, uruchom test, a zamkniesz jedyną lukę w momencie odnowienia, którą naprawdę trudno zauważyć.

Shopify nadal tego nie firmuje, ponieważ…

Dokumentacja Shopify nie macha już ogólnikowo ręką w stronę "proxy" jako takich. Wymienia O2O wprost:

"Konfiguracje z proxy Cloudflare, w tym O2O, nie są obsługiwane przez Shopify. Choć Twój sklep może wyglądać na działający poprawnie, taka konfiguracja może przestać działać w każdej chwili."

To nie jest przestarzałe ostrzeżenie o rozwiązanym problemie. To aktualne, świadome stanowisko, a dwa z powodów, które za nim stoją, bronią się nawet po O2O:

Dokumentacja Shopify dodaje trzeci powód, wykrywanie botów, argumentując, że ruch przechodzący przez Cloudflare dociera do niej ze zmienionymi atrybutami żądania. W praktyce jest to najsłabszy z trzech: Cloudflare prowadzi jedną z największych sieci zarządzania botami, jakie istnieją, więc większość sklepów zyskuje na brzegu znacznie więcej filtrowania botów, niż Shopify traci sygnału. To jedyna pozycja na liście Shopify, w której proxy raczej pomaga, niż szkodzi.

Czy to ostrzeżenie jest przesadzone?

Trochę tak, i to zrozumiałe. Panel oznacza działający, podłączony sklep bursztynowym "Issue" i płaskim sformułowaniem "not supported", co brzmi ciężej niż realne scenariusze awarii, z których większości da się uniknąć poprawną konfiguracją. Sprzedawca czyta "Issue", a słyszy "twój sklep zaraz się zepsuje", podczas gdy Shopify ma na myśli raczej "nie będziemy za to ręczyć".

Ale "nieobsługiwane" to nie "nie działa" i ta różnica ma znaczenie. Oznacza, że Shopify nie będzie gwarantować, diagnozować ani brać odpowiedzialności za zachowanie warstwy, której nie kontroluje. Dla platformy, która trzyma Twój checkout i Twoją dostępność, to rozsądna granica, nawet jeśli baner rysuje ją bezceremonialnie. Flaga mówi Ci, że Shopify nie stanie za tą konfiguracją. Nie mówi, że konfiguracja zawodzi.

Wiele sklepów Shopify działa w ten sposób

Nie musisz wierzyć na słowo jednemu sklepowi testowemu. Proxy Cloudflare przed Shopify to nie niszowa konfiguracja: mnóstwo uznanych marek używa jej produkcyjnie, każdego dnia. Nazwy poniżej to żywe przykłady, które zweryfikowaliśmy ręcznie, każda obecnie serwuje swoją witrynę przez proxy Cloudflare z Shopify z tyłu.

Zweryfikowane w lipcu 2026 roku przez odpytanie każdej domeny i potwierdzenie odpowiedzi proxy Cloudflare wraz ze znacznikami witryny Shopify. Konfiguracja sklepu może się zmienić w każdej chwili, więc traktuj to jako zdjęcie stanu, a nie rekomendację ze strony wymienionych marek.

Co daje Ci brzeg sieci, czego nie daje Shopify

Shopify dostarcza już CDN, certyfikaty SSL i ochronę przed DDoS w każdym planie, na co zwrócił uwagę także Hardeep w wątku społeczności. To nie proxy sprawia, że Twój sklep jest szybki, szyfrowany czy zdolny wchłonąć zalew ruchu, a jeśli po to się rozglądałeś, już to masz. Poniżej opisujemy węższy zestaw rzeczy, których Shopify Ci nie daje.

Powodem, by przyjąć ten kompromis, nie jest samo proxy. Jest nim warstwa, którą proxy stawia przed Twoim sklepem: programowalny brzeg sieci, którego Shopify Ci nie udostępnia. Najbardziej liczą się trzy możliwości, a trzeciej większość sklepów w ogóle nie widzi.

Nic z tego nie przychodzi razem z planem Shopify, bo nic z tego nie żyje wewnątrz Shopify. Żyje o jeden przeskok wcześniej, na brzegu sieci, i to jest cały powód, dla którego sprzedawca w ogóle bierze na siebie nieobsługiwane proxy.

Jedno zastrzeżenie: buforowanie na brzegu nie jest automatyczne. Cloudflare potrafi trzymać pliki statyczne, takie jak arkusze stylów i obrazy, na swoim brzegu i serwować je z pobliskiego serwera zamiast pobierać je z Shopify przy każdej wizycie, ale proxowany sklep Shopify nie buforuje sam z siebie, a domyślna lub źle zakresowana reguła cache może całkowicie to zdusić, więc pliki oznaczone jako możliwe do zbuforowania na rok przechodzą prosto, nietknięte. Własna sieć Shopify i tak utrzymuje witrynę szybką, więc traktuj buforowanie na brzegu jako bonus do prędkości, który włączasz świadomie. Tryb szyfrowania zapobiegający dawnym problemom z SSL potwierdzasz w konfiguracji SSL/TLS, na tym samym ekranie co przycisk Configure opisany wcześniej; buforowanie ustawia się w osobnym miejscu, więc warto sprawdzić oba, gdy już jesteś w panelu, bo to właśnie buforowanie najczęściej zostawia niewykorzystaną prędkość na stole.

Przed czym ostrzeże Cię deweloper

Dobry deweloper nie przepuści tego bez pytań, a pytania są uzasadnione. Żadne z nich nie jest powodem, by unikać takiej konfiguracji, ale każde warto potwierdzić na własnym sklepie, zamiast przyjmować na wiarę. To nie jest dodatkowa praca: to te same testy, które przeprowadziłbyś po każdej zmianie infrastruktury, i element utrzymywania sklepu w zdrowiu. Testujemy obie poniższe rzeczy na sklepie, który prowadzimy, i Ty też powinieneś.

Opóźnienie przy przekazaniu

Pierwsze pytanie dotyczy szybkości: czy przechodzenie przez Twoją strefę Cloudflare przed strefą Shopify dokłada zauważalny czas? Nie powinno, bo obie strefy siedzą już w tej samej sieci Cloudflare, więc przekazanie odbywa się wewnątrz tej sieci, a nie w otwartym internecie. Zmierzyliśmy to na clawmart.digital, proxowanym sklepie testowym, porównując z surowymi endpointami Shopify myshopify.com z tej samej maszyny. Proxowany sklep odpowiadał na brzegu w mniej więcej 150 do 200 milisekund, w tym samym paśmie co stojące obok nieproxowane endpointy Shopify. Dodatkowy przeskok utonął w normalnej zmienności między przebiegami.

Kiedy proxowany sklep Shopify faktycznie wydaje się wolny, przyczyną jest niemal zawsze ciężki szablon albo wolna aplikacja firmy trzeciej, a nie proxy. Zmierz, zanim obwinisz brzeg sieci. Czas do pierwszego bajtu, mierzony kilka razy z jednej lokalizacji, jest najszybszym odczytem:

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

Porównaj to z bazą na szarej chmurce (tylko DNS), albo ze swoim adresem myshopify.com, albo z przebiegiem WebPageTest. Kilka milisekund różnicy oznacza, że proxy nie jest Twoim wąskim gardłem. Setki milisekund oznaczają, że są nim szablon i stos aplikacji, i to tam warto poświęcić czas: odchudzenie szablonu, wycięcie aplikacji, których już nie używasz, i poprawienie sposobu ładowania obrazów przesuną tę liczbę znacznie bardziej niż cokolwiek, co skonfigurujesz na brzegu.

Aplikacje w checkoucie

Drugie pytanie dotyczy checkoutu: czy proxy będzie ingerować w aplikacje checkout extensibility, płatności albo skrypty działające na najważniejszym kroku? Z założenia nie powinno. Routing O2O od Cloudflare wyłącza Workers i Snippets właśnie na ścieżce /checkout, tak aby nic, co uruchamiasz na brzegu, nie mogło dotknąć płatności. W naszych testach żadna z popularnych aplikacji checkout extensibility nie zachowała się źle w tej konfiguracji. To nasze doświadczenie, a nie gwarancja dla każdej aplikacji na rynku, więc zawsze przeprowadź pełny checkout samodzielnie.

Złóż prawdziwe zamówienie z włączonymi aplikacjami: potwierdź, że rabaty, logika wysyłki, upselle i wszelkie rozszerzenia pozakupowe działają tak samo jak bez proxy, i że zamówienie trafia do Shopify z atrybutami, których oczekujesz. Jeśli jakaś aplikacja ma się zachować źle, pokaże się to właśnie tutaj, na Twoim zamówieniu testowym, na długo zanim spotka to klienta.

Czy funkcje Shopify nadal będą działać?

To pytanie, które sprzedawcy zadają tuż przed wycofaniem się: jeśli Cloudflare stoi z przodu, czy rzeczy, którymi zarządzam wewnątrz Shopify, nadal zachowują się jak trzeba? Największy niepokój budzą przekierowania adresów URL, bo zarządza się nimi w panelu Shopify, mają znaczenie dla SEO i nie jest oczywiste, czy stojące z przodu proxy je zbuforuje, przepisze albo połknie.

Przetestowaliśmy to więc na proxowanym sklepie, zamiast rozważać teoretycznie. Utworzyliśmy w panelu Shopify przekierowanie 301 z /pages/redirect-test-20260727 na stronę główną, potwierdziliśmy, że ścieżka wcześniej zwracała 404, więc nic realnego nie ucierpiało, sprawdziliśmy je pod kilkoma kątami, a potem usunęliśmy.

Odpowiedź specyficzna dla Cloudflare jest w ostatnim wierszu. Przepuścił przekierowania na wylot i nigdy ich nie zbuforował, więc Twoja logika przekierowań pozostaje w całości pod kontrolą Shopify. To zresztą nie przypadek: Shopify wysyła cache-control: private, no-store na samym 301, więc Cloudflare nie zbuforowałby go, nawet gdybyś go o to poprosił. Ciągi zapytań przeżywają, domena główna działa i zwykłe HTTP działa.

Jeden szczegół z porządkowania warto znać, bo wygląda na problem Cloudflare, a nim nie jest. Po usunięciu przekierowania goły adres URL nadal serwował stare 301 przez mniej więcej trzydzieści sekund, podczas gdy wersja tego samego adresu z dopiskiem łamiącym cache zwracała już 404. To pojedynczy węzeł brzegowy Shopify trzymał nieaktualną kopię, a nie Cloudflare: cf-cache-status przez cały czas pozostawał DYNAMIC, a wariant z ciągiem zapytania był poprawny od razu. Rozwiązało się samo. Po zmianie lub usunięciu przekierowania daj mu więc minutę, zanim uznasz, że nie zadziałało, i przetestuj z dopiskiem łamiącym cache, jeśli nie masz pewności.

To łączy się też z wcześniejszym zastrzeżeniem o buforowaniu i działa w obie strony. Przy wyłączonym buforowaniu na brzegu zmiany przekierowań działają natychmiast, co jest przypadkową zaletą. Jeśli później włączysz buforowanie HTML na brzegu, przekierowania też mogą tam trafić do cache, a Twoje edycje przestaną pojawiać się od razu. Jeśli pójdziesz tą drogą, wyklucz ścieżki przekierowań z reguły cache albo wbuduj krok czyszczenia cache w narzędzia, których używasz do masowego zarządzania przekierowaniami.

Konfiguracja, zanim sklep stanie się publiczny

Nie potrzebujesz uruchomionej witryny, żeby to wszystko skonfigurować i przetestować. Często mądrzej jest zrobić to, gdy sklep jest jeszcze prywatny, tak aby wykrycie O2O, wystawienie SSL i test checkoutu odbyły się tam, gdzie żaden klient nie wejdzie w niedokończoną konfigurację. Jedynym wymogiem jest płatny plan Shopify, bo domeny własne nie są dostępne w darmowym okresie próbnym. Nie musisz jednak uruchamiać sklepu: płatny plan trzymany za stroną z hasłem to wszystko, czego potrzeba do konfiguracji. Jeśli działasz na darmowym sklepie deweloperskim Partner, który ogranicza domeny własne, najpierw przenieś go na płatny plan, a potem wykonaj te same kroki.

Więc czy warto to uruchomić?

Zamień to z pytania tak-albo-nie na decyzję o tym, czego potrzebujesz na brzegu sieci, bo tylko to uzasadnia ten kompromis.

Użytkownicy Shopify Community, Steve_TopNewYork i sophia24, obaj wskazali na ten trzeci powód w tym samym wątku, i to właśnie ten koszt sprzedawcy niedoceniają. Proxy rzadko jest tym, co się psuje, ale gdy już znajdzie się w ścieżce, jest jedną warstwą więcej do wykluczenia o drugiej w nocy, kiedy checkout zachowuje się dziwnie, a Ty jeszcze nie wiesz dlaczego. To realny podatek dla małego zespołu i warto go płacić tylko za funkcję, którą potrafisz nazwać.

Jeśli już to uruchamiasz, traktuj listę kontrolną jako nienegocjowalną: proxowany rekord CNAME na shops.myshopify.com, potwierdzenie, że pojawia się ikona Shopify, Always Use HTTPS pozostawione wyłączone, wykluczenie ścieżki ACME z przekierowania na HTTPS i sprawdzanie daty odnowienia certyfikatu tak, jak sprawdzasz, czy kopia zapasowa faktycznie się wykonała. Skonfigurowane w ten sposób, mnóstwo sklepów działa z Cloudflare przed Shopify bez dramatów. Pomiń te kroki, a przygotujesz dokładnie tę cichą awarię, przed którą ostrzeżenie ma chronić.

Krótka wersja, na wideo: Field Notes: Cloudflare in front of Shopify przechodzi przez to, co naprawiło O2O, i dwie rzeczy, które usługa brzegowa pokazuje, a Shopify nie.

Najczęściej zadawane pytania

Czy stawianie Cloudflare przed sklepem Shopify jest bezpieczne?

Jest to znacznie bardziej wykonalne niż kiedyś, ale Shopify oficjalnie tego nie wspiera, więc jest to wybór wykalkulowany, a nie pozbawiony ryzyka. Problem routingu, który kiedyś psuł sklepy, czyli kolizja dwóch stref Cloudflare, został rozwiązany przez funkcję Orange-to-Orange (O2O) od Cloudflare. Poprawnie skonfigurowane, czyli proxowany CNAME na shops.myshopify.com, brak Always Use HTTPS i ścieżka wyzwania ACME wykluczona z każdego przekierowania na HTTPS, sprawia, że wiele sklepów działa na tym niezawodnie. Własna dokumentacja Shopify nadal stwierdza, że konfiguracje z proxy Cloudflare, w tym O2O, nie są obsługiwane i mogą przestać działać w każdej chwili, ponieważ Shopify nie może gwarantować zachowania warstwy proxy, której nie kontroluje. Uczciwe podsumowanie: technicznie sensowne przy poprawnej konfiguracji, oficjalnie nieobsługiwane, najlepiej zarezerwowane dla sklepów, które potrzebują na brzegu sieci czegoś, czego Shopify nie zapewnia.

Czym jest Orange-to-Orange (O2O)?

Orange-to-Orange to funkcja routingu Cloudflare na wypadek, gdy klient Cloudflare kieruje swoją proxowaną domenę na usługę, która również jest klientem Cloudflare. Proxy Cloudflare jest pokazywane w panelu jako pomarańczowa chmurka, więc dwie nałożone na siebie strefy Cloudflare to orange-to-orange. Shopify jest klientem Cloudflare for SaaS, więc sklep Shopify to dokładnie ten przypadek. Przed O2O Cloudflare nie potrafił wiarygodnie stwierdzić, która strefa powinna przejąć żądanie, i obie kolidowały ze sobą. O2O wykrywa, że cel rekordu CNAME należy do innego klienta Cloudflare, i kieruje żądanie najpierw przez Twoją strefę, a potem przez strefę dostawcy, w tej kolejności. Potwierdzeniem, że działa, jest mała ikona Shopify pojawiająca się obok rekordu CNAME w Twoim panelu Cloudflare.

Dlaczego Shopify twierdzi, że Cloudflare nie jest obsługiwany?

Dokumentacja Shopify podaje trzy główne powody. Dwa bronią się dobrze. Po pierwsze SSL: Shopify wystawia i odnawia certyfikaty przez Let’s Encrypt, korzystając z wyzwania ACME po HTTP, a każde proxy z przodu to jedna rzecz więcej, która może zakłócić tę walidację. Po drugie reakcja na incydenty: kiedy własna infrastruktura Shopify ma problem, dodatkowe proxy przed sklepem utrudniają Shopify obejście awarii przez przekierowanie ruchu, co zwiększa ekspozycję na przestoje, zamiast ją zmniejszać. Trzeci powód, wykrywanie botów, jest słabszy: Shopify argumentuje, że ruch przechodzący przez Cloudflare dociera ze zmienionymi atrybutami żądania, ale Cloudflare prowadzi jedną z największych sieci zarządzania botami na świecie, więc większość sklepów zyskuje na brzegu więcej filtrowania botów, niż Shopify traci sygnału. Żaden z tych powodów nie oznacza, że taka konfiguracja nie może działać. Oznaczają, że Shopify nie weźmie odpowiedzialności za zachowanie warstwy, której nie posiada.

Dlaczego mój certyfikat SSL w Shopify zawodzi za Cloudflare?

Niemal zawsze z powodu ustawienia Always Use HTTPS. Shopify weryfikuje własność domeny i odnawia certyfikaty SSL, odpowiadając na wyzwanie serwowane pod ścieżką /.well-known/acme-challenge/. Always Use HTTPS wymusza przekierowanie przy każdym żądaniu, w tym dla tej ścieżki, więc wyzwanie nigdy się nie kończy, a certyfikat nie może zostać wystawiony ani odnowiony. Sklep działa dalej na istniejącym certyfikacie aż do jego wygaśnięcia, a potem domena traci bezpieczne połączenie albo przestaje się łączyć. Rozwiązanie opisane przez Cloudflare to pozostawienie Always Use HTTPS wyłączonego i utworzenie zamiast tego reguły przekierowania, która wymusza HTTPS dla wszystkiego poza ścieżką /.well-known/acme-challenge/.

Czy muszę ustawić przypomnienie w kalendarzu, żeby sprawdzać odnowienie SSL i uchronić sklep przed awarią?

Nie, o ile wszystko jest poprawnie skonfigurowane. Odnawianie jest zaprojektowane tak, by działać samo. Certyfikat, który faktycznie widzą Twoi odwiedzający, to własny certyfikat brzegowy Cloudflare, walidowany przez Cloudflare po DNS i odnawiany automatycznie, więc w ogóle nie zależy od ścieżki wyzwania ACME. Za nim certyfikat origin Shopify odnawia się w tle przez Let’s Encrypt i działa to dalej tak długo, jak Always Use HTTPS pozostaje wyłączone, a ścieżka /.well-known/acme-challenge/ nie jest przekierowywana. Uruchom jednorazowy test curl po konfiguracji, aby potwierdzić, że ta ścieżka zwraca 404, a nie przekierowanie, a automatyczne odnawianie będzie miało wszystko, czego potrzebuje. Jeśli chcesz mieć siatkę bezpieczeństwa, właściwym narzędziem nie jest ręczne przypomnienie w kalendarzu, na które musisz zareagować, tylko automatyczny monitor wygasania SSL, który wyśle Ci e-mail, jeśli do wygaśnięcia certyfikatu zostanie kilka tygodni. Dzięki temu nic nie zależy od tego, czy pamiętasz o rocznicy.

Skąd mam wiedzieć o problemie z certyfikatem, zanim położy on sklep?

Ustaw monitoring, żeby dowiedzieć się o tym z powiadomienia, a nie od klienta. Darmowy monitor SSL i dostępności, taki jak UptimeRobot, Better Uptime lub podobna usługa, może obserwować domenę i ostrzec Cię na kilka dni przed wygaśnięciem certyfikatu albo w chwili, gdy HTTPS zacznie zawodzić. Także sam Cloudflare potrafi wysyłać powiadomienia o problemach z certyfikatami i origin z sekcji Notifications w panelu. Przy którymkolwiek z tych rozwiązań ciche niepowodzenie odnowienia, które jest jedynym realnym ryzykiem tej konfiguracji, przestaje być ciche: dostajesz e-mail z kilkutygodniowym wyprzedzeniem, na długo zanim kłódka pęknie kupującym.

Czy przekierowania URL z Shopify nadal działają za proxy Cloudflare?

Tak. Przetestowaliśmy to od początku do końca na proxowanym sklepie: przekierowanie 301 utworzone w panelu Shopify zadziałało natychmiast, bez czekania na propagację, zwróciło poprawny status 301 i nagłówek location, doprowadziło do 200 w celu w jednym przeskoku, zachowało ciągi zapytań takie jak ?utm_source=test i działało z domeny głównej oraz po zwykłym HTTP. Cloudflare przepuścił przekierowanie na wylot i nigdy go nie zbuforował, raportując cf-cache-status: DYNAMIC przy każdym żądaniu, więc Twoja logika przekierowań pozostaje w całości pod kontrolą Shopify. Shopify wysyła też cache-control: private, no-store na samym 301, więc Cloudflare nie zbuforowałby go, nawet gdybyś tak to skonfigurował. Jedno zastrzeżenie: po zmianie lub usunięciu przekierowania węzeł brzegowy Shopify może przez około trzydzieści sekund serwować nieaktualną kopię, więc daj mu minutę i przetestuj z dopiskiem łamiącym cache, zanim uznasz, że nie zadziałało. Jeśli później włączysz buforowanie HTML na brzegu Cloudflare, wyklucz ścieżki przekierowań albo dodaj krok czyszczenia cache, bo przekierowania też mogą tam trafić do cache.

Czy mogę skonfigurować Cloudflare na sklepie Shopify, który nie jest jeszcze publiczny?

Tak, i często jest to mądry sposób. Nie potrzebujesz uruchomionej witryny, tylko płatnego planu Shopify, ponieważ domeny własne nie są dostępne w darmowym okresie próbnym. Trzymaj sklep za stroną z hasłem w Online Store, a następnie Preferences, utwórz w Cloudflare taki sam proxowany CNAME na shops.myshopify.com, używając hosta, którego nie serwujesz na produkcji, na przykład subdomeny stagingowej, i podłącz ten host w Shopify w Settings, a następnie Domains. Shopify wystawi SSL, a panel Cloudflare pokaże ikonę Shopify, gdy tylko zadziała Orange-to-Orange, a publiczność przez cały czas widzi jedynie stronę z hasłem. Uruchom test curl dla ACME i pełny testowy checkout z włączonymi aplikacjami, a kiedy wszystko przejdzie, usuń hasło i ustaw swoją prawdziwą domenę jako podstawową. Startujesz na konfiguracji, którą masz już sprawdzoną. Jeśli działasz na darmowym sklepie deweloperskim Partner, który ogranicza domeny własne, najpierw przenieś go na płatny plan.