要点
表示される症状と安定した error ID から開始します。可能性の高い層を先に確認し、安全なコマンドと期待出力を使い、変更は 1 つずつ行い、edge-ready のルートと実際の外部リクエストで復旧を確認します。
診断の流れ
- error ID、agent version、OS、route state、時刻を記録します。
- loopback でローカルサービスを単独確認します。
oxaa routes listとoxaa diagnose --networkを実行します。- 実際の出力をドキュメントの期待状態と比較します。
- 最小の安全な修正を適用します。
- 新しい外部リクエストを送り、ローカル response を確認します。
- 復旧しない場合は、確認・マスキング済み診断をサポートへ送ります。
技術詳細
- 安定した症状または error ID
- 診断確率順の原因
- 安全な診断 command と期待する出力
- 修正方法と再試行の安全性
- edge-ready と外部 request による復旧確認
- 機密情報を除いた escalation package
トラブルシューティング
最初にローカルプロセス、ポート、scheme を確認します。次に認証と時刻、DNS、UDP/443、TCP/443 fallback、社内 proxy または TLS interception、ルート所有状態、edge-ready を確認します。oxaa routes list、oxaa diagnose --network、安定した error ID を使用し、共有前に secret、body、プライベートパスを除去します。
トラフィックと Inspector データの扱い
Oxaa の公開エッジでは、正確なホスト名を解決し、現在認証されているルートを特定してリクエストを転送するために公開 TLS を終端します。登録済みデバイスと Oxaa の間のセッションは暗号化され、そのセッションを通じて選択したローカルサービスだけにリクエストが届きます。
サービスの運用と保護に必要な範囲で、アカウント、ルート、使用量、セキュリティ、請求、サポート、診断のメタデータを保持します。Inspector の body キャプチャは通常の転送とは別の、明示的なデバッグ操作です。ローカル Inspector に表示される制限付きの request/response body コピーは開発者端末に残り、マスキング、即時削除、自動失効が可能です。公開トラフィックはエッジで処理されるため、「Oxaa はトラフィックを見られない」ではなく「Inspector のコピーはローカルに残る」と説明します。
クリーンアップと本番環境への移行
外部 callback、preview URL、DNS 設定を削除し、テスト用認証情報をローテーションし、ローカルキャプチャを削除してルートを停止します。必要に応じてデバイスまたはセッションを失効させ、本番トラフィックはデプロイ済みアプリ、production ingress、またはイベント配信基盤へ移行します。
Oxaa が行うこと・行わないこと
Oxaa は、登録済みデバイスと認証済みルートが有効な間、選択したローカル HTTP/HTTPS サービスを外部から利用できるようにする開発用接続です。アプリのホスティング、一般的な VPN、forward proxy、恒久的な本番配備、raw TCP/UDP トンネル、任意の TLS passthrough、CDN/WAF、または本番 Webhook 配信基盤ではありません。