Kurzantwort
Dieser Leitfaden verbindet eine reale Testanfrage von LINE mit lokal laufendem Code. Veröffentlichung erst nach eigenem Sandbox-Test, Prüfung aktueller offizieller Quellen und benanntem Wartungsverantwortlichen.
Schritt für Schritt
- Provider-Sandbox oder Testkonto, Event-Typ, Secret und minimalen lokalen Handler vorbereiten.
- Lokalen Handler starten und deterministischen Health-Endpunkt prüfen.
- Oxaa installieren/anmelden,
oxaa http <port>ausführen und auf Edge-Bereitschaft warten. - Exakte HTTPS-URL und Pfad in der aktuellen Provider-Einstellung eintragen.
- Echtes Provider-Testevent auslösen.
- Provider-Delivery, Oxaa-Metadaten und Antwort des lokalen Handlers bestätigen.
- Raw Body/Signatur, Zeitstempel, Retry und Trusted-Proxy-Verhalten prüfen.
- Begrenztes lokales Capture nur bei Bedarf aktivieren; sensible Daten redigieren und löschen.
- Oxaa-Replay nur für geeignete Requests nutzen; bei frischen Zeitstempeln oder Tokens Provider-Redelivery anfordern.
- Callback entfernen, Test-Secret rotieren, Captures löschen und Produktion an bereitgestellten Endpunkt oder Event-Plattform übergeben.
LINE-spezifische Prüfung
Konfigurieren Sie die aktuelle Webhook- oder Callback-Einstellung von LINE mit exakter Oxaa-URL und Pfad. Lösen Sie ein echtes Test-Event aus und prüfen Sie Provider-Delivery, Oxaa-Request-Metadaten und lokale Anwendungsantwort. Der Produktionsleitfaden muss Channel Secret, X-Line-Signature und Gültigkeit des Reply Token validieren.
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.