前回、記事中に「旧サーバについては、ファイル移行中のフォールバック目的です。ファイル移動が終わったら削除可能です。」と書いていました。しかし、「削除可能」なのは、以下のようなリモートのキャッシュに記載されている旧URLアクセスへの対策を実施済みの前提となります。（書きわすれてた。）

すでにローカルストレージで運用しているMastodonサーバの場合、リモートのサーバにキャッシュされている投稿の内容は、古いメディアURLを参照しています。

ここは書き換わることがありません。どのぐらいの期間、投稿をキャッシュするのかもリモートサーバ次第です。
※基本ずっと残るものと考えたほうが良いでしょう。。

そのため、本来であればローカルストレージ上にすでにアップロードされている画像などのデータを残したままにする必要があります。しかし、それではせっかく移行したのに面倒で取り回しが悪いです。

悪い設定が増えてしまいますが、下記のように当該の旧URLへアクセスが合った場合、内部でオブジェクトストレージを参照するようにします。

尚、投稿やアカウント自体の削除に伴う画像の消去は考慮していません。使い方によっては危険なので、留意すべきです。

バケット内にoldという名前をつけ、そこに旧URLで参照させたいファイルをコピーします。

Mastodonのnginx（通常のセットアップで作成するリバースプロキシ）の前段に、HAProxyを配置する設計です。

Mastodonのnginxだけでも似たようなことは簡単にできると思います。Mastodonと密なnginxか、疎なHAProxyか、どちらの設定がどの程度複雑になるかを想定してを選ぶと良いかもです。
（前段にMastodonと疎結合なリバースプロキシが存在すると、VMのマイグレやマシンの更改時などに非常に便利とおもいますので、趣味が合う（？）方は是非。）

まずMastodonの通信を受けるFrontendを作成します。

frontend don-tls-fr<br>  http-request set-header X-Forwarded-Proto https<br>  http-request set-header X-Real-IP %[src]<br><br>  #本来のヘッダの使い方と違うのでここはお好みで<br>  http-request set-header X-Forwarded-For %[src]<br><br>  http-after-response add-header alt-svc 'h3=":443"; ma=31536000'<br><br>  #IP直打ちとかhostが違うときはこっち（設定例未記載）<br>  default_backend error-bk<br><br>  bind *:443 ssl crt pemファイルフルパス alpn h2,http/1.1<br>  bind [::]:443 ssl crt pemファイルフルパス alpn h2,http/1.1<br>  bind quic4@:443 ssl crt pemファイルフルパス alpn h3<br>  bind quic6@[::]:443 ssl crt pemファイルフルパス alpn h3<br><br>  #仮想的に旧Media URLでもアクセス可能とする措置<br>  acl ismastodonlocalfile path -i -m beg /system/media_attachments/<br>  acl ismastodonlocalfile path -i -m beg /system/accounts/<br>  #カスタム絵文字はあまり使っておらず、移行時に全て削除してしまったので以下で正常に移行できるかは謎。コメントアウトしておきます。<br>  #acl ismastodonlocalfile path -i -m beg /system/custom_emojis/<br>  acl ismastodonlocalfile path -i -m beg /system/site_uploads/<br><br>  #旧URL（/system/ 配下）のCache以外のアクセスをobj-bkへ転送<br>  use_backend obj-bk if { req.hdr(host) 丼FQDN } ismastodonlocalfile<br><br>  #通常アクセス<br>  use_backend don-bk if { req.hdr(host) 丼FQDN }

次にオブジェクトストレージと、Mastodon自体へのアクセスを行うBackendです。

こちらについては、一つ前の記事で作成したGWを経由する経路とします。

各サーバの結合度を下げたい場合は、上記GWと同様の設定を入れ込むのもありかと思います。（よしなに。）

backend obj-bk<br>  http-request set-path /バケット名%[path,regsub(^/system/,/old/)]<br>  http-request set-header X-Forwarded-Proto https<br>  http-request set-header Host オブジェクトストレージ参照用FQDN<br>  server obj-gw オブジェクトストレージ参照用FQDN:443 ssl verify none resolvers dns-resolver check<br><br>backend don-bk<br>  option httpchk GET /health<br>  http-check expect string OK<br>  http-request set-header X-Forwarded-Proto https<br>  http-request set-header host 丼FQDN<br>  server don-v6 [丼v6アドレス]:443 ssl verify none alpn h2,http/1.1 check-alpn http/1.1 check<br>  server don-v4 丼v4アドレス:443 ssl verify none alpn h2,http/1.1 check-alpn http/1.1 check<br><br>resolvers dns-resolver<br>  nameserver ns1 1.1.1.1:53<br>  nameserver ns2 8.8.8.8:53

実際に使っている設定から色々と書き換えているので、このまま動くかは分かりません・・・。が、参考にはなるかと思います。

うまく行けば/system/配下でもアクセス可能となるはずです。

追記
面倒なのでverify noneとしていますが、非推奨です。ちゃんと設定しましょう。

※アドバイスなどあれば、こっそり教えて下さい(^o^)(^o^)