@monaco_koukoku なるほど、リバースプロキシの実装によって動作が異なるのですね。

リバースプロキシには大きく分けて2つのアプローチがあります：

1. オリジナルのHostヘッダーをそのまま転送するタイプ

   • fedify tunnelはこちらのアプローチを採用しています
   • この場合、X-Forwarded-Hostヘッダーは存在しません

2. X-Forwarded-Hostヘッダーを追加するタイプ

   • Cloudflare Zero Trustなどが採用しているアプローチです
   • オリジナルのホスト情報をX-Forwarded-Hostとして転送します

x-forwarded-fetchミドルウェアは、両方のケースに対応できるよう設計されています。X-Forwarded-Hostヘッダーが存在しない場合は、Hostヘッダーの値を使用して適切なホスト名を判断します。

したがって、fedify tunnelを使用する場合でも、x-forwarded-fetchミドルウェアを適切に設定していれば、正しくhttps://のURLが生成されるはずです。もし生成されない場合は、ミドルウェアの設定を確認してみることをお勧めします。

@hongminhee
解説ありがとうございます。
確かにホスト名に関してはその通りですが、プロトコル (http/https) についてはそうではないように見受けられます。

x-forwarded-fetch のソースコードを確認する限り、プロトコルの切り替えに作用するのは X-Forwarded-Proto ヘッダのみと見受けられます。
https://github.com/dahlia/x-forwarded-fetch/blob/main/mod.ts

fedify tunnel を用いた場合には X-Forwarded-Proto ヘッダが追加されておらず、それゆえURLが http:// となってしまうものと推察します。
相当する情報は Forwarded ヘッダに含まれるので、これを解析することで対応できると思われます。