लोकल HTTPS के लिए mkcert उपयोग करूँ या tunnel?

दोनों, अलग-अलग चीज़ों के लिए। mkcert आपके अपने ब्राउज़र को localhost पर विश्वसनीय सर्टिफ़िकेट देता है और ऑफ़लाइन काम करता है। tunnel आपको सार्वजनिक HTTPS URL देता है जिस तक बाहरी सेवाएँ और अन्य डिवाइस पहुँच सकें। ये टकराते नहीं — अधिकांश टीमें दोनों उपयोग करती हैं।

क्या mkcert Stripe या GitHub से वेबहुक टेस्टिंग संभाल सकता है?

नहीं। mkcert सर्टिफ़िकेट केवल उस मशीन पर विश्वसनीय हैं जिसने CA इंस्टॉल किया। बाहरी वेबहुक प्रदाता localhost तक नहीं पहुँच सकते, चाहे आपके लोकल ब्राउज़र में सर्टिफ़िकेट कितना भी विश्वसनीय हो। किसी भी इनबाउंड सार्वजनिक ट्रैफ़िक के लिए tunnel उपयोग करें।

क्या mkcert OAuth localhost callback के लिए काम करता है?

कुछ प्रदाता (Google, Auth0 के कुछ dev tier) विकास के लिए HTTP या HTTPS पर localhost स्वीकारते हैं। कई नहीं। mkcert उन्हें HTTPS देता है जो स्वीकारते हैं; सख़्त वालों के लिए सार्वजनिक HTTPS URL वाला tunnel आवश्यक है।

localhost पर HTTPS: mkcert बनाम tunnel, ईमानदार तुलना

दो टूल, एक समस्या: आपका dev सर्वर HTTPS पर पहुँच योग्य होना चाहिए। mkcert आपको लोकली विश्वसनीय TLS सर्टिफ़िकेट देता है ताकि https://localhost:3000 बस काम करे। एक tunnel आपको असली CA के असली सर्टिफ़िकेट से समर्थित सार्वजनिक HTTPS URL देता है। ये प्रतिद्वंद्वी नहीं — अलग समस्याएँ हल करते हैं — पर लोग इन्हें ऐसे मानते रहते हैं जैसे हों।

छोटा उत्तर

आपको HTTPS केवल अपनी मशीन पर, अपने ब्राउज़र के लिए चाहिए? mkcert उपयोग करें।
आपको चाहिए कि कोई बाहरी सेवा (Stripe, GitHub, Auth0, एक फ़ोन) आपके dev सर्वर तक पहुँचे? tunnel उपयोग करें।
दोनों? दोनों चलाएँ। ये टकराते नहीं।

यही पूरा लेख तीन बिंदुओं में है। बाक़ी बस क्यों है।

mkcert: 30 सेकंड में लोकली विश्वसनीय सर्टिफ़िकेट

mkcert आपके ऑपरेटिंग सिस्टम के trust store में एक लोकल प्रमाणन प्राधिकरण इंस्टॉल करता है और उससे सर्टिफ़िकेट जारी करता है। आपका ब्राउज़र सर्ट को विश्वसनीय देखता है क्योंकि CA विश्वसनीय है। कोई आपका कनेक्शन निजी नहीं है चेतावनी नहीं, कोई --ignore-certificate-errors फ़्लैग नहीं, अपने self-signed सर्ट बनाने का झंझट नहीं।

# प्रति मशीन एक बार
mkcert -install

# प्रति प्रोजेक्ट एक बार
mkcert localhost 127.0.0.1

# अब आपके पास localhost.pem और localhost-key.pem हैं

इन्हें अपने dev सर्वर में जोड़ें (Vite, Next.js, Express, Django runserver_plus सभी TLS args का समर्थन करते हैं) और आपके पास असली सर्टिफ़िकेट के साथ https://localhost:3000 है।

पेच: केवल आपकी मशीन उस CA पर भरोसा करती है। आपके साथी का ब्राउज़र चेतावनी देगा। आपका फ़ोन CA रूट मैन्युअल इंस्टॉल किए बिना भरोसा नहीं करेगा।

Tunnel: असली HTTPS, असली सार्वजनिक URL

एक localhost tunnel सार्वजनिक HTTPS URL से आपके लोकल पोर्ट पर ट्रैफ़िक अग्रेषित करता है। सर्टिफ़िकेट असली CA (Let's Encrypt आदि) जारी करता है और हर डिवाइस का हर ब्राउज़र भरोसा करता है।

npx portpreview 3000

tunnel क्लाउड gateway पर TLS termination संभालता है। आपका लोकल सर्वर सादे HTTP पर रह सकता है — सार्वजनिक URL HTTPS है, और वही सतह है जिसे हर बाहरी सेवा छूती है।

आमने-सामने

ज़रूरत	mkcert	Tunnel
आपके लोकल ब्राउज़र में HTTPS	हाँ	हाँ (सार्वजनिक URL के ज़रिए)
ब्राउज़र में service worker / secure cookie टेस्ट	हाँ	हाँ
बाहरी प्रदाता आप तक पहुँच सकता है	नहीं	हाँ
हाथ का फ़ोन आप तक पहुँच सकता है	नहीं (CA इंस्टॉल किए बिना)	हाँ
OAuth प्रदाता URL स्वीकारता है	कभी-कभी (Google: हाँ; कई: नहीं)	हाँ
Stripe / GitHub / Twilio वेबहुक भेज सकते हैं	नहीं	हाँ
सेटअप समय	प्रति मशीन 30 सेकंड	प्रति सत्र एक कमांड
ऑफ़लाइन काम करता है	हाँ	नहीं
एयरप्लेन मोड में टिकता है	हाँ	नहीं

जहाँ लोग ग़लती करते हैं

वेबहुक टेस्टिंग के लिए mkcert उपयोग करने की कोशिश

Stripe आपकी मशीन के लोकल CA पर भरोसा नहीं कर सकता। चाहे सर्टिफ़िकेट आपके ब्राउज़र में कितना भी विश्वसनीय दिखे — Stripe अलग नेटवर्क में है। सार्वजनिक इंटरनेट से किसी भी इनबाउंड ट्रैफ़िक के लिए आपको tunnel चाहिए।

केवल-ब्राउज़र अकेले HTTPS के लिए tunnel उपयोग करना

यदि आप बस चाहते हैं कि service worker काम करें या अपने ब्राउज़र में secure cookie सेट हो, तो mkcert तेज़ है और ऑफ़लाइन काम करता है। जो सर्टिफ़िकेट फ़ाइल हल करती है उसके लिए tunnel सत्र मत जलाएँ।

एक टूल चुनना और दूसरे केस को उसी से ज़बरदस्ती कराना

दोनों चलाना ठीक है। हमारे सेटअप का अधिकांश रोज़मर्रा के ब्राउज़र-साइड काम के लिए mkcert और वेबहुक या OAuth callback टेस्ट करते समय tunnel उपयोग करता है। ये package.json में बिना टकराव सह-अस्तित्व रखते हैं।

Caddy या nginx का क्या?

हाँ, आप अपने dev सर्वर के आगे स्वचालित HTTPS के साथ Caddy चला सकते हैं, और वह भी काम करता है — यह मूलतः "अतिरिक्त चरणों और reverse proxy के साथ mkcert" है। अधिकांश लोकल dev के लिए mkcert सरल है। कई लोकल सेवाओं के साथ अधिक विस्तृत routing के लिए Caddy अपनी जगह बनाता है।

हमारा असली सेटअप

हम जिस एक repo में काम करते हैं उसमें localhost-साइड HTTPS के लिए dev script में mkcert है, और एक अलग tunnel npm script जो किसी को वेबहुक या मोबाइल टेस्टिंग चाहिए होने पर portpreview चलाती है। tunnel URL env var से पास होता है ताकि OAuth redirect URI आसानी से बदले जा सकें। जोड़ने में 20 मिनट लगे और तब से हमने लोकल TLS के बारे में फिर कभी नहीं सोचा।

OAuth-विशिष्ट tunnel सेटअप के लिए देखें OAuth callback को लोकल कैसे टेस्ट करें। साथियों या डिज़ाइनरों के साथ प्रीव्यू साझा करने के लिए अपना लोकल dev सर्वर साझा करें। इस सेटअप के tunnel पक्ष के लिए PortPreview वेटलिस्ट में शामिल हों।