Laravel-App über localhost mit HTTPS veröffentlichen

Kurzantwort

Führen Sie ein getestetes Laravel-Fixture lokal aus, veröffentlichen Sie nur den ausgewählten Port und bestätigen Sie eine echte externe Anfrage. Die Seite muss stack-spezifisches Verhalten lösen – Host-, Proxy-, Cookie- und Realtime-Verhalten – statt den allgemeinen Schnellstart zu wiederholen.

Schritt für Schritt

1. Verwenden Sie unterstützte Laravel- und Oxaa-Versionen sowie den festgelegten Beispiel-Commit.
2. Starten Sie die Anwendung mit php artisan serve oder dem dokumentierten Entwicklungsbefehl des Repositorys.
3. Prüfen Sie einen deterministischen lokalen Health-Endpunkt auf Loopback.
4. Führen Sie oxaa login und oxaa http <port> aus; warten Sie auf Edge-Bereitschaft.
5. Öffnen Sie die öffentliche URL aus einem zweiten Netz oder einer Provider-Sandbox.
6. Testen Sie die relevanten stack-spezifischen Host-, Proxy-, Cookie-, Redirect-, Raw-Body- und Realtime-Eigenschaften.
7. Bestätigen Sie lokale Logs, Antwort und Inspector-Zustand.
8. Stoppen Sie die Route, entfernen Sie temporäre Konfiguration und archivieren Sie die getestete Version.

Laravel-spezifische Besonderheiten

• Getestete Framework- und Oxaa-Versionen
• Funktionierendes Beispiel-Repository und lokaler Startbefehl
• Oxaa-Befehl und Edge-ready-Ausgabe
• Stack-spezifisches Host-, Proxy-, Cookie- oder Realtime-Verhalten
• Echte externe Anfrage, erwartete Ausgabe und häufige Fehler
• Aufräumen und Links zum passenden Provider oder Anwendungsfall

So verarbeitet Oxaa Traffic und Inspector-Daten

Am öffentlichen Edge wird TLS beendet, damit Oxaa den exakten Hostnamen auflösen, die aktuell authentifizierte Route ermitteln und die Anfrage weiterleiten kann. Die Sitzung zwischen dem registrierten Gerät und Oxaa ist verschlüsselt; über diese Sitzung erreicht die Anfrage ausschließlich den ausgewählten lokalen Dienst.

Oxaa speichert begrenzte Konto-, Routen-, Nutzungs-, Sicherheits-, Abrechnungs-, Support- und Diagnosedaten, die für Betrieb und Schutz des Dienstes erforderlich sind. Body-Capture im Inspector ist eine getrennte, ausdrücklich aktivierte Debugging-Funktion: Die begrenzte Kopie des Request- oder Response-Bodys, die im lokalen Inspector angezeigt wird, bleibt auf dem Entwicklergerät und kann redigiert, sofort gelöscht oder automatisch ablaufen gelassen werden. Der öffentliche Traffic muss am Edge verarbeitet werden; korrekt ist daher „lokale Inspector-Kopien“, nicht „Oxaa kann den Traffic nicht sehen“.

Fehlerbehebung

Prüfen Sie zuerst lokalen Prozess, Port und Schema. Danach folgen Authentifizierung und Uhrzeit, DNS, UDP/443, der TCP/443-Fallback, Unternehmensproxy oder TLS-Interception, Routenbesitz und Edge-Bereitschaft. Verwenden Sie oxaa routes list, oxaa diagnose --network und stabile Fehler-IDs; prüfen und bereinigen Sie Diagnoseausgaben vor dem Teilen.

Aufräumen und Übergabe an Produktion

Entfernen Sie externe Callback- oder Preview-URLs und DNS-Bindungen, rotieren Sie Test-Zugangsdaten, löschen Sie lokale Captures, stoppen Sie die Route und widerrufen Sie Gerät oder Sitzung, wenn dies erforderlich ist. Produktiven Traffic übergeben Sie an die bereitgestellte Anwendung, einen produktiven Ingress oder eine dafür ausgelegte Event-Delivery-Plattform.

Was Oxaa ist – und was nicht

Oxaa ist eine Entwicklungsverbindung für einen ausgewählten lokalen HTTP- oder HTTPS-Dienst, solange das registrierte Gerät und die authentifizierte Route aktiv sind. Oxaa ist kein App-Hosting, kein allgemeines VPN, kein Forward Proxy, keine dauerhafte Produktionsbereitstellung, kein Raw-TCP/UDP-Tunnel, kein beliebiger TLS-Passthrough, kein CDN/WAF-Ersatz und keine Plattform für den produktiven Webhook-Versand.