Fast answer
Local request inspector gives the visitor a direct answer, the exact product behavior, the limits that affect the decision and a practical path to verification.
Local request inspector explains the feature as a visible, testable workflow: what the user can do, which states and limits apply, how failures behave and which evidence supports each material claim.
Technical details
The release-gated implementation must cover:
token-protected loopback accessmetadata and header inspectionexplicit bounded request and response body capturemethod, path and status filterssensitive-field redactionvisible truncation, four-hour expiry and immediate deletionconfirmed replay for eligible requests with provider timestamp caveats
How traffic and Inspector data are handled
Oxaa's public edge terminates public HTTPS so it can resolve the exact hostname, identify the current authenticated route and forward the request. The session between the enrolled device and Oxaa is encrypted; the selected local service receives the request through that session.
Oxaa retains bounded account, route, usage, security, billing, support and diagnostic metadata required to operate and protect the service. Inspector body capture is a separate, explicit debugging action: the bounded request or response body copy shown by the local Inspector remains on the developer device and can be redacted, deleted or allowed to expire. Public traffic still has to be processed by the edge, so the accurate claim is local Inspector copies—not “Oxaa cannot see traffic.”
Troubleshooting
Start with the local process, port and scheme. Then check authentication and clock, DNS, UDP/443, TCP/443 fallback, corporate proxy or TLS interception, route ownership and edge readiness. Use oxaa routes list, oxaa diagnose --network and stable error IDs; review diagnostic output before sharing it and remove secrets, bodies and private paths.
Cleanup and production handoff
Remove the external callback, preview URL or DNS binding; rotate test credentials; delete local captures; stop the route; and revoke the device or session when appropriate. Move production traffic to the deployed application, production ingress or event-delivery platform designed for that job.
What Oxaa is — and is not
Oxaa is development connectivity for a selected local HTTP or HTTPS service while the enrolled device and authenticated route are live. It is not application hosting, a general VPN, a forward proxy, permanent production deployment, raw TCP/UDP tunneling, arbitrary TLS passthrough, a CDN/WAF replacement or a production webhook delivery platform.
Frequently asked questions
Does Oxaa deploy my application?
No. The application continues to run on the enrolled device. Oxaa forwards requests to the selected local service only while the authenticated route is live.
Do I need to open an inbound port?
Normally no. The enrolled device initiates the session. A restrictive network can still block DNS, UDP/443, TCP/443 or intercept TLS, so diagnostics remain important.
Where do Inspector body copies live?
When bounded capture is explicitly enabled, the copy displayed by the local Inspector remains on the developer device. Oxaa still processes public traffic and retains bounded operational metadata.
Is this production hosting?
No. Use a deployed application, production ingress or event-delivery platform for production traffic.
Complete the next real step
Continue with Open the Inspector when the current product, plan and country support that action. Use Read data handling to review the exact technical, trust or support path before committing.
oxaa login
oxaa http 3000