レイヤ分け · 最小 ssh -L · ATS とキーチェーン · シナリオ表 · 5 ステップ検証
Windows を主力にクラウド Mac を借りる構成では、ビルドは通るのに Simulator から API だけがタイムアウト／TLS エラーというチケットが非常に多いです。原因の中心は localhost の帰属です。Simulator はリモート Mac 上で動くため、そこでの 127.0.0.1 はその Mac のループバックであり、開発用 PC 上の localhost:3000 とは別物です。本稿では現象のレイヤ分け、OpenSSH のローカル転送（ssh -L）の最小例と安全上の注意、ATS・自己署名・システムプロキシなど VNC がまだ必要な手順、シナリオ別の判断表、チケットに貼れる5 ステップ検証をまとめます。企業・学内ネットワークと SSH トンネル（デスクトップに届くか）、Git と同期方式、初回 30 分チェックリストとあわせて読むと、開通から連携まで一気通貫で整理できます。
問題を四層に分けると、無駄なコード変更を減らせます。A：リモート Mac 自体が外向き通信できない → 先にネットワーク記事へ。B：外向きは良いが、アプリが PC 上のループバックだけを指している → 転送か配置換えが必須。C：API が社内 RFC1918 上にある → まず VPN、必要なら踏み台経由でポートを寄せる。D：TLS／ATS／キーチェーン → 多くは対話ユーザの GUI で一度だけ通す必要があります。以下は現場で繰り返し見る誤認です。
いきなり Swift を疑う：リモート Mac のターミナルで curl -v http://127.0.0.1:PORT/health を先に実行し、届かなければアプリ以前の問題です。
Simulator を実機と同じとみなす：USB デバッグのような「PC 直結」はなく、スタックはクラウド Mac 上に閉じます。
転送を有効にしたつもりでバインド違い：右辺の IP／ポート、IPv6、 listen アドレスを突き合わせないとトンネルは空振りします。
ATS を丸ごと無効化：開発でもドメイン単位の例外に留め、本番ビルドに汚染しない運用を徹底します。
SSH だけで完結と期待：クライアント証明書やシステムの「ローカルネットワーク」許可は、Xcode と同じログインセッションのデスクトップで処理するのが早いです。
要点：チケット件名に「どのマシンの localhost か」を書くと往復が減ります。
目的：Windows 上の API（例 127.0.0.1:3000）を、リモート Mac から 127.0.0.1:別ポート として見せる。Windows からクラウドへ SSH し、リモート側ループバックをローカルサービスに結びます。
ssh -N -L 127.0.0.1:19000:127.0.0.1:3000 [email protected]
-N はシェルを開かず転送専用。リモート Mac 上の 19000 へ来た TCP は、SSH クライアント（Windows 側）を経由して 3000 に流れます。デバッグ用 baseURL は http://127.0.0.1:19000 を指します。社内別ホスト向けには右辺を差し替え、PC がその IP にルーチングできること（VPN 等）が前提です。チームでは 19xxx を連携用に予約し、README に三元組を固定して衝突を避けます。
安全：不必要に 0.0.0.0 へ公開しない；セッション断で転送も消えるためスリープや Wi‑Fi ローミングをログと突合せ；プロバイダの AllowTcpForwarding 制約を確認；禁止環境ではリモート Mac 上の nginx スタブやゲートウェイに寄せる。
転送は TCP の到達性を保証しますが、App Transport Security やサーバ／クライアント証明書の信頼は別問題です。開発では NSExceptionDomains をドメイン単位で置き、ルート CA をログインキーチェーンへ入れる操作は システム設定／キーチェーンアクセス の UI が要ります。SSH テキストセッションだけでは、Xcode と同じユーザで「信頼」ボタンを押したこととログを一致させにくく、再現性が落ちます。Charles／Proxyman などの HTTPS プロキシも初回トラストがグラフィカルです。
運用上は SSH＝転送と自動化、VNC＝一度きりの許可と突合せ と役割分担すると、平均復旧時間が安定します。無人 CI 用のスクリプト路線とは切り離し、インタラクティブなデバッグはデスクトップで完結させるのが 2026 年の実務では主流です。
転送は届くか、ATS／キーチェーンは信じるか——後者は VNC 向き。
| シナリオ | 推奨 | まだ VNC |
|---|---|---|
| API が Windows のみ | ssh -L でリモート環回へ | ATS、信頼アンカー、プロキシ |
| 社内セグメント | PC で VPN → 転送、または二段 | クライアント証明書のインポート |
| ホストヘッダ／mTLS | リモート nginx などで名前解決 | キーチェーン登録 |
| ヘッドレス CI のみ | SSH スクリプト | 署名失敗時の Organizer など |
| 共用ノード | ポート帯を人ごとに分離 | アカウントとプロビジョニングの分離 |
帯域と圧縮の話題は SSH トンネルとトラフィック を参照し、本稿はアプリ層と ATS にフォーカスします。
リモート環回プローブ：クラウド Mac で curl、HTTP／TLS エラーをそのまま貼る。
baseURL 整合：Swift／Flutter／RN の各層でホストが分裂していないか確認。
ATS スナップショット：Info.plist 例外ブロックを差分に添付。
SSH 健全性：キープアライブ、スリープで切れていないか。切断・スリープ後の復帰も参照。
VNC で一度：Safari／システム設定でプロキシと信頼をログと突合せてクローズ。
リモート Mac のループバックです。PC 上のサービスへは転送か再配置が必要です。
TCP については多くの場合はい。証明書とプライバシーは VNC が無難です。
curl → baseURL → ATS → SSH 生存の順で潰します。
そちらはデスクトップ到達。本稿は Simulator 向け API 接続です。
工数の多くは Swift の書き方より、どのマシンにループバックがあるかと信頼チェーンを誰がグラフィカルに完了させたかに吸われます。SSH だけに寄せるとキーチェーンとログがすれ違い、VNC だけではポート規約が曖昧になります。両方を Runbook 化すると平均復旧が安定します。
自前ハードはスリープや更新、減価償却のコストがあります。低スペック PC では IDE とバックエンドとトンネルでメモリが足りません。クラウド Mac を定額で借り、SSH と VNC の両方を公式導線で使うと、オンライン率とベースイメージは事業者側に寄せつつ、API と証明書の責務はチームに残せます。
ハードを増やしたくないが、本稿の VNC 確認まで含めたい場合は VNCMac のクラウド Mac を検討してください。主ボタンは 購入・申込ページ、比較は トップ からどうぞ。