HTTPS บน localhost: mkcert กับ tunnel เทียบกันตรง ๆ

สองเครื่องมือ หนึ่งปัญหา: เซิร์ฟเวอร์ dev ของคุณต้องเข้าถึงได้ผ่าน HTTPS mkcert ให้ใบรับรอง TLS ที่เชื่อถือในเครื่อง เพื่อให้ https://localhost:3000 ทำงานได้เลย tunnel ให้ URL HTTPS สาธารณะที่หนุนด้วยใบรับรองจริงจาก CA จริง ทั้งคู่ไม่ใช่คู่แข่ง — แก้คนละปัญหา — แต่คนมักปฏิบัติราวกับเป็นคู่แข่ง

คำตอบสั้น ๆ

• ต้องการ HTTPS แค่บนเครื่องของคุณ สำหรับเบราว์เซอร์ของคุณ? ใช้ mkcert
• ต้องการให้บริการภายนอก (Stripe, GitHub, Auth0, มือถือ) เข้าถึงเซิร์ฟเวอร์ dev ของคุณ? ใช้ tunnel
• ทั้งคู่? รันทั้งคู่ ไม่ขัดกัน

นั่นคือทั้งบทความในสามข้อ ที่เหลือเป็นแค่เหตุผล

mkcert: ใบรับรองที่เชื่อถือในเครื่องใน 30 วินาที

mkcert ติดตั้งผู้ออกใบรับรองในเครื่องลงใน trust store ของระบบปฏิบัติการและออกใบรับรองจากมัน เบราว์เซอร์เห็นใบรับรองว่าเชื่อถือได้เพราะ CA เชื่อถือได้ ไม่มีคำเตือน การเชื่อมต่อของคุณไม่เป็นส่วนตัว ไม่มี flag --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 รองรับ args TLS ทั้งหมด) แล้วคุณได้ https://localhost:3000 พร้อมใบรับรองจริง

จุดที่ติด: มีแค่เครื่องของคุณที่เชื่อ CA นั้น เบราว์เซอร์ของเพื่อนร่วมทีมจะเตือน มือถือของคุณจะไม่เชื่อหากไม่ติดตั้งราก CA ด้วยมือ

Tunnel: HTTPS จริง URL สาธารณะจริง

tunnel localhost ส่งต่อทราฟฟิกจาก URL HTTPS สาธารณะไปยังพอร์ตในเครื่องของคุณ ใบรับรองออกโดย CA จริง (Let's Encrypt หรือคล้ายกัน) และทุกเบราว์เซอร์บนทุกอุปกรณ์เชื่อถือ

npx portpreview 3000

tunnel จัดการ TLS termination ที่ gateway บนคลาวด์ เซิร์ฟเวอร์ในเครื่องของคุณอยู่บน HTTP ธรรมดาได้ — URL สาธารณะเป็น HTTPS และนั่นคือพื้นผิวที่ทุกบริการภายนอกสัมผัส

เทียบเคียงกัน

ความต้องการ	mkcert	Tunnel
HTTPS ในเบราว์เซอร์ในเครื่อง	ได้	ได้ (ผ่าน URL สาธารณะ)
ทดสอบ service worker / secure cookie ในเบราว์เซอร์	ได้	ได้
ผู้ให้บริการภายนอกเข้าถึงคุณได้	ไม่	ได้
มือถือในมือเข้าถึงคุณได้	ไม่ (หากไม่ติดตั้ง CA)	ได้
ผู้ให้บริการ OAuth ยอมรับ URL	บางครั้ง (Google: ได้; หลายเจ้า: ไม่)	ได้
Stripe / GitHub / Twilio ส่ง webhook ได้	ไม่	ได้
เวลาตั้งค่า	30 วินาทีต่อเครื่อง	หนึ่งคำสั่งต่อเซสชัน
ทำงานออฟไลน์	ได้	ไม่
รอดโหมดเครื่องบิน	ได้	ไม่

จุดที่คนเข้าใจผิด

พยายามใช้ mkcert สำหรับทดสอบ webhook

Stripe เชื่อ CA ในเครื่องของคุณไม่ได้ ไม่สำคัญว่าใบรับรองดูน่าเชื่อแค่ไหนในเบราว์เซอร์ — Stripe อยู่คนละเครือข่าย คุณต้องใช้ tunnel สำหรับทราฟฟิกขาเข้าจากอินเทอร์เน็ตสาธารณะ

ใช้ tunnel สำหรับ HTTPS เดี่ยวเฉพาะเบราว์เซอร์

หากคุณแค่อยากให้ service worker ทำงานหรือตั้ง secure cookie ในเบราว์เซอร์ของตัวเอง mkcert เร็วกว่าและทำงานออฟไลน์ อย่าเผาเซสชัน tunnel กับสิ่งที่ไฟล์ใบรับรองแก้ได้

เลือกเครื่องมือเดียวแล้วฝืนดันอีกกรณีผ่านมัน

รันทั้งคู่ก็โอเค การตั้งค่าของเราส่วนใหญ่ใช้ mkcert สำหรับงานฝั่งเบราว์เซอร์รายวันและ tunnel เมื่อทดสอบ webhook หรือ callback OAuth อยู่ร่วมกันใน package.json โดยไม่ขัดกัน

แล้ว Caddy หรือ nginx ล่ะ?

ได้ คุณรัน Caddy พร้อม HTTPS อัตโนมัติหน้าเซิร์ฟเวอร์ dev ได้ และมันก็ทำงาน — โดยพื้นฐานคือ "mkcert พร้อมขั้นเพิ่มและ reverse proxy" สำหรับ dev ในเครื่องส่วนใหญ่ mkcert ง่ายกว่า สำหรับการ routing ซับซ้อนกับหลายบริการในเครื่อง Caddy คุ้มค่า

การตั้งค่าจริงของเรา

repo หนึ่งที่เราทำงานมี mkcert ใน script dev สำหรับ HTTPS ฝั่ง localhost และ script npm tunnel แยกที่รัน portpreview เมื่อมีคนต้องการ webhook หรือทดสอบมือถือ URL tunnel ส่งผ่าน env var เพื่อให้สลับ redirect URI ของ OAuth ได้ง่าย ใช้เวลา 20 นาทีต่อสาย และไม่เคยคิดถึง TLS ในเครื่องอีกเลย

สำหรับตั้งค่า tunnel เฉพาะ OAuth ดู วิธีทดสอบ callback OAuth ในเครื่อง สำหรับแชร์พรีวิวกับเพื่อนร่วมทีมหรือดีไซเนอร์ แชร์เซิร์ฟเวอร์ dev ในเครื่อง เข้าร่วมรายชื่อรอของ PortPreview สำหรับฝั่ง tunnel ของการตั้งค่านี้