S3互換ストレージ(MinIO等)にWindowsから接続する — つまずくのは接続設定

MinIO や Ceph、各社のオブジェクトストレージを Windows から使うとき、手順書どおりに進めたのに繋がらない、ということがよくあります。原因はたいていマウントの手前、S3 の接続設定にあります。しかもその要件は、本家 Amazon S3 と S3 互換とで逆になっている項目があります。

最終更新: 2026年9月9日

この記事の内容

  1. パススタイルと仮想ホスト形式 — AWSと互換ストレージで要件が逆
  2. 署名バージョンとリージョン名
  3. リバースプロキシ越しの SignatureDoesNotMatch
  4. TLS と自己署名証明書
  5. 接続前に手元で確認できること

パススタイルと仮想ホスト形式 — AWSと互換ストレージで要件が逆

S3 の API には、バケットをどう指すかで2つの形式があります。

仮想ホスト形式とパススタイルの URL の違いを比較した図。仮想ホスト形式はバケット名がホスト名の一部になり Amazon S3 が必要とする。パススタイルはバケット名がパスの先頭に入り MinIO などの S3 互換ストレージが必要とする。
同じファイルを指す2つの書き方。バケット名がホスト名側に入るか、パス側に入るかが違います。

問題は、どちらが必要かが接続先によって変わることです。

つまり、AWS 用に書かれた手順をそのまま互換ストレージに使うと繋がらず、逆もまた同じです。

AWS にパススタイルで投げたときのエラー MovedPermanently や The bucket you are attempting to access must be addressed using the specified endpoint が返ります。
厄介なのは、これが HTTP 301 で返ってくるのに自動で追従できないことです。HEAD や List のレスポンスには本文が無く、正しいエンドポイントがどこかを読み取れないためです。「リダイレクトされているのに辿れない」という、原因の分かりにくい失敗になります。
互換ストレージに仮想ホスト形式で投げたとき バケット名.エンドポイント という FQDN を名前解決しようとして失敗します。DNS のエラーとして出るため、認証情報やバケット名を疑ってしまい、遠回りしがちです。

どちらが必要かの見分け方

エンドポイントのホスト名が amazonaws.com で終わるかどうかで判断できます。終わるなら仮想ホスト形式、それ以外はパススタイル、という切り分けが実用上ほぼ当たります。

S3 DriveBridge はこの判定を自動で行うため、利用者が選ぶ設定項目にはしていません。エンドポイント URL を入れれば、AWS 宛は仮想ホスト形式、それ以外はパススタイルで送ります。

署名バージョンとリージョン名

S3 の API リクエストは署名されます。現行は SigV4、古い実装向けに SigV2 があります。新しく構築した MinIO であれば V4 で問題ありません。V2 が要るのは、かなり古い互換実装や、一部の機器組み込みのオブジェクトストレージです。

見落としやすいのがリージョン名です。SigV4 の署名文字列にはリージョンが含まれるため、クライアントとサーバーで同じ値を使っていないと署名が一致しません。互換ストレージにはリージョンという概念が無いことも多く、その場合は既定値(us-east-1 など)が使われています。

「リージョンが無いから空でいい」とは限りません サーバー側が既定のリージョン名で署名を検証している場合、クライアント側も同じ文字列を指定する必要があります。空にすると別の値で署名され、SignatureDoesNotMatch になります。接続先のドキュメントで既定のリージョン名を確認してください。

リバースプロキシ越しの SignatureDoesNotMatch

互換ストレージを社内に置き、前段にリバースプロキシ(nginx、HAProxy、各種アプライアンス)を挟んでいる構成では、認証情報が正しくても署名が通らないことがあります。

原因は Host ヘッダーです。SigV4 は Host ヘッダーを署名対象に含みます。一方、リバースプロキシの既定動作は「転送先のホスト名や IP に Host を書き換えて渡す」ことが多く、そうなるとサーバーが受け取る Host はクライアントが署名したものと別物になります。結果は SignatureDoesNotMatch です。

リバースプロキシが Host ヘッダーを転送先のアドレスに書き換えると、クライアントが署名した Host と検証に使われる Host が食い違い SignatureDoesNotMatch になる仕組みと、Host をそのまま転送して解決した状態を並べた図。
上が既定のまま、下が Host を保持するようにした場合。認証情報は上下とも同じで、違うのは経路の途中で Host が書き換わるかどうかだけです。
認証情報を疑っても直りません アクセスキーもシークレットも正しく、ブラウザーからは管理画面が開ける。それでも API だけが弾かれる。この症状が出たら、まず Host ヘッダーを疑ってください。

対処

TLS と自己署名証明書

検証環境の MinIO では、自己署名証明書を使っていることがよくあります。この場合、多くのクライアントは証明書の検証に失敗して接続できません。

取れる方法は3つです。

  1. 正規の証明書を用意する。 社内向けでも、Let's Encrypt などで正規の証明書を取得できる構成にするのがいちばん後腐れがありません。
  2. 自己署名証明書(またはその CA)を Windows の証明書ストアに入れる。 「信頼されたルート証明機関」に配置すれば、OS の検証を通ります。
  3. TLS を使わない。 閉じた検証環境に限った話です。S3 の認証情報が平文で流れるため、業務データには使わないでください。
S3 DriveBridge には「証明書の検証をスキップする」設定はありません 意図的に用意していません。設定できてしまうと、検証環境で有効にしたまま本番に持ち込まれるためです。自己署名証明書を使う場合は、上の 2. のとおり Windows の証明書ストアに入れてください。

接続前に手元で確認できること

クライアントを設定する前に、次を押さえておくと切り分けが早くなります。

項目確認すること
エンドポイント URLスキーム(https:// か http://)とポート番号まで含めた完全な形。バケット名は含めない
パススタイル接続先が AWS 以外なら、まずパススタイルを前提にする
署名バージョン原則 V4。V2 が要るのは古い実装のみ
リージョン名サーバー側の既定値に合わせる。「無いから空」は誤り
Host ヘッダー前段にプロキシがあるなら、Host が保持されているか
証明書自己署名なら Windows の証明書ストアに入れておく

ここまで揃っていれば、あとはドライブとして見せる部分の話になります。Windows でファイルシステムとして扱うには WinFsp が必要です。

S3互換ストレージも、ドライブとして開けます

S3 DriveBridge は Amazon S3 のほか、MinIO などの S3 互換ストレージに対応しています。パススタイルは自動判定、署名バージョン・リージョン・TLS・HTTPプロキシは設定画面から指定できます。30日間、無料で試せます。

製品ページを見る