Kini lebih selamat meletakkan Cloudflare di hadapan Shopify: apa yang O2O perbaiki, dan apa maksud amaran itu.

Permulaan Pantas: Lakukan Ini pada Kedai Anda

Jika anda datang untuk langkah-langkahnya, inilah dia. Keseluruhan persediaan ialah satu CNAME berproksi dalam Cloudflare, domain yang sama disambungkan dalam Shopify, dan satu togol HTTPS yang dibiarkan sahaja. Selebihnya artikel ini menerangkan mengapa setiap langkah penting dan cara mengesahkan ia bertahan, tetapi inilah keseluruhan konfigurasinya.

Lebih suka menonton: Field Notes: Cloudflare in front of Shopify merangkumi perkara yang sama dalam tiga minit, lengkap dengan transkrip penuh pada halaman itu.

Langkah 1 dalam papan pemuka Cloudflare: kedua-dua rekod ialah CNAME kepada shops.myshopify.com dengan status Proxy Proxied.

Nilai clawmart.digital yang ditunjukkan sepanjang artikel ini datang daripada kedai ujian langsung yang kami jalankan pada instans Shopify yang berfungsi sepenuhnya, bukan mockup. Setiap tangkapan skrin, rekod, dan ujian di bawah datang daripada kedai tersebut.

Amaran pada Kedai yang Berfungsi

Domain Shopify anda dipaparkan sebagai tersambung, checkout berfungsi, dan mangga SSL ada di tempatnya. Betul-betul di bawah status hijau itu terletak amaran kuning bahawa domain anda mempunyai proksi Cloudflare, yang tidak disokong oleh Shopify. Kedua-duanya benar pada masa yang sama, dan percanggahan itulah yang membuatkan kebanyakan peniaga tersekat.

Ini salah satu mesej paling mengelirukan dalam infrastruktur ecommerce, kerana ia tidak salah dan tidak juga betul sepenuhnya. Selama bertahun-tahun, meletakkan Cloudflare di hadapan Shopify memang idea buruk yang merosakkan kedai dengan cara yang khusus dan boleh diramal. Kemudian Cloudflare menghantar ciri penghalaan yang membetulkan perkara yang rosak itu tepat-tepat, namun Shopify masih memberitahu anda supaya jangan lakukannya. Jurang itu, antara pembetulan yang berkesan dan vendor yang enggan mengesahkannya, di situlah kebimbangan "adakah kedai saya akan rosak" bermula.

Jadi inilah versi praktikalnya: apa yang sebenarnya rosak, apa yang O2O perbaiki, satu tetapan yang masih akan menjatuhkan tapak anda jika anda terlepas pandang, dan cara memutuskan sama ada semua ini sesuai untuk kedai anda.

Mengapa Ia Dahulu Rosak: Dua Awan Jingga

Cloudflare memaparkan domain berproksi sebagai awan jingga. Trafik ke domain itu melalui rangkaian Cloudflare sebelum sampai ke asal anda. Masalahnya pada Shopify ialah Shopify sendiri berjalan di atas Cloudflare. Jadi apabila anda menghalakan domain berawan jingga anda ke Shopify, permintaan itu tiba di Cloudflare dengan dua zon yang kedua-duanya menuntutnya: zon anda, dan zon Shopify. Dua awan jingga, bertindan.

Dari segi sejarah, Cloudflare tidak dapat menentukan dengan pasti zon mana yang patut memiliki permintaan itu, jadi ia akan menyelesaikan ke tempat yang salah atau berpusing. Hasilnya ialah kedai yang separuh berfungsi dan gagal dengan cara yang sukar dihasilkan semula.

Bahagian paling tajam ialah SSL. Shopify menyediakan dan memperbaharui sijil anda melalui Let's Encrypt, dan Let's Encrypt membuktikan anda memiliki domain itu dengan cabaran ACME yang disajikan pada laluan tertentu:

Jika proksi di hadapan Shopify memintas, menyimpan cache, atau mengalihkan laluan itu, cabaran tersebut tidak pernah selesai. Cabaran yang tidak selesai bermakna tiada sijil. Dan kerana sijil diperbaharui mengikut jadual, ini sering gagal secara senyap: kedai berfungsi baik dengan sijil sedia ada selama berminggu-minggu, kemudian menjadi tidak selamat pada hari ia luput. Inilah sebabnya nasihat lama hanyalah satu baris tegas, tukar awan itu kepada kelabu, DNS sahaja, keluarkan proksi Cloudflare daripada laluan.

Apa yang Orange-to-Orange Ubah

Orange-to-Orange, atau O2O, ialah jawapan Cloudflare kepada masalah dua zon, dan ia sebahagian daripada produk bernama Cloudflare for SaaS. Cloudflare membuka produk itu kepada semua pelanggan pada 2021, tersedia secara umum pada Oktober tahun itu, jadi O2O ialah laluan penghalaan yang mantap dengan pengalaman bertahun-tahun, bukan eksperimen baharu. Mekanismenya mudah: apabila zon berproksi anda menghalakan CNAME ke perkhidmatan yang juga pelanggan Cloudflare for SaaS, Cloudflare mengenali sasaran itu dan berhenti menganggap kedua-dua zon sebagai pertembungan. Ia menghalakan permintaan melalui zon anda dahulu dan zon penyedia kedua, dalam urutan yang ditetapkan, dan proksi berganda menjadi satu serah tangan.

Anda tidak perlu percaya begitu sahaja bahawa O2O sudah aktif. Cipta CNAME dengan proksi dihidupkan, dan Cloudflare meletakkan ikon Shopify kecil di sebelah rekod itu. Ikon itulah pengesanan yang mengesahkan ia tahu ke mana trafik itu pergi. Cloudflare juga melakukan kerja penyelenggaraan khusus penyedia di latar belakang, termasuk melumpuhkan Workers dan Snippets pada laluan /checkout, supaya tiada apa yang anda jalankan di edge boleh mengganggu pembayaran.

Anda menambah rekod itu dalam papan pemuka Cloudflare di bawah DNS, kemudian Records. Klik Add record, tetapkan Type kepada CNAME, Target kepada shops.myshopify.com, dan status Proxy kepada Proxied supaya awan itu bertukar jingga. Ikon Shopify muncul di sebelah rekod itu sebaik sahaja Cloudflare mengenali sasaran tersebut sebagai salah satu pelanggan SaaS-nya sendiri.

Mengendalikan Satu Pengecualian: SSL

O2O membetulkan pertembungan penghalaan. Ia tidak membetulkan SSL, kerana SSL sebenarnya tidak pernah menjadi masalah penghalaan. Ia adalah proksi yang menyentuh satu laluan yang digunakan Shopify untuk memperbaharui sijil. Pada kedai yang dipasang dengan betul, hampir semua ini kini berjalan dengan sendirinya, jadi perkara yang berguna ialah mengetahui apa yang automatik, kemudian menyemak senarai pendek yang tidak automatik.

Apa yang kini berlaku secara automatik

Kedai anda membawa dua sijil, dan kedua-duanya diperbaharui tanpa campur tangan anda. Kerana domain itu berproksi, sijil yang dilihat pengunjung ialah sijil edge Cloudflare sendiri, yang disahkan Cloudflare melalui DNS dan diperbaharui dengan sendirinya, jadi laluan ACME langsung tidak menyentuhnya. Di belakangnya, Shopify menyimpan sijil asal yang berasingan untuk laluan Cloudflare ke Shopify, diperbaharui melalui Let's Encrypt, dan mod penyulitan Full anda dibina untuk mempercayainya. Shopify juga menjalankan naik taraf HTTP kepada HTTPS di asalnya sendiri, jadi pengunjung mendarat pada sambungan selamat sama ada Cloudflare berbuat apa-apa atau tidak.

Sijil asal itu diperbaharui melalui ACME, pertukaran automatik yang digunakan Let's Encrypt untuk mengesahkan anda mengawal domain tersebut. Ia meminta apa jua yang menjawab bagi domain anda supaya menyajikan token sekali guna pada laluan di atas, melalui HTTP biasa, dan Shopify mengendalikan keseluruhan pertukaran itu di latar belakang. Itulah sebabnya anda tidak pernah memikirkannya. Persediaan ini kekal sihat selagi satu laluan itu kekal boleh dicapai.

Satu perkara yang merosakkannya

Semua pembaharuan automatik itu bergantung pada satu tetapan Cloudflare yang kekal dimatikan, dan ia dihidupkan secara lalai dalam banyak persediaan.

Jadi pembetulannya sebahagian besarnya hanyalah tidak menghidupkan togol itu, dan membiarkan pengalihan asal Shopify melakukan naik taraf yang memang sudah dilakukannya. Jika anda mahu Cloudflare turut menguatkuasakan HTTPS di edge-nya sendiri, gunakan peraturan pengalihan yang melangkau laluan cabaran, jangan sekali-kali Always Use HTTPS.

Apa yang perlu disemak

Semua yang di bawah ini terletak dalam papan pemuka Cloudflare. Log masuk di dash.cloudflare.com, pilih akaun anda, dan klik domain untuk membuka zonnya. Setiap item ialah satu laluan dalam bar sisi kiri zon tersebut.

Satu jiran pada halaman Edge Certificates itu sering mengelirukan orang: Automatic HTTPS Rewrites selamat dibiarkan hidup. Ia hanya menulis semula pautan sumber http kepada https untuk mengelakkan amaran kandungan bercampur, yang langsung berbeza daripada Always Use HTTPS yang memaksa pengalihan seluruh halaman. Opportunistic Encryption dan TLS 1.3 juga boleh kekal hidup. Always Use HTTPS ialah satu-satunya togol pada skrin itu yang perlu kekal dimatikan.

Kemudian sahkan dari luar, tanpa menunggu pembaharuan gagal. Minta laluan cabaran itu melalui HTTP biasa dan baca responsnya:

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

Sampai ke Shopify itulah kemenangannya, dan 404 untuk token rekaan itu memang tepat. Pengalihan 301 atau 308 ke HTTPS bermakna Always Use HTTPS atau peraturan menyeluruh masih menelan laluan tersebut. Selepas itu, semak status SSL di bawah Settings → Domains dalam admin Shopify anda, dan sepanjang minggu-minggu berikutnya perhatikan tarikh luput sijil asal bergerak ke hadapan dengan sendirinya. Sijil yang diperbaharui tanpa disentuh ialah isyarat bahawa persediaan itu bertahan.

Jalankan ujian itu semula selepas sebarang perubahan pada DNS atau tetapan Cloudflare anda, bukan hanya semasa persediaan. Pengguna Shopify Community, Hardeep, membangkitkan perkara ini dalam utas tentang artikel ini, dan ia sepadan dengan cara persediaan seperti ini sebenarnya gagal. Konfigurasinya betul pada hari pertama, seseorang menyunting satu peraturan atau satu rekod beberapa bulan kemudian, dan tiada siapa menyemak semula laluan cabaran itu sehinggalah sesuatu sijil senyap-senyap tidak diperbaharui.

Satu perangkap wajar dinyatakan dengan jelas: sijil yang dipaparkan sebagai telah disediakan hari ini hanya memberitahu anda bahawa sijil semasa telah dikeluarkan, bukan bahawa pembaharuan seterusnya akan berjaya. Sijil Let's Encrypt diperbaharui dalam kitaran kira-kira enam puluh hingga sembilan puluh hari, jadi kedai yang kelihatan sihat sepenuhnya mungkin hanya belum sampai ke tarikh pembaharuannya. Itu, ditambah hakikat bahawa banyak kedai memang tidak pernah menghidupkan Always Use HTTPS sejak awal, itulah sebabnya ramai menjalankannya selama berbulan-bulan tanpa masalah, dan sebab kegagalan itu, apabila ia datang, terasa mengelirukan. Tiada apa yang berubah, kecuali sijil yang senyap-senyap tidak diperbaharui.

Berikan ia berat yang wajar. Ini insurans murah terhadap kegagalan yang jarang tetapi senyap, bukan tanda kedai anda hampir rosak. Lakukan konfigurasi dua minit itu, jalankan ujiannya, dan anda telah menutup satu-satunya jurang masa pembaharuan yang memang sukar disedari.

Shopify Masih Tidak Akan Meluluskan Ini, Kerana…

Dokumentasi Shopify tidak lagi bercakap secara kabur tentang "proksi" secara umum. Ia menyebut O2O secara langsung:

"Persediaan proksi Cloudflare, termasuk O2O, tidak disokong oleh Shopify. Walaupun kedai anda mungkin kelihatan berfungsi dengan betul, persediaan ini boleh rosak pada bila-bila masa."

Itu bukan amaran lapuk tentang masalah yang sudah selesai. Ia pendirian semasa yang disengajakan, dan dua daripada sebab di sebaliknya masih kukuh walaupun selepas O2O:

Dokumentasi Shopify menambah sebab ketiga, pengesanan bot, dengan hujah bahawa trafik melalui Cloudflare sampai kepadanya dengan atribut permintaan yang telah diubah. Dalam praktiknya itulah yang paling lemah antara ketiga-tiganya: Cloudflare menjalankan salah satu rangkaian pengurusan bot terbesar yang ada, jadi kebanyakan kedai memperoleh jauh lebih banyak penapisan bot di edge berbanding isyarat yang hilang pada Shopify. Ia satu-satunya item dalam senarai Shopify di mana proksi lebih berkemungkinan membantu daripada memudaratkan.

Adakah Amaran Itu Keterlaluan?

Sedikit, dan itu boleh difahami. Papan pemuka menandakan kedai yang berfungsi dan tersambung dengan "Issue" kuning serta frasa mendatar "not supported", yang terasa jauh lebih berat daripada mod kegagalan sebenar, yang kebanyakannya boleh dielakkan dengan konfigurasi yang betul. Peniaga membaca "Issue" dan mendengar "kedai saya hampir rosak", sedangkan maksud Shopify lebih hampir kepada "kami tidak akan menjamin ini".

Tetapi "tidak disokong" bukan "tidak berfungsi", dan perbezaan itu penting. Ia bermakna Shopify tidak akan menjamin, menyahpepijat, atau memikul tanggungjawab bagi tingkah laku dalam lapisan yang tidak mereka kawal. Bagi platform yang memiliki checkout dan masa operasi anda, itu garisan yang munasabah, walaupun sepanduk itu melukisnya dengan tegas. Bendera itu memberitahu anda Shopify tidak akan menyokong persediaan tersebut. Ia tidak memberitahu anda persediaan itu sedang gagal.

Ramai Kedai Shopify Menjalankan Ini

Anda tidak perlu mempercayai kata-kata satu kedai ujian sahaja. Proksi Cloudflare di hadapan Shopify bukan konfigurasi pinggiran: banyak jenama mapan menjalankannya dalam produksi, setiap hari. Nama-nama di bawah ialah contoh langsung yang kami sahkan secara manual, setiap satunya kini menyajikan kedainya melalui proksi Cloudflare dengan Shopify di belakangnya.

Disahkan pada Julai 2026 dengan meminta setiap domain dan mengesahkan respons proksi Cloudflare bersama penanda kedai Shopify. Persediaan sesebuah kedai boleh berubah pada bila-bila masa, jadi anggap ini sebagai gambaran seketika, bukan sokongan daripada jenama yang disenaraikan.

Apa yang Edge Beri Anda tetapi Shopify Tidak

Shopify sudah menyertakan CDN, sijil SSL, dan perlindungan DDoS pada setiap pelan, seperti yang turut ditegaskan Hardeep dalam utas komuniti itu. Proksi itu bukan yang menjadikan kedai anda pantas, disulitkan, atau mampu menyerap banjir trafik, dan jika itu yang anda cari, anda sudah pun memilikinya. Apa yang menyusul ialah set perkara yang lebih sempit yang tidak diberikan Shopify kepada anda.

Sebab untuk menerima pertukaran ini bukan proksi itu sendiri. Ia adalah lapisan yang diletakkan proksi itu di hadapan kedai anda, satu edge boleh atur cara yang tidak didedahkan Shopify kepada anda. Tiga keupayaan paling penting, dan yang ketiga ialah sesuatu yang kebanyakan kedai langsung tidak nampak.

Tiada satu pun daripada itu disertakan dengan pelan Shopify, kerana tiada satu pun daripadanya berada di dalam Shopify. Ia berada satu hop lebih awal, di edge, dan itulah sebab utama seorang peniaga sanggup menanggung proksi yang tidak disokong.

Satu peringatan: caching di edge tidak automatik. Cloudflare boleh menyimpan fail statik seperti helaian gaya dan imej di edge-nya dan menyajikannya daripada pelayan berdekatan dan bukan mengambilnya daripada Shopify pada setiap lawatan, tetapi kedai Shopify berproksi tidak melakukan caching dengan sendirinya, dan peraturan cache lalai atau yang salah skop boleh menyekatnya sepenuhnya, sehingga fail yang ditanda boleh dicache selama setahun dihantar terus tanpa disentuh. Rangkaian Shopify sendiri mengekalkan kelajuan kedai tanpa mengira itu, jadi anggap caching di edge sebagai bonus kelajuan yang anda pilih untuk aktifkan. Anda mengesahkan mod penyulitan yang menghalang masalah SSL lama itu dalam konfigurasi SSL/TLS, skrin yang sama dengan butang Configure yang dibincangkan tadi; caching pula ditetapkan di kawasannya sendiri, jadi berbaloi menyemak kedua-duanya semasa anda berada dalam papan pemuka, kerana caching ialah tetapan yang paling mungkin membiarkan kelajuan terbiar.

Apa yang Pembangun Akan Ingatkan Anda

Pembangun yang baik tidak akan meluluskan ini tanpa soalan, dan soalan-soalan itu wajar. Tiada satu pun daripadanya menjadi sebab untuk mengelak persediaan ini, tetapi setiap satunya wajar disahkan pada kedai anda sendiri dan bukan diterima begitu sahaja. Itu bukan kerja tambahan: ia ujian yang sama yang anda akan jalankan selepas sebarang perubahan infrastruktur, dan ia sebahagian daripada menjaga kesihatan kedai. Kami menguji kedua-dua perkara berikut pada kedai yang kami jalankan, dan anda juga patut melakukannya.

Latensi pada serah tangan

Soalan pertama ialah kelajuan: adakah penghalaan melalui zon Cloudflare anda sebelum zon Shopify sendiri menambah masa yang ketara? Sepatutnya tidak, kerana kedua-dua zon sudah berada pada rangkaian Cloudflare yang sama, jadi serah tangan itu berlaku di dalam rangkaian tersebut dan bukan keluar ke internet terbuka. Kami mengukurnya pada clawmart.digital, kedai ujian berproksi itu, berbanding endpoint Shopify myshopify.com mentah daripada mesin yang sama. Kedai berproksi menjawab di edge dalam lingkungan 150 hingga 200 milisaat, jalur yang sama dengan endpoint Shopify tidak berproksi di sebelahnya. Hop tambahan itu hilang dalam variasi biasa antara larian.

Apabila kedai Shopify berproksi memang terasa perlahan, puncanya hampir selalu tema yang berat atau aplikasi pihak ketiga yang perlahan, bukan proksi. Ukur dahulu sebelum menyalahkan edge. Masa ke bait pertama, dijalankan beberapa kali dari satu lokasi, ialah bacaan terpantas:

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

Bandingkan itu dengan garis dasar awan kelabu (DNS sahaja), atau dengan alamat myshopify.com anda, atau larian WebPageTest. Perbezaan beberapa milisaat bermakna proksi bukan penghalang anda. Ratusan milisaat bermakna tema dan tindanan aplikasi itulah puncanya, dan di situlah masa patut dibelanjakan: memangkas tema, membuang aplikasi yang anda tidak lagi guna, dan membetulkan cara imej dimuatkan akan menggerakkan nombor itu jauh lebih banyak daripada apa-apa yang anda konfigurasikan di edge.

Aplikasi dalam checkout

Soalan kedua ialah checkout: adakah proksi itu akan mengganggu aplikasi checkout extensibility, pembayaran, atau skrip yang berjalan pada langkah paling penting? Mengikut reka bentuknya, ia sepatutnya tidak. Penghalaan O2O Cloudflare melumpuhkan Workers dan Snippets pada laluan /checkout secara khusus supaya tiada apa yang anda jalankan di edge boleh menyentuh pembayaran. Dalam ujian kami, tiada satu pun aplikasi checkout extensibility popular yang berkelakuan pelik di sebalik persediaan ini. Itu pengalaman kami, bukan jaminan untuk setiap aplikasi di pasaran, jadi sentiasa jalankan checkout penuh sendiri.

Buat pesanan sebenar dengan aplikasi anda aktif: sahkan diskaun, logik penghantaran, upsell, dan sebarang sambungan pasca pembelian berfungsi seperti biasa tanpa proksi, dan pesanan itu masuk ke Shopify dengan atribut yang anda jangkakan. Jika sesebuah aplikasi akan berkelakuan pelik, ia akan muncul di sini, pada pesanan ujian anda, jauh sebelum pelanggan menemuinya.

Adakah Ciri Shopify Anda Masih Berfungsi?

Inilah soalan yang ditanya peniaga sejurus sebelum mereka berundur: jika Cloudflare berada di hadapan, adakah perkara yang saya urus di dalam Shopify masih berkelakuan seperti biasa? Yang paling menimbulkan kebimbangan ialah pengalihan URL, kerana ia diurus dalam admin Shopify, ia penting untuk SEO, dan tidak jelas sama ada proksi di hadapan akan menyimpan cache, menulis semula, atau menelannya.

Jadi kami mengujinya pada kedai berproksi itu dan bukan sekadar membuat andaian. Kami mencipta satu 301 dalam admin Shopify daripada /pages/redirect-test-20260727 ke halaman utama, mengesahkan laluan itu mengembalikan 404 sebelumnya supaya tiada apa-apa yang sebenar terjejas, memeriksanya dari beberapa sudut, kemudian memadamkannya.

Jawapan khusus Cloudflare ada pada baris terakhir itu. Ia menghantar pengalihan terus tanpa pernah menyimpannya dalam cache, jadi logik pengalihan anda kekal sepenuhnya di bawah kawalan Shopify. Itu bukan nasib pula: Shopify menghantar cache-control: private, no-store pada 301 itu sendiri, jadi Cloudflare tidak akan menyimpannya dalam cache walaupun anda memintanya. Rentetan pertanyaan kekal, apex berfungsi, dan HTTP biasa berfungsi.

Satu butiran daripada proses pembersihan wajar diketahui, kerana ia kelihatan seperti masalah Cloudflare sedangkan bukan. Selepas kami memadamkan pengalihan itu, URL kosong terus menyajikan 301 lama selama kira-kira tiga puluh saat sementara versi URL yang sama dengan pemecah cache sudah mengembalikan 404. Itu satu nod edge Shopify yang menyimpan salinan basi, bukan Cloudflare: cf-cache-status kekal DYNAMIC sepanjang masa dan varian rentetan pertanyaan betul serta-merta. Ia selesai dengan sendirinya. Jadi selepas mengubah atau membuang pengalihan, beri ia seminit sebelum membuat kesimpulan bahawa ia tidak berjaya, dan uji dengan pemecah cache jika anda tidak pasti.

Ini juga berkait semula dengan peringatan caching tadi, dan ia berfungsi dua hala. Dengan caching di edge dimatikan, perubahan pengalihan berkuat kuasa serta-merta, satu kelebihan yang tidak disengajakan. Jika anda kemudian menghidupkan caching HTML di edge, pengalihan juga boleh disimpan dalam cache di situ dan suntingan anda akan berhenti muncul serta-merta. Jika anda mengambil laluan itu, kecualikan laluan pengalihan daripada peraturan cache atau bina langkah purge ke dalam apa jua alat yang anda guna untuk mengurus pengalihan secara pukal.

Menyediakannya Sebelum Kedai Dibuka kepada Umum

Anda tidak memerlukan kedai yang sudah dilancarkan untuk mengkonfigurasi dan menguji semua ini. Selalunya lebih bijak melakukannya semasa kedai masih peribadi, supaya pengesanan O2O, penyediaan SSL, dan ujian checkout semuanya berlaku di tempat yang tiada pelanggan boleh tersasar masuk ke persediaan separuh siap. Satu-satunya syarat ialah pelan Shopify berbayar, kerana domain tersuai tidak tersedia pada percubaan percuma. Anda tidak perlu melancarkan kedai itu pun: pelan berbayar yang disimpan di sebalik halaman kata laluannya sudah memadai untuk persediaan ini. Jika anda menggunakan kedai pembangunan Partner percuma, yang mengehadkan domain tersuai, pindahkannya ke pelan berbayar dahulu, kemudian ikut langkah yang sama.

Jadi Patutkah Anda Menjalankannya?

Tukarkan ia daripada soalan ya-atau-tidak kepada keputusan tentang apa yang anda perlukan di edge, kerana itu sahaja yang mewajarkan pertukaran ini.

Pengguna Shopify Community, Steve_TopNewYork dan sophia24, kedua-duanya menyentuh sebab ketiga itu dalam utas yang sama, dan itulah kos yang sering dipandang rendah oleh peniaga. Proksi jarang menjadi punca kerosakan, tetapi setelah ia berada dalam laluan, ia menjadi satu lagi lapisan yang perlu anda singkirkan pada pukul dua pagi apabila checkout berkelakuan pelik dan anda belum tahu sebabnya. Itu cukai yang nyata ke atas pasukan kecil, dan ia hanya berbaloi dibayar untuk ciri yang anda boleh namakan.

Jika anda memang menjalankannya, anggap senarai semak ini tidak boleh dirunding: CNAME berproksi ke shops.myshopify.com, sahkan ikon Shopify muncul, biarkan Always Use HTTPS dimatikan, kecualikan laluan ACME daripada pengalihan HTTPS anda, dan semak tarikh pembaharuan sijil seperti anda menyemak sama ada sandaran benar-benar berjalan. Dikonfigurasi begitu, banyak kedai menjalankan Cloudflare di hadapan Shopify tanpa masalah. Langkau langkah-langkah itu, dan anda telah menyediakan tepat-tepat kerosakan senyap yang cuba dihalang oleh amaran tersebut.

Versi ringkas, dalam bentuk video: Field Notes: Cloudflare in front of Shopify menerangkan apa yang O2O perbaiki dan dua perkara yang ditunjukkan perkhidmatan edge kepada anda tetapi tidak oleh Shopify.

Soalan Lazim

Adakah selamat meletakkan Cloudflare di hadapan kedai Shopify?

Ia jauh lebih berdaya maju berbanding dahulu, tetapi Shopify tidak menyokongnya secara rasmi, jadi ia satu pilihan yang dikira dan bukan pilihan bebas risiko. Masalah penghalaan yang dahulu merosakkan kedai, iaitu dua zon Cloudflare bertembung, telah diselesaikan oleh ciri Orange-to-Orange (O2O) Cloudflare. Dikonfigurasi dengan betul, bermakna CNAME berproksi ke shops.myshopify.com, Always Use HTTPS dimatikan, dan laluan cabaran ACME dikecualikan daripada sebarang pengalihan HTTPS, banyak kedai menjalankannya dengan stabil. Dokumentasi Shopify sendiri masih menyatakan bahawa persediaan proksi Cloudflare termasuk O2O tidak disokong dan boleh rosak pada bila-bila masa, kerana mereka tidak dapat menjamin tingkah laku dalam lapisan proksi yang tidak mereka kawal. Ringkasan jujurnya: kukuh dari segi teknikal apabila dipasang dengan betul, tidak disokong secara rasmi, dan paling sesuai untuk kedai yang memerlukan sesuatu di edge yang tidak disediakan Shopify.

Apakah itu Orange-to-Orange (O2O)?

Orange-to-Orange ialah ciri penghalaan Cloudflare untuk keadaan apabila seorang pelanggan Cloudflare menghalakan domain berproksinya ke perkhidmatan yang juga merupakan pelanggan Cloudflare. Proksi Cloudflare dipaparkan sebagai awan jingga dalam papan pemuka, jadi dua zon Cloudflare yang bertindan ialah orange-to-orange. Shopify ialah pelanggan Cloudflare for SaaS, jadi kedai Shopify ialah kes ini tepat-tepat. Sebelum O2O, Cloudflare tidak dapat menentukan dengan pasti zon mana yang patut memiliki permintaan itu dan kedua-duanya akan bertembung. O2O mengesan bahawa sasaran CNAME itu milik pelanggan Cloudflare yang lain dan menghalakan permintaan melalui zon anda dahulu dan zon penyedia kedua, mengikut urutan. Anda boleh mengesahkan ia berfungsi apabila ikon Shopify kecil muncul di sebelah rekod CNAME dalam papan pemuka Cloudflare anda.

Mengapa Shopify mengatakan Cloudflare tidak disokong?

Dokumentasi Shopify memberikan tiga sebab utama. Dua daripadanya kukuh. Pertama, SSL: Shopify mengeluarkan dan memperbaharui sijil melalui Let’s Encrypt menggunakan cabaran HTTP ACME, dan sebarang proksi di hadapan ialah satu lagi perkara yang boleh mengganggu pengesahan itu. Kedua, tindak balas insiden: apabila infrastruktur Shopify sendiri bermasalah, proksi tambahan di hadapan kedai menyukarkan Shopify mengalihkan laluan mengelilingi isu tersebut, yang menaikkan pendedahan anda kepada gangguan dan bukan menurunkannya. Yang ketiga, pengesanan bot, lebih lemah: Shopify berhujah bahawa trafik melalui Cloudflare tiba dengan atribut permintaan yang telah diubah, tetapi Cloudflare menjalankan salah satu rangkaian pengurusan bot terbesar di dunia, jadi kebanyakan kedai memperoleh lebih banyak penapisan bot di edge berbanding isyarat yang hilang pada Shopify. Tiada satu pun daripada ini bermakna persediaan itu tidak boleh berfungsi. Ia bermakna Shopify tidak akan memikul tanggungjawab bagi tingkah laku dalam lapisan yang bukan milik mereka.

Mengapa sijil SSL Shopify saya gagal di sebalik Cloudflare?

Hampir selalunya kerana tetapan Always Use HTTPS. Shopify mengesahkan pemilikan domain dan memperbaharui sijil SSL dengan menjawab cabaran yang disajikan pada laluan /.well-known/acme-challenge/. Always Use HTTPS memaksa pengalihan pada setiap permintaan, termasuk laluan itu, jadi cabaran tersebut tidak pernah selesai dan sijil tidak dapat dikeluarkan atau diperbaharui. Kedai terus berfungsi dengan sijil sedia ada sehingga ia luput, kemudian domain itu menjadi tidak selamat atau berhenti bersambung. Pembetulan yang didokumenkan Cloudflare ialah membiarkan Always Use HTTPS dimatikan dan sebaliknya mencipta peraturan pengalihan yang memaksa HTTPS untuk semua perkara kecuali laluan /.well-known/acme-challenge/.

Perlukah saya menetapkan peringatan kalendar untuk menyemak pembaharuan SSL supaya kedai saya tidak rosak?

Tidak, bukan jika ia dikonfigurasi dengan betul. Pembaharuan itu direka untuk berjalan dengan sendirinya. Sijil yang sebenarnya dilihat pengunjung anda ialah sijil edge Cloudflare sendiri, yang disahkan Cloudflare melalui DNS dan diperbaharui secara automatik, jadi ia langsung tidak bergantung pada laluan cabaran ACME. Di belakangnya, sijil asal Shopify diperbaharui melalui Let’s Encrypt di latar belakang, dan itu terus berfungsi selagi Always Use HTTPS dimatikan dan laluan /.well-known/acme-challenge/ tidak dialihkan. Jalankan ujian curl sekali sahaja selepas persediaan untuk mengesahkan laluan itu mengembalikan 404 dan bukan pengalihan, dan pembaharuan automatik itu sudah ada apa yang diperlukannya. Jika anda mahukan jaring keselamatan, alat yang betul bukanlah peringatan kalendar manual yang perlu anda tindak lanjuti, tetapi pemantau luput SSL automatik yang menghantar e-mel kepada anda jika sijil itu menghampiri tarikh luput dalam masa dua minggu. Dengan cara itu tiada apa-apa yang bergantung pada ingatan anda terhadap sesuatu tarikh.

Bagaimanakah saya akan tahu sebelum masalah sijil menjatuhkan kedai?

Sediakan pemantauan supaya anda diberitahu, dan bukan mengetahuinya daripada pelanggan. Pemantau SSL dan masa operasi percuma seperti UptimeRobot, Better Uptime, atau perkhidmatan serupa boleh memerhatikan domain itu dan memberi amaran beberapa hari sebelum sijil luput atau pada saat HTTPS mula gagal. Cloudflare sendiri juga boleh menghantar pemberitahuan bagi isu sijil dan asal daripada bahagian Notifications dalam papan pemuka. Dengan salah satu daripadanya, kegagalan pembaharuan senyap yang menjadi satu-satunya risiko sebenar persediaan ini tidak lagi senyap: anda menerima e-mel dengan masa persiapan berminggu-minggu, jauh sebelum mangga itu rosak untuk pembeli.

Adakah pengalihan URL Shopify masih berfungsi di sebalik proksi Cloudflare?

Ya. Kami mengujinya dari hujung ke hujung pada kedai berproksi: satu 301 yang dicipta dalam admin Shopify berkuat kuasa serta-merta tanpa menunggu perambatan, mengembalikan 301 dan pengepala location yang betul, diikuti sehingga 200 pada sasaran dalam satu hop, mengekalkan rentetan pertanyaan seperti ?utm_source=test, dan berfungsi daripada domain apex serta melalui HTTP biasa. Cloudflare menghantar pengalihan itu terus tanpa pernah menyimpannya dalam cache, dengan melaporkan cf-cache-status: DYNAMIC pada setiap permintaan, jadi logik pengalihan anda kekal sepenuhnya di bawah kawalan Shopify. Shopify juga menghantar cache-control: private, no-store pada 301 itu sendiri, jadi Cloudflare tidak akan menyimpannya dalam cache walaupun anda mengkonfigurasinya begitu. Satu peringatan: selepas mengubah atau memadamkan pengalihan, satu nod edge Shopify boleh menyajikan salinan basi selama kira-kira tiga puluh saat, jadi beri ia seminit dan uji dengan pemecah cache sebelum membuat kesimpulan bahawa ia tidak berjaya. Jika anda kemudian menghidupkan caching HTML di edge Cloudflare, kecualikan laluan pengalihan atau tambah langkah purge, kerana pengalihan juga boleh disimpan dalam cache di situ.

Bolehkah saya menyediakan Cloudflare pada kedai Shopify yang belum dibuka kepada umum?

Boleh, dan selalunya itulah cara yang bijak. Anda tidak memerlukan kedai yang sudah dilancarkan, cuma pelan Shopify berbayar, kerana domain tersuai tidak tersedia pada percubaan percuma. Kekalkan kedai di sebalik halaman kata laluannya di bawah Online Store kemudian Preferences, cipta CNAME berproksi yang sama ke shops.myshopify.com dalam Cloudflare menggunakan hos yang tidak anda sajikan dalam produksi, seperti subdomain staging, dan sambungkan hos itu dalam Shopify di bawah Settings kemudian Domains. Shopify menyediakan SSL dan papan pemuka Cloudflare memaparkan ikon Shopify sebaik sahaja Orange-to-Orange aktif, sementara orang awam hanya melihat halaman kata laluan. Jalankan ujian curl ACME dan checkout ujian penuh dengan aplikasi anda aktif, dan apabila semuanya lulus, buang kata laluan dan tetapkan domain sebenar anda sebagai utama. Anda melancarkan ke konfigurasi yang sudah anda buktikan. Jika anda menggunakan kedai pembangunan Partner percuma, yang mengehadkan domain tersuai, pindahkannya ke pelan berbayar dahulu.