自宅のIPv6環境で git push がタイムアウトする原因と対策（CLI / SourceTree）
社内ネットワークからは問題なく git push が成功するのに、自宅回線から実行すると高確率でタイムアウトしたり、接続が強制終了される現象に遭遇しました。
本記事では、この現象の解決策から、裏で起きているネットワークの相性問題（PMTUDブラックホール現象）のメカニズム、および検証方法までをまとめます。
1. 発生した事象
自宅から git push を実行すると、数秒〜十数秒フリーズした後に以下のエラーを出力して失敗します。
$ git push
Connection to bitbucket.org closed by remote host.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
PC本体やSSH鍵の設定は社内と同じものを使っており、不備は見当たりません。
SSHのデバッグログ（ssh -vT）の挙動
...（前略）...
debug1: Offering public key: user@example.com ED25519 SHA256:xxxx agent
debug1: Server accepts key: user@example.com ED25519 SHA256:xxxx agent
Authenticated to bitbucket.org ([2401:1d80:3224:1:0:bbc:1:df7c]:22) using "publickey".
debug1: channel 0: new session [client-session] (inactive timeout: 0)
debug1: Entering interactive session.
debug1: pledge: filesystem
# ここで約10秒間、無言でフリーズする
Connection to bitbucket.org closed by remote host.
Transferred: sent 3304, received 2476 bytes, in 10.0 seconds
debug1: Exit status -1
ログの特徴：
- SSHの鍵認証自体は一瞬で成功している。
- 接続先が IPv6のアドレス になっている。
- 認証直後、実際のデータをやり取りしようとした瞬間にフリーズして切断される。
2. 原因の簡易推定：PMTUDブラックホール現象
この「認証（小さなパケット）は通るが、実際のデータ（大きなパケット）になった途端に無言で切れる」というのは、インターネットの経路上のセキュリティフィルターとIPv6の仕様がバッティングした際に発生する、「PMTUD（Path MTU Discovery）ブラックホール現象」の典型的な挙動です。
個人でインターネット上の経路やプロバイダの設定を変えることは不可能です。そのため、手元の環境で「最初からIPv4での通信を強制して回避する」のが最も現実的な解決策になります。
3. 対策方法
環境に合わせて、以下のいずれかの設定を行ってください。
💡 コマンドライン（CLI）Git の対策
対策1：~/.ssh/config にIPv4強制を設定する（おすすめ）
Bitbucketへの接続時に、常時IPv4を強制するオプション AddressFamily inet を追記します。
Host bitbucket.org
HostName bitbucket.org
User git
IdentityFile ~/.ssh/id_ed25519 # 自身の鍵パス
AddressFamily inet # これをつけるとIPv4強制になる
※ Host bitbucket.org の宣言漏れやインデントミスがあると、別のホスト設定に吸い込まれて無視されるので記述位置に注意してください。
対策2：Gitコマンド単位でSSHオプションを強制する
# このリポジトリのみ対象
git config core.sshCommand "ssh -4"
# 全リポジトリを対象（グローバル設定）
git config --global core.sshCommand "ssh -4"
💡 SourceTree（GUI）の対策
CLIのGitで直っても、SourceTreeだと依然として push が遅い（または失敗する）ケースがあります。
これは、SourceTreeが起動時に独自の環境変数をセットするため、上記の ~/.ssh/config や core.sshCommand を無視してしまう仕様があるからです。SourceTreeでも設定を適用させるには、以下の変更を行います。
内蔵Gitから「システムGit」へ切り替える
- SourceTreeの「設定（
Cmd + ,）」> 「Git」 タブを開きます。 - 画面下部にある「Gitのバージョン」で、「システムGitを使用」 をクリックします。
- アプリを完全に再起動（
Cmd + Q）します。
これを行うことで、SourceTreeが内蔵GitではなくMac標準のGitおよびSSHを利用するようになり、~/.ssh/config の設定が正しく読み込まれるようになります。
4. 原因の詳細解説：PMTUDブラックホール現象とは？
なぜIPv4に強制するだけで直るのか、裏側のメカニズムの解説です。
- MTU（最大パケットサイズ）の低下：日本の自宅回線で主流の「IPv6 IPoE（v6プラスなど）」は、通信を高速化するためにデータへ専用の荷札（カプセル化ヘッダ）を付与します。そのため、1回に送れる最大パケットサイズ（MTU）が、通常の1500バイトから1460バイト前後に小さく制限されます（プロバイダの正常な仕様です）。
- IPv6の厳しい仕様：IPv4では、途中のルーターが気を利かせてパケットを自動で細切れに分割（フラグメント）して届けてくれます。しかしIPv6では、ルーターの負荷軽減のため「途中のルーターによるパケット分割が完全に禁止」されています。
- エラー通知の消失（ブラックホール化）：本来なら、サイズオーバーしたパケットを落としたルーターが、送信元（PC）に対して「大きすぎて通せないから小さくして！（ICMPv6 Packet Too Big）」というエラー通知を送り返します。しかし、インターネット上のどこかにあるファイアウォールが、「ICMPパケットは危険だから」と過剰にブロックしてしまうことがあります。
エラーの通知（ICMP）すら途中で闇に葬られて消えるため、PC側はパケットが消えた理由が分からず、ただ無言でデータを待ち続けてタイムアウトします。これがブラックホール現象です。IPv4に強制すると、最悪エラー通知が消えても経路上のルーターが自動分割して届けてくれるため、この問題が発生しなくなります。
5. 原因の検証・確認方法
「自分の環境が本当にブラックホール現象なのか」を厳密に証明するための検証方法です。
検証①：IPv4での接続テスト
SSHに -4 オプションを付与し、IPv4での接続を強制します。
$ ssh -4 -vT git@bitbucket.org
...
Authenticated to bitbucket.org ([104.192.140.26]:22) using "publickey".
Entering interactive session.
authenticated via ssh key.
Transferred: sent 3516, received 2716 bytes, in 0.3 seconds
IPv4を指定した途端、わずか0.3秒で接続に成功する場合、原因がIPv6の経路上にあることが確定します。
検証②：Google DNS（IPv6）をターゲットにサイズ別Pingテスト
Bitbucketはセキュリティ上Ping（ICMP）を遮断しているため、IPv6のPingに応答してくれるGoogleのパブリックDNS（2001:4860:4860::8888）を相手に、パケットサイズを変えてテストします。
A. 小さいパケットサイズ（-s 1200 / 合計1248バイト）
$ ping6 -c 3 -s 1200 2001:4860:4860::8888
1208 bytes from 2001:4860:4860::8888, icmp_seq=0 hlim=115 time=7.459 ms
1208 bytes from 2001:4860:4860::8888, icmp_seq=1 hlim=115 time=7.532 ms
--- statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
小さいパケットは何の問題もなく応答が返ってきます。
B. 大きいパケットサイズ（-s 1450 / 合計1498バイト）
$ ping6 -c 3 -s 1450 2001:4860:4860::8888
1458 bytes from 2001:4860:4860::8888, icmp_seq=0 hlim=115 time=54.599 ms
--- statistics ---
3 packets transmitted, 1 packets received, 66.7% packet loss
サイズを通常の限界（1500バイト）のギリギリ手前まで大きくした途端、大半が完全に行方不明（66.7% packet loss）になり、返ってきた1通も応答時間が7倍（54.5ms）に激増します。
「パケットサイズを大きくした瞬間に、エラー通知（Packet Too Big）すら戻らずにパケットが消失する」という、PMTUDブラックホール現象の動かぬ証拠（再現データ）です。
6. まとめ
- 自宅のIPv6環境から特定の海外サービスへの接続がタイムアウトする場合、インフラの故障ではなくPMTUDブラックホール現象（相性問題）の可能性が高い。
- 解決には IPv4（
AddressFamily inetまたはssh -4）を強制する のが最も手軽で確実。 - GUIツール（SourceTree等）は独自に設定を上書きしがちなので、システムGitへの切り替えやホスト名エイリアスの活用が有効。