Czy używać mkcert czy tunelu do lokalnego HTTPS?

Obu, do różnych rzeczy. mkcert daje twojej przeglądarce zaufany certyfikat na localhost i działa offline. Tunel daje publiczny URL HTTPS osiągalny przez zewnętrzne usługi i inne urządzenia. Nie kolidują — większość zespołów używa obu.

Czy mkcert obsłuży testowanie webhooków ze Stripe lub GitHub?

Nie. Certyfikaty mkcert są zaufane tylko na maszynie, która zainstalowała CA. Zewnętrzni dostawcy webhooków nie mogą dosięgnąć localhost, niezależnie od tego, jak zaufany jest certyfikat w lokalnej przeglądarce. Do dowolnego ruchu publicznego przychodzącego użyj tunelu.

Czy mkcert działa dla callbacków OAuth na localhost?

Niektórzy dostawcy (Google, pewne poziomy dev Auth0) akceptują localhost przez HTTP lub HTTPS do developmentu. Wielu nie. mkcert daje HTTPS dla tych, którzy tak; dla rygorystycznych wymagany jest tunel z publicznym URL HTTPS.

HTTPS na localhost: mkcert vs tunel, uczciwe porównanie

Dwa narzędzia, jeden problem: twój serwer deweloperski musi być osiągalny przez HTTPS. mkcert daje lokalnie zaufany certyfikat TLS, więc https://localhost:3000 po prostu działa. Tunel daje publiczny URL HTTPS oparty na prawdziwym certyfikacie z prawdziwego CA. Nie są konkurentami — rozwiązują różne problemy — ale ludzie wciąż traktują je tak, jakby byli.

Krótka odpowiedź

Potrzebujesz HTTPS tylko na własnej maszynie, dla własnej przeglądarki? Użyj mkcert.
Potrzebujesz, by zewnętrzna usługa (Stripe, GitHub, Auth0, telefon) dotarła do twojego serwera dev? Użyj tunelu.
Obu? Uruchom oba. Nie kolidują.

To cały artykuł w trzech punktach. Reszta to tylko dlaczego.

mkcert: lokalnie zaufane certyfikaty w 30 sekund

mkcert instaluje lokalny urząd certyfikacji w magazynie zaufania twojego systemu operacyjnego i wystawia z niego certyfikaty. Przeglądarka widzi certyfikat jako zaufany, bo CA jest zaufane. Bez ostrzeżeń twoje połączenie nie jest prywatne, bez flag --ignore-certificate-errors, bez klecenia własnych self-signed.

# raz na maszynę
mkcert -install

# raz na projekt
mkcert localhost 127.0.0.1

# masz teraz localhost.pem i localhost-key.pem

Podłącz je do serwera dev (Vite, Next.js, Express, Django runserver_plus — wszystkie wspierają argumenty TLS) i masz https://localhost:3000 z prawdziwym certyfikatem.

Haczyk: tylko twoja maszyna ufa temu CA. Przeglądarka kolegi ostrzeże. Twój telefon nie zaufa bez ręcznej instalacji korzenia CA.

Tunel: prawdziwy HTTPS, prawdziwy publiczny URL

Tunel localhost przekazuje ruch z publicznego URL HTTPS na twój lokalny port. Certyfikat wystawia prawdziwe CA (Let's Encrypt lub podobne) i ufa mu każda przeglądarka na każdym urządzeniu.

npx portpreview 3000

Tunel obsługuje terminację TLS na bramie chmurowej. Twój lokalny serwer może zostać na czystym HTTP — publiczny URL to HTTPS, i to jest powierzchnia, której dotyka każda zewnętrzna usługa.

Obok siebie

Potrzeba	mkcert	Tunel
HTTPS w lokalnej przeglądarce	Tak	Tak (przez publiczny URL)
Testy service worker / secure cookie w przeglądarce	Tak	Tak
Zewnętrzny dostawca może cię dosięgnąć	Nie	Tak
Telefon w ręce może cię dosięgnąć	Nie (bez instalacji CA)	Tak
Dostawca OAuth akceptuje URL	Czasem (Google: tak; wielu: nie)	Tak
Stripe / GitHub / Twilio mogą webhookować	Nie	Tak
Czas konfiguracji	30 sekund na maszynę	Jedno polecenie na sesję
Działa offline	Tak	Nie
Przeżywa tryb samolotowy	Tak	Nie

Gdzie ludzie się mylą

Próba użycia mkcert do testowania webhooków

Stripe nie może zaufać lokalnemu CA twojej maszyny. Nieważne, jak zaufany wygląda certyfikat w przeglądarce — Stripe jest w innej sieci. Do dowolnego ruchu przychodzącego z publicznego internetu potrzebujesz tunelu.

Użycie tunelu do solowego HTTPS tylko w przeglądarce

Jeśli chcesz tylko, by działały service workery albo ustawiło się secure cookie we własnej przeglądarce, mkcert jest szybszy i działa offline. Nie pal sesji tunelu na coś, co rozwiązuje plik certyfikatu.

Wybór jednego narzędzia i przepychanie przez nie drugiego przypadku

Uruchamianie obu jest OK. Większość naszej konfiguracji używa mkcert do codziennej pracy po stronie przeglądarki i tunelu, gdy testujemy webhooki lub callbacki OAuth. Współistnieją w package.json bez konfliktu.

A co z Caddy lub nginx?

Tak, możesz uruchomić Caddy z automatycznym HTTPS przed serwerem dev i to też działa — to zasadniczo „mkcert z dodatkowymi krokami i reverse proxy". Dla większości lokalnego developmentu mkcert jest prostszy. Dla bardziej rozbudowanego routingu z wieloma lokalnymi usługami Caddy zarabia na siebie.

Nasza faktyczna konfiguracja

Jedno repo, w którym pracujemy, ma mkcert w skrypcie dev dla HTTPS po stronie localhost i osobny skrypt npm tunnel, który uruchamia portpreview, gdy ktoś potrzebuje webhooków lub testów mobilnych. URL tunelu przekazywany jest przez zmienną środowiskową, więc redirect URI OAuth łatwo podmienić. Podłączenie zajęło 20 minut i od tamtej pory nie myśleliśmy o lokalnym TLS.

Po konfigurację tunelu pod OAuth zobacz jak testować callbacki OAuth lokalnie. Po udostępnianie podglądów kolegom lub projektantom udostępnianie lokalnego serwera dev. Dołącz do listy oczekujących PortPreview po stronę tunelową tej konfiguracji.