mcpField
P
proxyman-https-capture

proxyman-https-capture

github.com/proxymanapp開発22204 回インストール10 週間前に更新
リポジトリ

proxyman-https-capture について

デバイス、ランタイム、ネットワーク条件に応じた Proxyman の HTTPS キャプチャ方法を選び、検証するスキルです。MCP を使った手順と手動のトラブルシューティングを案内し、設定変更前の同意を求めます。

主な機能

  1. 01対象に応じたキャプチャ方法の選択
  2. 02接続性と TLS の段階的な確認
  3. 03MCP によるセットアップと通信検証
  4. 04障害診断とロールバックの案内

活用シーン

  1. 01HTTPS 通信が表示されない問題の調査
  2. 02デバイスやランタイムに合う方法の選択
  3. 03Atlantis のキャプチャ経路の検証

MCP 対応

Proxyman MCP のツールとリソースを使ったセットアップ、証明書と SSL プロキシの確認、ガイド付き操作、通信確認を案内します。状態を変更する操作には事前の同意が必要です。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/proxymanapp/proxyman-skill.md --skill proxyman-https-capture

インストール後、Claude Code で/proxyman-https-captureを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
android-emulator.md
atlantis.md
capture-paths.md
runtime-capture.md

詳細

Proxyman HTTPS キャプチャ

ユーザーの正確なデバイス、ランタイム、ネットワーク、Proxyman プラットフォームに合わせて、動作する中で最も影響の少ないキャプチャ方法を選択してください。通常のプロキシキャプチャには、Proxyman 経由でトラフィックをルーティングすること、Proxyman CA を信頼すること、対象ホストの SSL Proxying を有効にすること、という互いに独立した 3 つの要件があります。Atlantis は、プロキシ/CA/SSL Proxying の経路を使わずに、検査したトラフィックを Proxyman に転送するインストルメンテーションの代替手段です。Atlantis 固有の制限と検証方法を適用してください。

ツールが見つからない場合は proxyman-mcp-setup を、キャプチャしたフローを調べる場合は proxyman-traffic-debugging を、ホスト Mac で生成されたルート証明書/カスタムルート証明書のライフサイクルやカスタムサーバー/クライアント ID については proxyman-certificates-recovery を使ってください。セットアップ手順以外の最新の公式ドキュメントが必要な場合は proxyman-debugging-tools を使ってください。

必要最小限の情報を集める

以下を確認してください。

  • Proxyman を実行しているホスト OS とアプリのバージョン。
  • 対象の種類、OS/ランタイムのバージョン、実機かシミュレーター/エミュレーターか、デバッグビルドか本番ビルドか。
  • 対象がホストに接続する方法と、VPN、MDM、ファイアウォール、プロキシ、証明書ピンニングの有無。
  • 対象のホスト名と、HTTP は表示されるが HTTPS は読めない状態か、トラフィックがまったく表示されない状態か。
  • ユーザーが GUI の手順、MCP による自動化、手動コマンドのどれを希望しているか。

ユーザーの承認を得るまでは、証明書のインストール、エミュレーターの root 化、システムプロキシの変更、シェル/アプリのインジェクション、対象の再起動を行わないでください。

共通のキャプチャモデル

次の順序で診断してください。

  1. 到達性: 対象が Proxyman を実行しているホストに到達できること。
  2. ルーティング: 対象が HTTP/HTTPS を Proxyman の現在のプロキシホストとポートに送信していること。
  3. 記録: Proxyman が記録中で、送信元/クライアントが表示されていること。
  4. 信頼: 対象が、該当するストア内の正しい Proxyman ルート CA を信頼していること。
  5. SSL Proxying: 対象のホストが含まれており、除外されていないこと。
  6. アプリケーションの動作: ライブラリによるプロキシのバイパス、localhost の特殊な扱い、VPN、ピンニング、QUIC/HTTP3、カスタムの信頼ストア。

証明書をインストールしたことを、ルーティングが機能している証拠と見なさないでください。また、SSL Proxying が有効なことを、対象が CA を信頼している証拠と見なさないでください。

方法を選ぶ

判断マトリクスと公式ページへのリンクについては、キャプチャ方法を読んでください。ユーザーが Atlantis とは何かを尋ねた場合、VPN が通常のプロキシをブロックしている状況でのキャプチャを必要としている場合、または Atlantis をアプリに統合したい場合は、Atlantis によるキャプチャを読んでください。

  • システムプロキシに従うデスクトップブラウザー/アプリ:システムプロキシとホストの証明書信頼を使用します。
  • iOS/iPadOS/Vision Pro デバイス:Wi-Fi の手動プロキシとデバイスの証明書信頼を使用します。インストルメンテーションライブラリを組み込める対応アプリでは、プロキシ/証明書のセットアップを避けたい場合や、VPN が通常の経路をブロックしている場合に Atlantis を検討してください。
  • Apple シミュレーター:起動中のシミュレーターに CA をインストールし、シミュレーターのプロキシ経路を使用します。
  • tvOS/watchOS:実機/シミュレーターに応じた公式の手順に従ってください。
  • Android 実機:OS とアプリのポリシーに適したユーザー/システム CA の方法と、Wi-Fi の手動プロキシを使用します。
  • Android エミュレーター:アクティブで互換性のある AVD には、Proxyman のガイド付き自動化を優先してください。Android エミュレーターの安全性を読んでください。
  • ターミナルランタイムまたはブラウザー:対応している場合は自動セットアップ/インジェクションを優先してください。対応していない場合は、ランタイムのキャプチャに記載されている明示的なプロキシ環境変数/オプションと、ランタイムの CA バンドル/ストアを使用します。
  • localhost:明示的なプロキシ設定またはリバースプロキシを使用します。多くのクライアントは意図的にシステムプロキシをバイパスします。
  • Docker/VM/サブシステム:127.0.0.1 をそのまま使うのではなく、そのネットワーク名前空間から到達できるホストアドレスを使用します。

MCP によるワークフロー

  1. get_version と get_proxy_status を実行します。
  2. 正確な対象、プラットフォーム、ランタイム、VPN、および症状を指定して answer_setup_question を実行します。
  3. 返された引用を読み、対象が曖昧な場合は list_setup_workflows を使用します。
  4. 通常のプロキシ経路では、get_certificate_status と get_ssl_proxying_list を確認します。Atlantis の場合は docs://setup/atlantis を読み、証明書や SSL プロキシの設定を無理に適用しないでください。
  5. 関連する組み込みリソースまたはプロンプトを使用します。セットアップ用リソースは、キャプチャ経路のリファレンスに記載されています。
  6. 自動化による状態の変更を説明し、同意を求めます。
  7. ライブサーバーで必要なアクションが利用可能で、ユーザーが承認した場合に限り、run_guided_setup、inject_terminal、inject_electron、set_system_proxy、install_certificate、または SSL ツールを使用します。
  8. 対象から既知の HTTPS リクエストを 1 つ生成します。
  9. filter_flows でホストを指定して検索し、必要に応じて client も指定します。get_flow_detail で詳細を確認します。
  10. HTTPS の本文が見えること、TLS/証明書の概要、および対象の識別情報を確認します。

MCP セットアップインデックスに完全一致する項目がない場合は、汎用的な代替結果を無理に使わず、proxyman-debugging-tools 経由で最新の公式ページを取得してください。

GUI ワークフロー

  1. 通常のプロキシ対象については、Proxyman のセットアップガイドまたは証明書ガイドを開きます。Atlantis の場合は、専用の統合リファレンスに従ってください。
  2. 実行中のアプリに表示されるプロキシのホスト/ポートを使用し、一般的なポートを固定で指定しないでください。
  3. 最新の公式ページにある、対象固有のルーティングと証明書の手順に従います。
  4. SSL プロキシは、必要なホストまたはワイルドカードに対してのみ有効にします。
  5. 再現可能なリクエストを生成し、Proxyman で確認します。
  6. プロキシ、信頼設定、エミュレーターのブートイメージ、または注入した環境を元に戻す方法を記録します。

障害の切り分け

  • 何も表示されない: 記録、ルーティング、到達可能性、またはクライアントの送信元に関する問題です。
  • HTTP は表示されるが、HTTPS は表示されない: ルーティングは機能しています。対象の信頼設定、SSL プロキシ、ピンニング、HTTP3/QUIC、またはカスタム CA ストアを確認してください。
  • TLS エラー: 正しい CA、完全な信頼、ホストの対象/除外設定、アプリのピンニング、および日付/時刻を確認します。TLS 検証の無効化を標準的な解決策として案内しないでください。
  • 一部のライブラリだけ表示されない: そのライブラリは環境/システムプロキシを迂回しているか、別の信頼ストアを使用している可能性があります。
  • デバイスが接続できない: 同じネットワーク上にあること、またはルーティング可能なホストアドレス、ファイアウォール/アクセス制御、現在のポート、および VPN/プライベートリレーの動作を確認してください。
  • ローカルホストが表示されない: ループバック以外の対象アドレスを使用して、リバースプロキシまたは明示的なプロキシ設定を利用します。
  • iOS で VPN が競合する: デバイスのプロキシを繰り返し変更するのではなく、ユーザーが管理するビルドに適した Atlantis の判断手順を確認してください。
  • Android アプリがユーザー CA を拒否する: デバッグ用ネットワークセキュリティ構成、または管理された互換性のあるエミュレーターのシステム CA 経路を使用してください。本番アプリでピンニングを回避するよう案内しないでください。

検証チェックリスト

次の条件を満たした場合にのみ、セットアップは完了です。

  • 想定した対象/クライアントを識別できる。
  • テストリクエストとレスポンスが表示される。
  • HTTPS ヘッダー/本文が、意図した経路を通じて読み取れる。通常のプロキシキャプチャでは復号され、想定した Atlantis の送信元では転送されている。
  • 通常のプロキシ経路を使用した場合、無関係なホストに対して SSL プロキシを不必要に有効にしていない。
  • ユーザーがロールバック方法を把握している。
  • ピンニング、本番ビルド、VPN、root/Magisk、またはサポート対象外の自動化などの制約が明示されている。

コメント