Gerçekten HTTPS gerektiren bir özellik geliştiriyorsunuz: OAuth giriş, Stripe webhook'ları, service worker, SameSite=None; Secure çerezler veya WebAuthn. Tarayıcı URL https:// ile başlayana kadar iş birliği yapmıyor — self-signed sertifikalar ya hiç çalışmıyor (Stripe onlara POST atmaz) ya da mkcert, certutil, tarayıcı trust store'ları ve işletim sistemi keychain'iyle yarım öğleden sonra heba oluyor.
Kısaca: Nodetonet yaklaşık 60 saniyede kararlı bir alt alan adına gerçek, otomatik yenilenen bir Let's Encrypt sertifikası verir. OAuth sağlayıcınız, Stripe, her webhook göndericisi ve tarayıcı hemen güvenir — self-signed uyarısı yok, her yeniden başlatmada yeni rastgele URL'yi yeniden kaydetmek yok.
Yerel HTTPS neden zor?
Geliştiricilerin başvurduğu üç yaklaşım ve her birinin keskin kenarı:
| Yaklaşım | Neyi çözer | Neyi bozar |
|---|---|---|
Self-signed cert + mkcert |
Kendi tarayıcınız güvenir | Stripe, Twilio, Slack ve harici webhook göndericileri güvenilmeyen sertifikaları reddeder |
chrome://flags "allow insecure localhost" |
Chrome uyarı vermez | Service worker'lar hâlâ gerçek secure context ister; push bildirimleri başarısız olur; PWA kurulumu engellenir |
| Genel tünelleme servisi | Gerçek sertifika, genel URL | Her yeniden başlatmada yeni rastgele alt alan adı tüm kayıtlı redirect URI'ları bozar; koltuk başına fiyat birikir |
Temel sorun şu: tarayıcılar ve harici servisler, sertifikayı kendi tarayıcınızda kabul edip etmediğinizi değil, tam TLS zincirini doğrular. Hepsini aynı anda tatmin edecek tek şey gerçek bir herkesçe güvenilen CA — Let's Encrypt gibi — dir.
Nodetonet yerel HTTPS geliştirmeye nasıl uyuyor?
Kontrol ettiğiniz bir alt alan adına (veya bizim sağladığımız bir alt alan adına) yönlendirilmiş, http://127.0.0.1:3000 hedefli bir HTTP tüneli oluşturun. Nodetonet edge'i otomatik düzenlenen, otomatik yenilenen bir Let's Encrypt sertifikasıyla TLS'i sonlandırır. O andan itibaren:
- Tarayıcınız tam geçerli bir sertifika zinciri görür — uyarı yok.
- Stripe webhook gönderir. Auth0 / Okta / Clerk redirect URI'ı kabul eder. Slack Events API payload'larını iletir. Hiçbiri olağandışı bir şeye güvenmek zorunda kalmaz.
- Service worker'lar origin gerçek bir HTTPS secure context olduğu için normal şekilde kaydolur ve kurulur. PWA kurulumu ve push bildirimleri çalışır.
- WebAuthn ve Credential Management API flag veya geçici çözüm gerektirmeden çalışır.
- Güvenli çerezler
SameSite=None; Secureile doğru şekilde set edilir ve iletilir.
Sertifikanın ötesinde Nodetonet bu iş yükü için geliştirici kalitesinde kontroller ekler:
- Rezerve, kalıcı alt alan adları —
uygulamam-dev.nodetonet.comajan yeniden başlatmalarında aynı kalır. OAuth sağlayıcınıza bir kez kaydedin, unutun. - Özel alan adı desteği —
dev.uygulamam.com'u CNAME ile yönlendirin; Stripe webhook meta verilerinde gerçek production alan adınızı görsün. - Tünel başına IP allowlist — test sırasında gelen bağlantıları Stripe'ın IP aralıklarıyla sınırlayın. Allowlist'lerin nasıl çalıştığı için IP izin/reddetme rehberimize bakın.
- Edge'de HTTP/2 — tarayıcının ağ paneli gerçek HTTP/2 frame'lerini gösterir, düşürülmüş bir bağlantıyı değil.
- Wildcard SSL kapsamı — tek bir sertifika tüm alt alan adlarınızı kapsar; wildcard SSL sertifikaları'nda ayrıntılar var.
- Peşin ödeme, abonelik yok — yalnızca tünel aktifken ödeme yapın. Kullandıkça-öde fiyatlandırma modelini okuyun.
Adım adım: 5 adımda localhost'ta HTTPS
- /auth/register'da hesap oluşturun ve küçük bir peşin kredi ekleyin.
- Geliştirme makinenize Nodetonet Windows ajan'ını (.exe) indirip çalıştırın.
- Panelde bir HTTPS tüneli oluşturun: hedef
http://127.0.0.1:3000, alt alan adıuygulamam-dev(uygulamam-dev.nodetonet.comsonucu verir). - Let's Encrypt'in sertifikayı düzenlemesi için yaklaşık 30 saniye bekleyin. Ardından URL'yi açın — yerel uygulamanız, her şeyin güvendiği gerçek HTTPS üzerinden sunuluyor.
https://uygulamam-dev.nodetonet.com/auth/callback'i OAuth sağlayıcınızın redirect URI listesine yapıştırın ve aynı URL'yi Stripe'ın webhook endpoint alanına ekleyin. Bitti — yeniden başlatmalar arasında yeniden kayıt gerekmez.
Ekip iş akışları için tüneli komut dosyasıyla çalıştırma
Ekipler genellikle tünelin geliştirme sunucusunun yanında otomatik başlamasını ister. Aşağıda REST API üzerinden tünel oluşturan, genel URL'yi yazdıran ve istek log'unu takip eden minimal bir shell betiği var — bir package.json dev:tunnel betiği veya CI önizleme ortamı için uygundur:
#!/bin/bash
set -e
API="https://nodetonet.com/api/v1"
TOKEN="${API_TOKEN:?API_TOKEN env degiskenini ayarla}"
# localhost:3000 hedefli bir HTTPS tuneli olustur
PROXY=$(curl -s -X POST "$API/proxies" -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d '{
"type": "https",
"target": "http://127.0.0.1:3000",
"subdomain": "uygulamam-dev"
}')
URL=$(echo "$PROXY" | jq -r '.public_url')
ID=$(echo "$PROXY" | jq -r '.id')
echo "Tunel hazir: $URL"
# Istek logunu her 2 saniyede takip et
while true; do
curl -s "$API/proxies/$ID/requests?limit=10" -H "Authorization: Bearer $TOKEN" | jq -r '.[] | "\(.ts) \(.method) \(.path) -> \(.status)"'
sleep 2
done
Bu betiği scripts/dev-tunnel.sh'e bırakın ve package.json'a "dev:tunnel": "bash scripts/dev-tunnel.sh" ekleyin. Python'da örnekler için Python'da programatik tünel oluşturma ve REST API hızlı başlangıç rehberine bakın.
Nodetonet ile webhook geliştirme
Yerel HTTPS webhook hikayesinin yalnızca yarısıdır. Diğer yarısı gerçekte neyin geldiğini incelemek, tekrarlamak ve hata ayıklamaktır. Nodetonet tünelleriyle iyi çalışan birkaç uygulama:
- İstek incelemesi — REST API üzerinden her gelen payload'ı kaydedin ve işleyicinizin çıktısıyla karşılaştırın. Mevcut olanlar için denetim log'ları rehberi'ne bakın.
- Alan adı izin/reddetme — çok kiracılı geliştirme için tüneli yalnızca kendi servislerinize kısıtlayın. Bkz. alan adı kısıtlamaları.
- Tünel sağlığını izleme — entegrasyon testi paketi çalıştırmadan önce tünelin ayakta olduğunu doğrulayın. Tünel sağlığını izleme'de ayrıntılar var.
Tünel doğru araç olmadığında
- Yalnızca tarayıcı için HTTPS. Yalnızca kendi uygulamanızın kendi tarayıcınızda güveni kazanması gerekiyorsa
mkcertücretsiz ve yeterlidir — tünel, harici trafik gerekmez. - Hava boşluklu veya çevrimdışı geliştirme. Tüneller giden internet bağlantısına ihtiyaç duyar. Çevrimdışıyken self-signed sertifikaya dönün.
- Milisaniye-altı gecikme profili çıkarma. Her istek edge üzerinden bir gidiş-dönüş ekler (~10–30 ms). OAuth ve webhook için sorun yok; zaman-kritik bir şeyi profillerken ölçmeye değer.
İlgili Nodetonet kapasiteleri
HTTP tünelleri Nodetonet'in sunduklarının yalnızca bir katmanıdır. Aynı panel ayrıca mobil proxy, dönen proxy havuzu, SOCKS5 proxy, coğrafi hedefleme ve tam VPN çalıştırır — hepsi aynı peşin krediye faturalanır, özellik başına abonelik yok. Alternatifler değerlendiriyorsanız Nodetonet vs ngrok veya Nodetonet vs Cloudflare Tunnel'a bakın.
Test etmeye hazır mısınız? Ücretsiz hesap oluşturun, beş dakikadan az sürede tüneli kurun ve self-signed sertifika savaşını geride bırakın.