Shopify के आगे Cloudflare लगाना अब ज़्यादा सुरक्षित है: O2O ने क्या ठीक किया, और चेतावनियों का अब भी क्या मतलब है।

क्विक स्टार्ट: अपने स्टोर पर यह करें

अगर आप सीधे स्टेप्स के लिए आए हैं, तो वे यहाँ हैं। पूरा सेटअप इतना ही है: Cloudflare में एक proxied CNAME, वही डोमेन Shopify में कनेक्ट किया हुआ, और एक HTTPS टॉगल जिसे छूना नहीं है। बाक़ी लेख यह समझाता है कि हर स्टेप क्यों मायने रखता है और यह कैसे पक्का करें कि वह टिका हुआ है, लेकिन कॉन्फ़िगरेशन बस इतना ही है।

देखना पसंद करेंगे: Field Notes: Cloudflare in front of Shopify इसी विषय को तीन मिनट में कवर करता है, पेज पर पूरे ट्रांसक्रिप्ट के साथ।

Cloudflare डैशबोर्ड में स्टेप 1: दोनों रिकॉर्ड shops.myshopify.com की ओर CNAME हैं, Proxy status Proxied के साथ।

इस लेख में दिखाई गई clawmart.digital वैल्यू एक लाइव टेस्ट स्टोर से हैं जिसे हम पूरी तरह काम करने वाले Shopify इंस्टेंस पर चलाते हैं, यह कोई मॉकअप नहीं है। नीचे दिया हर स्क्रीनशॉट, रिकॉर्ड और टेस्ट उसी स्टोर से आया है।

एक चालू स्टोर पर दिखती चेतावनी

आपका Shopify डोमेन connected दिखता है, checkout काम करता है, और SSL का ताला भी लगा है। उसी हरे स्टेटस के ठीक नीचे एक अंबर रंग की चेतावनी बैठी है कि आपके डोमेन पर Cloudflare proxy है, जिसे Shopify सपोर्ट नहीं करता। दोनों बातें एक ही समय पर सच हैं, और यही विरोधाभास वह जगह है जहाँ ज़्यादातर मर्चेंट अटक जाते हैं।

यह ecommerce इन्फ़्रास्ट्रक्चर के सबसे उलझाऊ संदेशों में से एक है, क्योंकि यह न तो ग़लत है और न ही पूरी तरह सही। सालों तक, Shopify के आगे Cloudflare लगाना सचमुच एक बुरा विचार था जो स्टोर को एक ख़ास, अनुमानित तरीक़े से तोड़ देता था। फिर Cloudflare ने एक रूटिंग फ़ीचर जारी किया जिसने ठीक वही चीज़ ठीक कर दी जो टूटती थी, और फिर भी Shopify आपसे कहता है कि ऐसा न करें। यही फ़ासला, एक काम करते समाधान और उसे मान्यता न देने वाले वेंडर के बीच, वह जगह है जहाँ "क्या मेरा स्टोर टूटने वाला है" वाली चिंता रहती है।

तो यह रहा व्यावहारिक संस्करण: असल में क्या टूटता था, O2O ने क्या ठीक किया, वह एक सेटिंग जो चूक जाने पर अब भी आपकी साइट गिरा सकती है, और यह कैसे तय करें कि इसमें से कुछ आपके स्टोर के लिए है भी या नहीं।

पहले यह क्यों टूटता था: दो नारंगी बादल

Cloudflare एक proxied डोमेन को नारंगी बादल के रूप में दिखाता है। उस डोमेन का ट्रैफ़िक आपके origin तक पहुँचने से पहले Cloudflare के नेटवर्क से होकर गुज़रता है। Shopify पर पेच यह है कि Shopify ख़ुद Cloudflare पर चलता है। तो जब आप अपने नारंगी बादल वाले डोमेन को Shopify की ओर पॉइंट करते हैं, तो रिक्वेस्ट Cloudflare पर ऐसे दो zones के साथ पहुँचती है जो दोनों उस पर दावा करते हैं: आपका, और Shopify का। दो नारंगी बादल, एक के ऊपर एक।

पहले Cloudflare भरोसे के साथ यह तय नहीं कर पाता था कि उस रिक्वेस्ट का मालिक कौन सा zone है, इसलिए वह ग़लत जगह resolve हो जाती या लूप में फँस जाती। नतीजा एक ऐसा स्टोर होता जो आधा काम करता और ऐसे तरीक़ों से फेल होता जिन्हें दोबारा पैदा करना मुश्किल था।

सबसे तीखा किनारा SSL था। Shopify आपका सर्टिफ़िकेट Let's Encrypt के ज़रिए जारी और रिन्यू करता है, और Let's Encrypt यह साबित करता है कि डोमेन आपका है, एक ACME challenge के ज़रिए जो एक ख़ास पाथ पर सर्व होता है:

अगर Shopify के आगे बैठा कोई proxy उस पाथ को इंटरसेप्ट, कैश या रीडायरेक्ट करता है, तो challenge कभी पूरा नहीं होता। challenge पूरा न होने का मतलब है कोई सर्टिफ़िकेट नहीं। और चूँकि सर्टिफ़िकेट एक तय समय पर रिन्यू होते हैं, यह अक्सर चुपचाप फेल होता था: स्टोर हफ़्तों तक मौजूदा सर्टिफ़िकेट पर ठीक चलता, फिर जिस दिन वह ख़त्म होता उसी दिन insecure हो जाता। यही वजह है कि पुरानी सलाह एक ही दो-टूक लाइन थी: बादल को धूसर कर दो, DNS only, Cloudflare के proxy को रास्ते से हटा दो।

Orange-to-Orange ने क्या बदला

Orange-to-Orange, या O2O, दो zones वाली समस्या का Cloudflare का जवाब है, और यह Cloudflare for SaaS नाम के प्रोडक्ट का हिस्सा है। Cloudflare ने वह प्रोडक्ट 2021 में हर ग्राहक के लिए खोला, उसी अक्टूबर में आम तौर पर उपलब्ध, इसलिए O2O सालों का अनुभव रखने वाला एक जमा-जमाया रूटिंग पाथ है, कोई हालिया प्रयोग नहीं। तंत्र सीधा है: जब आपका proxied zone किसी ऐसी सेवा की ओर CNAME पॉइंट करता है जो ख़ुद भी Cloudflare for SaaS की ग्राहक है, तो Cloudflare टारगेट को पहचान लेता है और दोनों zones को टकराव की तरह देखना बंद कर देता है। वह रिक्वेस्ट को पहले आपके zone से और फिर प्रोवाइडर के zone से, एक तय क्रम में भेजता है, और दोहरा proxy एक handoff बन जाता है।

आपको भरोसे पर नहीं छोड़ना पड़ता कि O2O सक्रिय हुआ या नहीं। proxy चालू रखकर CNAME बनाइए, और Cloudflare रिकॉर्ड के बग़ल में एक छोटा Shopify आइकन लगा देता है। वह आइकन इस बात की पुष्टि है कि उसे पता है ट्रैफ़िक कहाँ जा रहा है। Cloudflare पर्दे के पीछे प्रोवाइडर-विशिष्ट रखरखाव भी करता है, जिसमें /checkout पाथ पर Workers और Snippets को बंद करना शामिल है, ताकि एज पर आपका चलाया कुछ भी पेमेंट में दख़ल न दे सके।

वह रिकॉर्ड आप Cloudflare डैशबोर्ड में DNS, फिर Records के अंतर्गत जोड़ते हैं। Add record पर क्लिक करें, Type को CNAME, Target को shops.myshopify.com, और Proxy status को Proxied पर सेट करें ताकि बादल नारंगी हो जाए। जैसे ही Cloudflare टारगेट को अपने ही SaaS ग्राहकों में से एक के रूप में पहचानता है, रिकॉर्ड के बग़ल में Shopify आइकन दिख जाता है।

एकमात्र अपवाद को संभालना: SSL

O2O ने रूटिंग का टकराव ठीक किया। उसने SSL ठीक नहीं किया, क्योंकि SSL असल में कभी रूटिंग की समस्या थी ही नहीं। वह एक proxy का उस इकलौते पाथ को छूना था जिससे Shopify सर्टिफ़िकेट रिन्यू करता है। सही तरह सेटअप किए गए स्टोर पर अब इसमें से लगभग सब कुछ अपने आप चलता है, इसलिए काम की बात यह जानना है कि क्या ऑटोमैटिक है, फिर उस छोटी सूची को जाँचना जो नहीं है।

अब क्या अपने आप होता है

आपका स्टोर दो सर्टिफ़िकेट रखता है, और दोनों आपके बिना रिन्यू होते हैं। चूँकि डोमेन proxied है, विज़िटर को जो सर्टिफ़िकेट दिखता है वह Cloudflare का अपना edge certificate है, जिसे Cloudflare DNS के ज़रिए वैलिडेट करता है और ख़ुद रिन्यू करता है, इसलिए ACME पाथ उसे कभी छूता ही नहीं। उसके पीछे, Shopify Cloudflare-से-Shopify वाले हिस्से के लिए एक अलग origin certificate रखता है, जो Let's Encrypt के ज़रिए रिन्यू होता है, और आपका Full एन्क्रिप्शन मोड उसी पर भरोसा करने के लिए बना है। Shopify अपने origin पर HTTP से HTTPS का अपग्रेड भी ख़ुद करता है, इसलिए विज़िटर सुरक्षित कनेक्शन पर ही उतरते हैं, चाहे Cloudflare कुछ करे या न करे।

वह origin certificate ACME के ज़रिए रिन्यू होता है, यानी वह ऑटोमेटेड आदान-प्रदान जिससे Let's Encrypt पुष्टि करता है कि डोमेन आपके नियंत्रण में है। वह आपके डोमेन का जवाब देने वाली चीज़ से कहता है कि ऊपर दिए गए पाथ पर, सादे HTTP पर, एक बार का टोकन सर्व करे, और Shopify पूरा आदान-प्रदान पर्दे के पीछे संभाल लेता है। इसीलिए आप इसके बारे में कभी सोचते ही नहीं। यह सेटअप ठीक तब तक स्वस्थ रहता है जब तक वह एक पाथ पहुँच योग्य रहता है।

इसे तोड़ने वाली एकमात्र चीज़

वह पूरा ऑटोमैटिक रिन्यूअल Cloudflare की एक सेटिंग के बंद रहने पर टिका है, और कई सेटअप में वह डिफ़ॉल्ट रूप से चालू रहती है।

तो समाधान ज़्यादातर इतना ही है कि उस टॉगल को चालू न करें, और Shopify के origin रीडायरेक्ट को वही अपग्रेड करने दें जो वह पहले से करता है। अगर आप चाहते हैं कि Cloudflare अपने एज पर भी HTTPS लागू करे, तो ऐसा redirect rule इस्तेमाल करें जो challenge पाथ को छोड़ दे, कभी Always Use HTTPS नहीं।

क्या-क्या जाँचना है

नीचे दी हर चीज़ Cloudflare डैशबोर्ड में है। dash.cloudflare.com पर साइन इन करें, अपना अकाउंट चुनें, और उसका zone खोलने के लिए डोमेन पर क्लिक करें। हर आइटम उस zone के बाएँ साइडबार का एक पाथ है।

उसी Edge Certificates पेज पर एक पड़ोसी सेटिंग लोगों को उलझाती है: Automatic HTTPS Rewrites को चालू छोड़ना सुरक्षित है। यह सिर्फ़ http रिसोर्स लिंक्स को https में बदलती है ताकि mixed-content चेतावनियाँ न आएँ, जो Always Use HTTPS के पूरे पेज को रीडायरेक्ट करने जैसा कुछ भी नहीं है। Opportunistic Encryption और TLS 1.3 भी चालू रह सकते हैं। उस स्क्रीन पर Always Use HTTPS ही अकेला टॉगल है जिसका बंद रहना ज़रूरी है।

फिर इसे बाहर से पुष्टि करें, बिना यह इंतज़ार किए कि कोई रिन्यूअल फेल हो। सादे HTTP पर challenge पाथ की रिक्वेस्ट करें और रिस्पॉन्स पढ़ें:

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

Shopify तक पहुँच जाना ही जीत है, और बनावटी टोकन के लिए 404 बिल्कुल सही है। HTTPS पर 301 या 308 रीडायरेक्ट का मतलब है कि Always Use HTTPS या कोई catch-all नियम अब भी उस पाथ को निगल रहा है। उसके बाद, अपने Shopify admin में Settings → Domains के अंतर्गत SSL स्टेटस जाँचें, और आने वाले हफ़्तों में देखें कि origin certificate की समाप्ति तिथि अपने आप आगे बढ़ रही है। बिना छुए रिन्यू होता सर्टिफ़िकेट ही वह संकेत है कि सेटअप टिका हुआ है।

वह टेस्ट अपने DNS या Cloudflare सेटिंग्स में किसी भी बदलाव के बाद दोबारा चलाएँ, सिर्फ़ सेटअप के समय नहीं। Shopify Community के यूज़र Hardeep ने इस लेख पर चली चर्चा में यह बात उठाई, और यह ठीक वैसा ही है जैसे ये सेटअप असल में फेल होते हैं। कॉन्फ़िगरेशन पहले दिन सही था, महीनों बाद किसी ने कोई नियम या रिकॉर्ड बदला, और किसी ने challenge पाथ दोबारा नहीं जाँचा जब तक एक सर्टिफ़िकेट चुपचाप रिन्यू होना बंद नहीं हो गया।

एक जाल का साफ़ नाम लेना ज़रूरी है: आज provisioned दिखता सर्टिफ़िकेट यह बताता है कि मौजूदा वाला जारी हुआ, यह नहीं कि अगला रिन्यूअल भी होगा। Let's Encrypt सर्टिफ़िकेट लगभग साठ से नब्बे दिन के चक्र पर रिन्यू होते हैं, इसलिए पूरी तरह स्वस्थ दिखने वाला स्टोर शायद बस वही हो जो अभी अपनी रिन्यूअल तारीख़ तक पहुँचा ही नहीं। यह, और यह तथ्य कि कई स्टोर ने Always Use HTTPS कभी चालू ही नहीं किया, यही वजह है कि बहुत सारे स्टोर महीनों तक इसे बिना किसी दिक़्क़त के चलाते हैं, और यही वजह है कि जब ख़राबी आती है तो वह उलझाने वाली लगती है। कुछ नहीं बदला, सिवाय एक सर्टिफ़िकेट के जो चुपचाप रिन्यू नहीं हुआ।

इसे सही वज़न दें। यह एक कम होने वाली लेकिन चुपचाप आने वाली ख़राबी के ख़िलाफ़ सस्ता बीमा है, इस बात का संकेत नहीं कि आपका स्टोर टूटने वाला है। दो मिनट का कॉन्फ़िगरेशन करें, टेस्ट चलाएँ, और आपने वह इकलौता रिन्यूअल-समय का छेद बंद कर दिया जिसे पकड़ पाना सचमुच मुश्किल है।

Shopify फिर भी इस पर मुहर नहीं लगाएगा, क्योंकि…

Shopify का दस्तावेज़ अब आम "proxies" की बात करके टाल नहीं देता। वह सीधे O2O का नाम लेता है:

"O2O समेत Cloudflare proxy सेटअप Shopify द्वारा समर्थित नहीं हैं। हालाँकि आपका स्टोर सही ढंग से काम करता दिख सकता है, यह सेटअप कभी भी टूट सकता है।"

यह किसी हल हो चुकी समस्या पर पुरानी पड़ चुकी चेतावनी नहीं है। यह एक मौजूदा, सोची-समझी स्थिति है, और इसके पीछे के दो कारण O2O के बाद भी टिकते हैं:

Shopify का अपना दस्तावेज़ एक तीसरा कारण भी जोड़ता है, bot detection, यह तर्क देते हुए कि Cloudflare से गुज़रा ट्रैफ़िक बदले हुए रिक्वेस्ट एट्रिब्यूट्स के साथ उस तक पहुँचता है। व्यवहार में यह तीनों में सबसे कमज़ोर है: Cloudflare दुनिया के सबसे बड़े bot-management नेटवर्क में से एक चलाता है, इसलिए ज़्यादातर स्टोर एज पर उससे कहीं ज़्यादा बॉट फ़िल्टरिंग पाते हैं जितना संकेत Shopify खोता है। Shopify की सूची में यह इकलौता आइटम है जहाँ proxy नुक़सान से ज़्यादा फ़ायदा करने की संभावना रखता है।

क्या यह चेतावनी ज़रूरत से ज़्यादा सख़्त है?

थोड़ी सी, और यह समझ में आने लायक़ है। डैशबोर्ड एक चालू, कनेक्टेड स्टोर पर अंबर रंग का "Issue" और सपाट वाक्यांश "not supported" चिपका देता है, जो असली ख़राबियों से कहीं ज़्यादा भारी लगता है, और उनमें से ज़्यादातर सही कॉन्फ़िगरेशन से टाली जा सकती हैं। मर्चेंट "Issue" पढ़ता है और सुनता है "आपका स्टोर टूटने वाला है", जबकि Shopify का मतलब इसके ज़्यादा क़रीब है कि "हम इसकी ज़मानत नहीं लेंगे"।

लेकिन "not supported" का मतलब "काम नहीं करता" नहीं है, और यह फ़र्क़ मायने रखता है। इसका मतलब है कि Shopify ऐसी परत के व्यवहार की गारंटी, डीबगिंग या ज़िम्मेदारी नहीं लेगा जिस पर उसका नियंत्रण नहीं है। ऐसे प्लेटफ़ॉर्म के लिए जो आपका checkout और आपका अपटाइम संभालता है, यह एक वाजिब लकीर है, भले ही बैनर उसे दो-टूक ढंग से खींचता हो। यह फ़्लैग बताता है कि Shopify इस सेटअप के पीछे खड़ा नहीं होगा। यह नहीं बताता कि सेटअप फेल हो रहा है।

कई Shopify स्टोर यह चला रहे हैं

आपको एक टेस्ट स्टोर की बात पर भरोसा करने की ज़रूरत नहीं। Shopify के आगे Cloudflare proxy कोई हाशिये का कॉन्फ़िगरेशन नहीं है: बहुत सारे स्थापित ब्रांड इसे रोज़, प्रोडक्शन में चलाते हैं। नीचे दिए नाम ऐसे लाइव उदाहरण हैं जिन्हें हमने हाथ से जाँचा, हर एक इस समय अपना स्टोरफ़्रंट Cloudflare proxy से होकर सर्व कर रहा है, पीछे Shopify के साथ।

जुलाई 2026 में हर डोमेन की रिक्वेस्ट करके और Shopify स्टोरफ़्रंट के मार्करों के साथ Cloudflare proxy रिस्पॉन्स की पुष्टि करके जाँचा गया। किसी स्टोर का सेटअप कभी भी बदल सकता है, इसलिए इसे एक स्नैपशॉट मानें, सूचीबद्ध ब्रांड्स की ओर से कोई समर्थन नहीं।

एज से वह क्या मिलता है जो Shopify नहीं देता

Shopify हर प्लान पर पहले ही एक CDN, SSL सर्टिफ़िकेट और DDoS सुरक्षा देता है, जैसा Hardeep ने कम्युनिटी थ्रेड में भी बताया। proxy वह चीज़ नहीं है जो आपके स्टोर को तेज़, एन्क्रिप्टेड या बाढ़ झेलने लायक़ बनाती है, और अगर आप यही ढूँढ रहे थे, तो वह आपके पास पहले से है। आगे जो है वह उन चीज़ों का छोटा समूह है जो Shopify आपको नहीं देता।

यह ट्रेडऑफ़ स्वीकारने की वजह proxy ख़ुद नहीं है। वजह वह परत है जो proxy आपके स्टोर के आगे रखता है, एक प्रोग्रामेबल एज जिस तक Shopify आपको पहुँच नहीं देता। तीन क्षमताएँ सबसे ज़्यादा मायने रखती हैं, और तीसरी वह है जो ज़्यादातर स्टोर कभी देखते ही नहीं।

इनमें से कुछ भी Shopify प्लान के साथ नहीं आता, क्योंकि इनमें से कुछ भी Shopify के अंदर नहीं रहता। यह एक हॉप पहले रहता है, एज पर, और यही पूरी वजह है कि कोई मर्चेंट सबसे पहले एक असमर्थित proxy का बोझ उठाएगा।

एक चेतावनी: एज कैशिंग अपने आप नहीं होती। Cloudflare स्टाइलशीट और इमेज जैसी स्टैटिक फ़ाइलें अपने एज पर रख सकता है और हर विज़िट पर Shopify से लाने के बजाय पास के सर्वर से सर्व कर सकता है, लेकिन एक proxied Shopify स्टोर अपने आप कैश नहीं करता, और कोई डिफ़ॉल्ट या ग़लत दायरे वाला कैश नियम उसे पूरी तरह दबा सकता है, जिससे एक साल तक कैश करने योग्य चिह्नित फ़ाइलें बिना छुए सीधे निकल जाती हैं। Shopify का अपना नेटवर्क वैसे भी स्टोरफ़्रंट को तेज़ रखता है, इसलिए एज कैशिंग को एक ऐसा स्पीड बोनस मानें जिसे आप चुनकर चालू करते हैं। पुरानी SSL समस्याओं को रोकने वाला एन्क्रिप्शन मोड आप SSL/TLS कॉन्फ़िगरेशन में पुष्टि करते हैं, वही स्क्रीन जहाँ पहले बताया गया Configure बटन है; कैशिंग अपने अलग हिस्से में सेट होती है, इसलिए डैशबोर्ड में रहते हुए दोनों जाँच लेना सही है, क्योंकि कैशिंग वही सेटिंग है जिससे सबसे ज़्यादा स्पीड बेकार जाने की संभावना है।

एक डेवलपर आपको किन बातों पर आगाह करेगा

एक अच्छा डेवलपर बिना सवाल किए इसे हरी झंडी नहीं देगा, और सवाल जायज़ हैं। इनमें से कोई भी इस सेटअप से बचने की वजह नहीं है, लेकिन हर एक को भरोसे पर लेने के बजाय अपने स्टोर पर पुष्टि करना ठीक रहता है। यह अतिरिक्त काम नहीं है: यह वही टेस्टिंग है जो आप किसी भी इन्फ़्रास्ट्रक्चर बदलाव के बाद चलाते, और यह स्टोर को स्वस्थ रखने का हिस्सा है। हम जो स्टोर चलाते हैं उस पर नीचे दिए दोनों टेस्ट करते हैं, और आपको भी करने चाहिए।

handoff पर लेटेंसी

पहला सवाल स्पीड का है: क्या Shopify के अपने zone से पहले आपके Cloudflare zone से होकर जाने में ध्यान देने लायक़ समय लगता है? नहीं लगना चाहिए, क्योंकि दोनों zones पहले से एक ही Cloudflare नेटवर्क पर बैठे हैं, इसलिए handoff खुले इंटरनेट पर नहीं, उसी नेटवर्क के अंदर होता है। हमने इसे clawmart.digital, यानी proxied टेस्ट स्टोर पर, उसी मशीन से सीधे Shopify के myshopify.com एंडपॉइंट्स के मुक़ाबले मापा। proxied स्टोर ने एज पर लगभग 150 से 200 मिलीसेकंड में जवाब दिया, वही बैंड जिसमें उसके बग़ल में non-proxied Shopify एंडपॉइंट थे। अतिरिक्त हॉप सामान्य रन-दर-रन उतार-चढ़ाव में खो गया।

जब कोई proxied Shopify स्टोर सचमुच धीमा लगता है, तो वजह लगभग हमेशा एक भारी थीम या धीमा थर्ड-पार्टी ऐप होता है, proxy नहीं। एज को दोष देने से पहले मापें। Time to first byte, एक ही जगह से कई बार चलाकर, सबसे तेज़ पढ़त देता है:

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

उसकी तुलना grey-cloud (DNS-only) बेसलाइन से करें, या अपने myshopify.com पते से, या किसी WebPageTest रन से। कुछ मिलीसेकंड का फ़र्क़ बताता है कि proxy आपकी अड़चन नहीं है। सैकड़ों मिलीसेकंड का मतलब है कि थीम और ऐप स्टैक अड़चन हैं, और समय वहीं लगाना चाहिए: थीम छाँटना, बेकार पड़े ऐप हटाना, और इमेज लोड होने का तरीक़ा ठीक करना उस आँकड़े को एज पर की गई किसी भी सेटिंग से कहीं ज़्यादा हिलाएगा।

checkout में ऐप्स

दूसरा सवाल checkout का है: क्या proxy checkout-extensibility ऐप्स, पेमेंट, या सबसे अहम चरण पर चलने वाली स्क्रिप्ट्स में दख़ल देगा? डिज़ाइन के हिसाब से नहीं देना चाहिए। Cloudflare की O2O रूटिंग /checkout पाथ पर Workers और Snippets को ख़ास तौर पर इसीलिए बंद कर देती है ताकि एज पर आपका चलाया कुछ भी पेमेंट को छू न सके। हमारे परीक्षण में, इस सेटअप के पीछे कोई भी लोकप्रिय checkout-extensibility ऐप ग़लत व्यवहार नहीं करता। यह हमारा अनुभव है, बाज़ार के हर ऐप के लिए गारंटी नहीं, इसलिए पूरा checkout हमेशा ख़ुद चलाकर देखें।

अपने ऐप्स चालू रखते हुए एक असली ऑर्डर करें: पुष्टि करें कि डिस्काउंट, शिपिंग लॉजिक, अपसेल, और कोई भी post-purchase एक्सटेंशन वैसे ही चलते हैं जैसे proxy के बिना चलते हैं, और ऑर्डर उन्हीं एट्रिब्यूट्स के साथ Shopify में पहुँचता है जिनकी आप उम्मीद करते हैं। अगर कोई ऐप ग़लत व्यवहार करने वाला है, तो वह यहीं दिखेगा, आपके टेस्ट ऑर्डर पर, किसी ग्राहक के सामने आने से बहुत पहले।

क्या आपके Shopify फ़ीचर्स अब भी काम करेंगे?

यह वह सवाल है जो मर्चेंट पीछे हटने से ठीक पहले पूछते हैं: अगर Cloudflare आगे बैठा है, तो क्या वे चीज़ें जो मैं Shopify के अंदर मैनेज करता हूँ वैसे ही चलेंगी? सबसे ज़्यादा चिंता URL redirects को लेकर होती है, क्योंकि वे Shopify admin में मैनेज होते हैं, वे SEO के लिए मायने रखते हैं, और यह साफ़ नहीं होता कि आगे बैठा proxy उन्हें कैश करेगा, बदलेगा या निगल जाएगा।

तो हमने इसके बारे में सोचने के बजाय proxied स्टोर पर इसे टेस्ट किया। हमने Shopify admin में /pages/redirect-test-20260727 से होमपेज तक एक 301 बनाया, पहले पुष्टि की कि वह पाथ 404 लौटाता है ताकि कुछ भी असली प्रभावित न हो, कई कोणों से जाँचा, फिर उसे मिटा दिया।

Cloudflare से जुड़ा जवाब उसी आख़िरी पंक्ति में है। उसने रीडायरेक्ट सीधे पास कर दिए और कभी कैश नहीं किए, इसलिए आपका रीडायरेक्ट लॉजिक पूरी तरह Shopify के नियंत्रण में रहता है। यह किस्मत भी नहीं है: Shopify 301 पर ख़ुद cache-control: private, no-store भेजता है, इसलिए Cloudflare उसे तब भी कैश नहीं करता अगर आप कहें। क्वेरी स्ट्रिंग्स बची रहती हैं, apex काम करता है, और सादा HTTP काम करता है।

सफ़ाई के दौरान मिली एक बात जानने लायक़ है, क्योंकि वह Cloudflare की समस्या जैसी दिखती है और है नहीं। रीडायरेक्ट मिटाने के बाद, सादा URL लगभग तीस सेकंड तक पुराना 301 सर्व करता रहा जबकि उसी URL का cache-busted संस्करण पहले ही 404 लौटा रहा था। वह एक अकेला Shopify edge node पुरानी कॉपी पकड़े हुए था, Cloudflare नहीं: cf-cache-status पूरे समय DYNAMIC रहा और क्वेरी-स्ट्रिंग वाला संस्करण तुरंत सही था। यह अपने आप ठीक हो गया। तो रीडायरेक्ट बदलने या हटाने के बाद, यह नतीजा निकालने से पहले कि वह काम नहीं किया, एक मिनट दें, और शक हो तो cache-buster के साथ टेस्ट करें।

यह पहले बताई गई कैशिंग वाली चेतावनी से भी जुड़ता है, और दोनों तरफ़ काटता है। एज कैशिंग बंद होने पर, रीडायरेक्ट के बदलाव तुरंत लागू होते हैं, जो एक अनजाने में मिला फ़ायदा है। अगर आप बाद में एज पर HTML कैशिंग चालू करते हैं, तो रीडायरेक्ट भी वहाँ कैश हो सकते हैं और आपके बदलाव तुरंत दिखना बंद कर देंगे। अगर आप उस रास्ते जाते हैं, तो कैश नियम से रीडायरेक्ट पाथ बाहर रखें या थोक में रीडायरेक्ट मैनेज करने वाली अपनी टूलिंग में एक purge स्टेप बना लें।

स्टोर के पब्लिक होने से पहले सेटअप करना

इसमें से कुछ भी कॉन्फ़िगर और टेस्ट करने के लिए आपको लॉन्च हो चुके स्टोरफ़्रंट की ज़रूरत नहीं। अक्सर यही ज़्यादा समझदारी है कि स्टोर के प्राइवेट रहते हुए ही यह कर लिया जाए, ताकि O2O डिटेक्शन, SSL प्रोविज़निंग और checkout टेस्ट सब वहाँ हों जहाँ कोई ग्राहक अधूरे सेटअप में न भटक जाए। एकमात्र ज़रूरत एक पेड Shopify प्लान है, क्योंकि कस्टम डोमेन फ़्री ट्रायल पर उपलब्ध नहीं होते। हालाँकि स्टोर लॉन्च करना ज़रूरी नहीं: पासवर्ड पेज के पीछे रखा एक पेड प्लान ही सेटअप के लिए काफ़ी है। अगर आप फ़्री Partner development store पर हैं, जो कस्टम डोमेन सीमित करता है, तो पहले उसे पेड प्लान में ट्रांसफ़र करें, फिर वही स्टेप्स अपनाएँ।

तो क्या आपको इसे चलाना चाहिए?

इसे हाँ-या-ना के सवाल से हटाकर इस निर्णय में बदलें कि आपको एज पर क्या चाहिए, क्योंकि यही एकमात्र चीज़ है जो इस ट्रेडऑफ़ को जायज़ ठहराती है।

Shopify Community के यूज़र Steve_TopNewYork और sophia24 दोनों उसी थ्रेड में उस तीसरे कारण पर पहुँचे, और यही वह क़ीमत है जिसे मर्चेंट कम आँकते हैं। proxy शायद ही कभी टूटने वाली चीज़ होती है, लेकिन एक बार रास्ते में आ जाने पर वह एक और परत है जिसे आपको रात के दो बजे छाँटना पड़ता है जब checkout गड़बड़ कर रहा हो और आपको अभी पता न हो कि क्यों। एक छोटी टीम पर यह असली बोझ है, और इसे उठाना सिर्फ़ ऐसे फ़ीचर के लिए ठीक है जिसका आप नाम ले सकें।

अगर आप इसे चलाते हैं, तो चेकलिस्ट को अनिवार्य मानें: shops.myshopify.com की ओर एक proxied CNAME, पुष्टि करें कि Shopify आइकन दिखता है, Always Use HTTPS बंद रखें, अपने HTTPS रीडायरेक्ट से ACME पाथ को बाहर रखें, और सर्टिफ़िकेट की रिन्यूअल तारीख़ वैसे ही जाँचें जैसे आप जाँचते हैं कि बैकअप सचमुच चला या नहीं। इस तरह कॉन्फ़िगर करने पर, बहुत सारे स्टोर बिना किसी नाटक के Shopify के आगे Cloudflare पर चलते हैं। ये स्टेप्स छोड़ दें, और आपने ठीक वही चुपचाप आने वाली ख़राबी तैयार कर दी जिसे यह चेतावनी रोकना चाहती है।

संक्षेप में, वीडियो पर: Field Notes: Cloudflare in front of Shopify बताता है कि O2O ने क्या ठीक किया और वे दो चीज़ें कौन सी हैं जो एक एज सेवा आपको दिखाती है और Shopify नहीं।

अक्सर पूछे जाने वाले प्रश्न

क्या Shopify स्टोर के आगे Cloudflare लगाना सुरक्षित है?

यह पहले के मुक़ाबले कहीं ज़्यादा व्यवहार्य है, लेकिन Shopify इसे आधिकारिक रूप से सपोर्ट नहीं करता, इसलिए यह एक सोचा-समझा विकल्प है, जोखिम-मुक्त नहीं। जो रूटिंग समस्या पहले स्टोर तोड़ती थी, यानी दो Cloudflare zones का टकराव, उसे Cloudflare के Orange-to-Orange (O2O) फ़ीचर ने हल कर दिया। सही कॉन्फ़िगर होने पर, यानी shops.myshopify.com की ओर एक proxied CNAME, Always Use HTTPS बंद, और किसी भी HTTPS रीडायरेक्ट से ACME challenge पाथ बाहर, बहुत सारे स्टोर इस पर भरोसे के साथ चलते हैं। Shopify का अपना दस्तावेज़ अब भी कहता है कि O2O समेत Cloudflare proxy सेटअप समर्थित नहीं हैं और कभी भी टूट सकते हैं, क्योंकि वह ऐसी proxy परत के व्यवहार की गारंटी नहीं दे सकता जिस पर उसका नियंत्रण नहीं है। ईमानदार सारांश: सही तरीक़े से लगाया जाए तो तकनीकी रूप से ठोस, आधिकारिक रूप से असमर्थित, और उन्हीं स्टोर के लिए सबसे उपयुक्त जिन्हें एज पर कुछ ऐसा चाहिए जो Shopify नहीं देता।

Orange-to-Orange (O2O) क्या है?

Orange-to-Orange, Cloudflare का वह रूटिंग फ़ीचर है जो तब काम आता है जब कोई Cloudflare ग्राहक अपना proxied डोमेन ऐसी सेवा की ओर पॉइंट करता है जो ख़ुद भी Cloudflare की ग्राहक है। Cloudflare का proxy डैशबोर्ड में नारंगी बादल के रूप में दिखता है, इसलिए एक के ऊपर एक दो Cloudflare zones को orange-to-orange कहा जाता है। Shopify एक Cloudflare for SaaS ग्राहक है, इसलिए Shopify स्टोर बिल्कुल यही मामला है। O2O से पहले, Cloudflare भरोसे के साथ यह नहीं बता पाता था कि रिक्वेस्ट का मालिक कौन सा zone है और दोनों टकरा जाते थे। O2O पहचान लेता है कि CNAME टारगेट किसी दूसरे Cloudflare ग्राहक का है और रिक्वेस्ट को पहले आपके zone से और फिर प्रोवाइडर के zone से, क्रम में भेजता है। आप पुष्टि कर सकते हैं कि यह काम कर रहा है जब आपके Cloudflare डैशबोर्ड में CNAME रिकॉर्ड के बग़ल में एक छोटा Shopify आइकन दिखता है।

Shopify क्यों कहता है कि Cloudflare समर्थित नहीं है?

Shopify का दस्तावेज़ तीन मुख्य कारण देता है। दो अच्छी तरह टिकते हैं। पहला, SSL: Shopify सर्टिफ़िकेट Let’s Encrypt के ज़रिए एक ACME HTTP challenge का इस्तेमाल करके जारी और रिन्यू करता है, और आगे बैठा कोई भी proxy उस वैलिडेशन में दख़ल दे सकने वाली एक और चीज़ है। दूसरा, घटना प्रतिक्रिया: जब Shopify के अपने इन्फ़्रास्ट्रक्चर में कोई दिक़्क़त आती है, तो स्टोर के आगे लगे अतिरिक्त proxy Shopify के लिए उस समस्या के इर्द-गिर्द रास्ता बदलना मुश्किल कर देते हैं, जिससे डाउनटाइम का जोखिम घटने के बजाय बढ़ता है। तीसरा, bot detection, कमज़ोर है: Shopify का तर्क है कि Cloudflare से गुज़रा ट्रैफ़िक बदले हुए रिक्वेस्ट एट्रिब्यूट्स के साथ पहुँचता है, लेकिन Cloudflare दुनिया के सबसे बड़े bot-management नेटवर्क में से एक चलाता है, इसलिए ज़्यादातर स्टोर एज पर उससे कहीं ज़्यादा बॉट फ़िल्टरिंग पाते हैं जितना संकेत Shopify खोता है। इनमें से किसी का मतलब यह नहीं कि सेटअप काम नहीं कर सकता। मतलब यह है कि Shopify ऐसी परत के व्यवहार की ज़िम्मेदारी नहीं लेगा जो उसकी अपनी नहीं है।

Cloudflare के पीछे मेरा Shopify SSL सर्टिफ़िकेट क्यों फेल होता है?

लगभग हमेशा Always Use HTTPS सेटिंग की वजह से। Shopify डोमेन का मालिकाना हक़ वैलिडेट करता है और SSL सर्टिफ़िकेट रिन्यू करता है, एक challenge का जवाब देकर जो /.well-known/acme-challenge/ पाथ पर सर्व होता है। Always Use HTTPS हर रिक्वेस्ट पर रीडायरेक्ट थोप देता है, उस पाथ पर भी, इसलिए challenge कभी पूरा नहीं होता और सर्टिफ़िकेट न जारी हो पाता है न रिन्यू। स्टोर मौजूदा सर्टिफ़िकेट पर तब तक चलता रहता है जब तक वह ख़त्म नहीं होता, फिर डोमेन insecure हो जाता है या कनेक्ट होना बंद कर देता है। Cloudflare जो समाधान बताता है वह यह है कि Always Use HTTPS बंद रखें और इसके बजाय एक redirect rule बनाएँ जो /.well-known/acme-challenge/ पाथ को छोड़कर बाक़ी सब पर HTTPS लागू करे।

क्या मुझे SSL रिन्यूअल जाँचने के लिए कैलेंडर रिमाइंडर लगाना चाहिए ताकि मेरा स्टोर न टूटे?

नहीं, अगर यह सही कॉन्फ़िगर है तो नहीं। रिन्यूअल अपने आप चलने के लिए ही बनाया गया है। आपके विज़िटर को जो सर्टिफ़िकेट असल में दिखता है वह Cloudflare का अपना edge certificate है, जिसे Cloudflare DNS के ज़रिए वैलिडेट करता है और अपने आप रिन्यू करता है, इसलिए वह ACME challenge पाथ पर बिल्कुल निर्भर नहीं है। उसके पीछे, Shopify का origin certificate पर्दे के पीछे Let’s Encrypt के ज़रिए रिन्यू होता है, और यह तब तक चलता रहता है जब तक Always Use HTTPS बंद है और /.well-known/acme-challenge/ पाथ रीडायरेक्ट नहीं हो रहा। सेटअप के बाद एक बार curl टेस्ट चलाकर पुष्टि करें कि वह पाथ 404 लौटाता है, रीडायरेक्ट नहीं, और ऑटोमैटिक रिन्यूअल को जो चाहिए वह मिल जाएगा। अगर आप सुरक्षा जाल चाहते हैं, तो सही टूल कोई मैनुअल कैलेंडर रिमाइंडर नहीं है जिस पर आपको काम करना पड़े, बल्कि एक ऑटोमेटेड SSL-एक्सपायरी मॉनिटर है जो सर्टिफ़िकेट की समाप्ति में कुछ हफ़्ते बचने पर आपको ईमेल कर दे। इस तरह कुछ भी आपकी याददाश्त पर निर्भर नहीं रहता।

सर्टिफ़िकेट की समस्या स्टोर गिराने से पहले मुझे कैसे पता चलेगी?

मॉनिटरिंग लगाइए ताकि आपको बताया जाए, न कि आप किसी ग्राहक से पता करें। UptimeRobot, Better Uptime या इसी तरह की कोई मुफ़्त SSL और अपटाइम मॉनिटरिंग सेवा डोमेन पर नज़र रख सकती है और सर्टिफ़िकेट ख़त्म होने से दिनों पहले, या HTTPS फेल होते ही, आपको अलर्ट कर सकती है। Cloudflare ख़ुद भी डैशबोर्ड के Notifications हिस्से से सर्टिफ़िकेट और origin की समस्याओं की सूचनाएँ भेज सकता है। इनमें से कोई भी लगी हो, तो इस सेटअप का जो एक असली जोखिम है, चुपचाप रिन्यूअल फेल होना, वह चुप नहीं रहता: आपको हफ़्तों की मोहलत के साथ ईमेल मिल जाता है, ख़रीदारों के लिए ताला टूटने से बहुत पहले।

क्या Cloudflare proxy के पीछे Shopify URL redirects अब भी काम करते हैं?

हाँ। हमने इसे एक proxied स्टोर पर शुरू से आख़िर तक टेस्ट किया: Shopify admin में बनाया गया एक 301 बिना किसी प्रोपेगेशन इंतज़ार के तुरंत लाइव हुआ, सही 301 और location हेडर लौटाया, एक हॉप में टारगेट पर 200 तक पहुँचा, ?utm_source=test जैसी क्वेरी स्ट्रिंग्स बचाए रखीं, और apex डोमेन से तथा सादे HTTP पर भी काम किया। Cloudflare ने रीडायरेक्ट को सीधे पास किया और कभी कैश नहीं किया, हर रिक्वेस्ट पर cf-cache-status: DYNAMIC रिपोर्ट करते हुए, इसलिए आपका रीडायरेक्ट लॉजिक पूरी तरह Shopify के नियंत्रण में रहता है। Shopify 301 पर ख़ुद cache-control: private, no-store भी भेजता है, इसलिए Cloudflare उसे तब भी कैश नहीं करता अगर आप ऐसा कॉन्फ़िगर कर दें। एक चेतावनी: रीडायरेक्ट बदलने या मिटाने के बाद कोई Shopify edge node लगभग तीस सेकंड तक पुरानी कॉपी सर्व कर सकता है, इसलिए एक मिनट दें और यह नतीजा निकालने से पहले cache-buster के साथ टेस्ट करें कि वह काम नहीं किया। अगर आप बाद में Cloudflare एज पर HTML कैशिंग चालू करते हैं, तो रीडायरेक्ट पाथ बाहर रखें या एक purge स्टेप जोड़ें, क्योंकि रीडायरेक्ट वहाँ भी कैश हो सकते हैं।

क्या मैं ऐसे Shopify स्टोर पर Cloudflare सेट कर सकता हूँ जो अभी पब्लिक नहीं है?

हाँ, और अक्सर यही समझदारी भरा तरीक़ा है। आपको लॉन्च हो चुके स्टोरफ़्रंट की ज़रूरत नहीं, सिर्फ़ एक पेड Shopify प्लान की, क्योंकि कस्टम डोमेन फ़्री ट्रायल पर उपलब्ध नहीं होते। स्टोर को Online Store फिर Preferences के अंतर्गत उसके पासवर्ड पेज के पीछे रखें, Cloudflare में shops.myshopify.com की ओर वही proxied CNAME बनाएँ, ऐसे होस्ट के साथ जो आप प्रोडक्शन में सर्व नहीं कर रहे, जैसे कोई staging सबडोमेन, और उस होस्ट को Shopify में Settings फिर Domains के अंतर्गत कनेक्ट करें। Shopify SSL प्रोविज़न करता है और Orange-to-Orange सक्रिय होते ही Cloudflare डैशबोर्ड Shopify आइकन दिखाता है, जबकि आम लोगों को सिर्फ़ पासवर्ड पेज दिखता रहता है। ACME curl टेस्ट और अपने ऐप्स चालू रखते हुए एक पूरा टेस्ट checkout चलाएँ, और जब सब कुछ पास हो जाए, पासवर्ड हटा दें और अपने असली डोमेन को primary सेट करें। आप एक ऐसे कॉन्फ़िगरेशन पर लॉन्च करते हैं जिसे आप पहले ही साबित कर चुके हैं। अगर आप फ़्री Partner development store पर हैं, जो कस्टम डोमेन सीमित करता है, तो पहले उसे पेड प्लान में ट्रांसफ़र करें।