オフィス、大学、ホテルなどのネットワークでは、リモートMacへのVNCが自宅では通るのにLANでは失敗することがよくあります。本稿は2026年向けの症状の分類、直接接続とSSHローカル転送の意思決定表、ポートと許可リストの実務メモ、ビューアログの読み方をまとめます。およそ15分で「ブロック要因がローカルポリシーか、別ノードが必要か」を判断できるようにし、遅延・初回セットアップの記事へもリンクします。
1. 症状の4分類
「接続できない」は一種類の失敗ではありません。まず分類します。
- ハンドシェイクのタイムアウトや無限スピナー：非標準ポートのドロップ、短いNATタイムアウト、DNS不調など。まず出口ポリシーを疑う。
- TLSや証明書エラー：HTTPS/WSSゲートウェイで起きやすい。時刻ずれ、SSLインスペクション、正しいゲートウェイホスト名を確認する。
- 認証失敗：経路は通っている。資格情報、MFA、アカウントロックを確認し、SSHログインと突き合わせる。
- ログイン後に黒画面や切断：帯域、コーデック交渉、キープアライブが多い。遅延・帯域の自己診断と併用する。
2. 事前確認5項目
- ネットワークのA/B：テザリングで動きオフィスで失敗なら、企業側コントロールが濃厚。
- プロキシとPAC：ビューアがシステムプロキシを無視する場合や明示プロキシが必要な場合がある。挙動を比較する。
- DNS：
nslookup ノードのホスト名を実行。ポリシーが許す場合のみリゾルバ変更を検討。 - ビューアのビルド：正確なバージョンと画質設定をサポート用に記録。
- ノード情報の一式：ホスト、ポート、アクセス方式が揃っていないと原因の取り違えになる。
3. 意思決定表：直接VNCとSSHローカル転送
多くの企業はTCP 22を許可し590xをフィルタします。同じMacにSSHできるなら、VNCをSSHで包む。
| シナリオ | 推奨経路 | 利点 | 注意 |
|---|---|---|---|
| 自宅ブロードバンド、プロキシなし | 直接VNC | 遅延最小 | ポート到達が必須 |
| オフィスが590xをブロック、SSHは許可 | ssh -L 転送 | 許可されたチャネルを再利用 | セッション維持、sshdが転送を許可していること |
| HTTP/Sのみの出口 | ITの許可リストまたはベンダーのHTTPSゲートウェイ | コンプライアントな接続 | 無許可トンネルは避ける |
| SSLインスペクションでハンドシェイク破損 | IT例外または信頼できる企業CA | TLSを復旧 | エラーテキストと時刻を記録 |
転送の例（ユーザー、ホスト、ポートは置き換え）：
ssh -N -L 5901:127.0.0.1:5901 youruser@remote-mac-host
ビューアは 127.0.0.1:5901 に接続。転送先でリモート側がListenしている場所を確認する。ベンダー文書ではループバックの指定が異なる場合がある。
4. 実行7ステップ
nc -vz ホスト ポートでタイムアウトと即時拒否を区別。5. 許可リストとノード変更
全経路で同じタイムアウトならプロバイダに相談。企業Wi-Fiだけがダメならポリシーと許可リストがレバーになる。初回リモートMacチェックリストで基本設定ミスを除外する。圧縮と多重化の背景はSSHトンネルとVNCトラフィックの解説を参照。
- 古典的なディスプレイ番号：5900 + ディスプレイ番号（例 :1 は5901）。ベンダー文書に従う。
- 長時間SSH：
ServerAliveInterval 60を入れて途中切断を減らす。 - 企業SSLアプライアンスでは、ルートCAのインポートやプライベートゲートウェイの明示例外が必要なことがある。
6. FAQ
SSH転送は遅延を増やす？ CPUとRTTのオーバーヘッドはあるが、「遅くても動く」は「速くてブロック」よりマシ。
VPNの代わり？ 出口を変えることもある。ポリシー内で使う。
帯域の記事との関係？ 本稿は到達性。接続後は専用の帯域ガイドでMbpsとRTTを調整。
キャプティブポータル（ホテル、ゲストWi-Fi）：先にブラウザでログインを完了させる。登録まで非HTTPをブロックするポータルでは、認証前はVNCが壊れる。DNSを差し替えるポータルでは、承認後もノードのホスト名が正しく解決するか確認。
スプリットトンネルとフルトンネルVPN：フルはVNCを別出口に回しルールが良くなったり悪くなったりする。スプリットはオフィスローカル経路のままのことも。両方有効なとき、ビューアがどのインターフェースを使うか記録する。
IPv6のみの経路：オフィスがIPv6優先でエンドポイントがIPv4のみ（またはその逆）だと奇妙なタイムアウトが出る。明示的なv4/v6でのテストか、ベンダーのデュアルスタック案内を求める。
7. ITセキュリティ審査用エビデンスパック
「VNCが壊れた」だけではセキュリティチームは動きにくい。次を添付する。
- 宛先IPまたはホスト名、TCPポート、プロトコル（生VNCかTLSラップか）。
- UTCのタイムスタンプとローカルタイムゾーン。
nc -vz等でタイムアウトとRSTを示す出力。- 同一ホストへのSSH（22番）の成否。
- 同一ノートPCで個人テザリングなら同一クライアント設定で動くか。
この組み合わせで、パスワードや全パケットキャプチャを共有せず「出口ポリシーか」を答えやすくなる。ITがSSH転送のみ承認する場合は、本稿の転送例を引用し、ローカルポートは最小限に留める。
まとめ
制限ネットワークではポリシ境界で静かに失敗しがちです。同じノードがテザリングでは動きオフィスWi-Fiで死ぬなら、ハードより経路の問題です。ポート根拠なしにビューアを入れ直してもITは納得しにくい。調査結果・ログ・明確な許可依頼の方が早い。長期的には、グラフィカル承認に依存するiOS/macOSワークフローには、マルチリージョンノード、対応アクセス方式、ネットワークガイドを文書化しているプロバイダが必要です。そうでないと新しいSSIDのたびに同じ戦いの繰り返しになります。VNCとSSHの両方で届く専用リモートMacをレンタルし、接続手順が整理されたヘルプがあると、アドホックなトンネル工作よりエンジニア時間を節約できます。VNCMacはノードと接続ドキュメントのセットに力を入れ、ファイアウォールとの格闘よりリリースに時間を使えるようにしています。