Jitsi Meet Docker のカスタムドメイン名の設定方法

Jitsi Meet Docker のカスタム ドメインへの最短の手順は、DNS ホスト名を Docker ホストに向け、最終的な HTTPS URL に設定し、同じホスト名に対して信頼できる TLS を構成し、WebRTC メディアが引き続き Jitsi Videobridge にアクセスできることを確認することです。インターネットに直接接続するインストールの場合、公式の Docker セットアップでは、、、およびPUBLIC_URLを介した組み込みの証明書自動化がサポートされています。ENABLE_LETSENCRYPTLETSENCRYPT_DOMAINLETSENCRYPT_EMAIL

このガイドではmeet.example.com、具体的な例として、標準のdocker-jitsi-meet プロジェクトを前提としています。例として示されているホスト名、メールアドレス、およびドキュメント専用の IP アドレスを、ご自身の値に置き換えてください。ここで説明する構成は、env.example2026 年 10 月 7 日時点で、公式の Jitsi Docker ハンドブックおよび最新のプロジェクトに対して検証済みです。

ドメインを変更する前に必要なもの

カスタムドメインは、証明書を要求する前にホスト名を決定しておくと最も効果的に機能します。たとえば、ユーザーが を開く場合https://meet.example.com、DNS、PUBLIC_URL、TLS証明書はすべて を使用する必要がありますmeet.example.com。jitsi.example.comと を混在させると、meet.example.com証明書の警告や誤ったホストへのリダイレクトが発生する一般的な原因となります。

• あなたが管理するドメイン。
• Docker EngineとDocker Composeがインストールされたサーバー。
• パブリックIPアドレス、または既にポート80と443を所有しているリバースプロキシ。
• ウェブポートおよびJitsiメディアトラフィックに対するファイアウォールアクセス。
• 既存のdocker-jitsi-meetディレクトリとその中の.envファイル。

Jitsi Docker の公式ハンドブックには、PUBLIC_URL本番環境でのデプロイには実際のドメインに設定する必要があると記載されています。また、標準的な直接設定におけるコア外部ポートとして、80/TCP、443/TCP、および 10000/UDP が挙げられています。Jitsi Docker のセルフホスティングガイドを参照してください。

ステップ1：カスタムホスト名をJitsiサーバーに向ける

使用したいホスト名に対応するAレコードを作成します。この例では、meet.example.comサーバーのパブリックIPv4アドレスを指しています。サーバーが安定したIPv6接続を確立している場合は、パブリックIPv6アドレスを指すAAAAレコードを追加することもできます。

Type: A
Name: meet
Value: YOUR_PUBLIC_IPV4
TTL: 300

図解から実際の環境にアドレスをコピーしないでください203.0.113.10。そのアドレスはドキュメント用に予約されています。プロキシ/CDNモードのDNSプロバイダを使用する場合は、プロキシが使用予定のJitsiトラフィックパターンをサポートしていることを確認するまでは、通常のDNSのみによる名前解決から始めてください。

ステップ2：.envファイルにPUBLIC_URLとHTTPSの値を設定します。

.envクローンまたは展開したディレクトリにあるファイルを開きますdocker-jitsi-meet。Jitsi Webコンテナがポート80と443で公開リッスンする直接デプロイの場合、重要な設定は次のとおりです。

PUBLIC_URL=https://meet.example.com
HTTP_PORT=80
HTTPS_PORT=443
ENABLE_HTTP_REDIRECT=1
ENABLE_LETSENCRYPT=1
LETSENCRYPT_DOMAIN=meet.example.com
LETSENCRYPT_EMAIL=admin@example.com
LETSENCRYPT_ACME_SERVER=letsencrypt

PUBLIC_URLこれは単なる見た目の問題ではありません。Jitsi は効果的な構成を構築する際にこれを使用するため、localhost や古いホスト名のままにしておくと、リンク切れや動作の不整合が発生する可能性があります。現在のプロジェクトサンプルでは、​​意図的に標準以外の HTTPS ポートを使用する場合は、そのポートを に含める必要があることも指摘されていますPUBLIC_URL。

公式サンプルでは現在、ZeroSSLがデフォルトのACMEサーバーとして指定されており、LETSENCRYPT_ACME_SERVER="letsencrypt"Let's Encryptを明示的に使用したい場合にも許可されます。既存のインストール環境で既に信頼できる証明書が正常に取得されている場合は、特に理由もなくプロバイダーを変更するのではなく、作業環境に合ったACME設定を維持してください。

ステップ3：必要なファイアウォールポートを開く

上記で説明したインターネットに直接接続するDockerデプロイメントの場合、80/TCP、443/TCP、および10000/UDPを許可してください。SSH管理ポートも開いたままにしてください。UFWを使用するUbuntuホストでの最小限の例は次のとおりです。

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw status verbose

ウェブポートは、サイト認証と証明書認証に使用されます。UDP 10000は、Jitsi Videobridgeのデフォルトのメディアポートです。メディアポートがブロックされている場合、ページは正常に読み込まれても、ミーティングが失敗したり、音声や映像が途切れたりすることがあります。そのため、HTTPSのみをチェックするだけでは不十分です。

ホストがNATの背後にある場合は、も確認してくださいJVB_ADVERTISE_IPS。公式ハンドブックでは、この変数はJitsi Videobridgeがメディア用にアドバタイズするアドレスを制御し、多くのLANまたはNAT展開で必要になると説明されています。一般的なパブリックインターネットの例は次のとおりです。

JVB_ADVERTISE_IPS=YOUR_PUBLIC_IPV4

ステップ4：新しいドメインでDockerスタックを再起動します

保存し.envてからコンテナを再作成し、環境変更を適用します。

docker compose down
docker compose up -d
docker compose ps

環境変数を変更した後は、単純なrestart方法は最善の選択肢ではありません。既存のコンテナ定義に以前の環境情報が残っている可能性があるためです。スタックを再作成することで、新しい環境変数PUBLIC_URL、ポート値、証明書設定が明示的に反映されます。

新規プロジェクトから始める場合は、まず公式のクイックスタート手順に従ってください。これには、必要なパスワードの生成や設定ディレクトリの作成が含まれます。最近のJitsiコンテナリリースでは、サービスは特権のないユーザーとして実行され、書き込み可能なストレージと一時ディレクトリが必要となるため、完全に新規インストールを行う場合は、古いサードパーティのチュートリアルではなく、最新のハンドブックに記載されているディレクトリコマンドに従ってください。

ステップ5：サーバー外部からDNSとHTTPSを確認する

DNSが伝播したら、ホスト名が期待されるパブリックアドレスに解決されることを確認してください。

dig +short meet.example.com

次に、HTTPSエンドポイントをテストします。

curl -I https://meet.example.com

応答が成功すれば、DNS、TCP 443、およびWebサービスが連携して動作していることが証明されます。ただし、マルチパーティメディアが正常に動作していることはまだ証明されていないため、これは最終確認ではなく中間確認です。

古いアドレスが返された場合はdig、DNSのTTLが経過するまで待つか、レコードを修正してください。DNSが正しくてもcurlタイムアウトする場合は、クラウドセキュリティグループ、ホストファイアウォール、ルーター/NATルール、およびポート443が他のサービスによって既に占有されていないかを確認してください。

ステップ6：証明書の発行とウェブログを確認する

ブラウザに証明書の警告が表示され続ける場合は、設定を繰り返し削除して別の証明書を要求するのではなく、Webコンテナのログを確認してください。

docker compose logs --tail=200 web

ACME検証エラー、ポートバインディングの失敗、ホスト名の不一致がないか確認してください。Jitsiハンドブックでは、認証局のレート制限について警告し、発行された証明書を含む構成ストレージを保持することを推奨しています。セットアップの実験を繰り返す際にはステージングが役立ちますが、ステージングから切り替えた後は、本番環境の証明書を要求する前に、古いステージング証明書の情報をWebストレージから削除する必要がある場合があるとハンドブックに記載されています。

既に別のソースから信頼できる証明書を取得している場合は、Jitsi は組み込みの ACME フローを有効にする代わりに、既存の証明書チェーン全体と秘密鍵を Web サービスにマウントすることもサポートしています。公式の既存証明書セクションにある証明書マウントの例を参照してください。

ステップ7：ブラウザでカスタムドメインを開きます

最新のブラウザでアクセスしてくださいhttps://meet.example.com。選択したホスト名でJitsiのランディングページが表示され、TLS接続が有効になっていることを確認してください。一時的な名前でテストルームを作成してください。

実際の会議にはHTTPSを使用してください。Dockerの公式ガイドでは、HTTPによる直接アクセスは、マイクやカメラへのアクセスなど、ブラウザのWebRTC APIの動作不良を引き起こす可能性があると具体的に警告しています。したがって、HTTPSは単なるセキュリティバッジではなく、機能構成の一部です。

ステップ8：ホームページだけでなく、実際の通話をテストする

可能であれば、2つの異なるデバイスまたはネットワークから同じルームに参加してください。各参加者が音声とビデオを送受信できることを確認してください。ウェブサイト自体は正しく表示されていても、VideobridgeのアドレスやUDPパスが間違っている場合があるため、2つのブラウザでテストを行うことが重要です。

NAT の背後にあるインストールでは、最初の接続は正常に見えるものの、参加者が増えるにつれてメディアが失敗するという症状がよく見られます。その場合は、JVB_ADVERTISE_IPSパブリック NAT マッピングと UDP 10000 を再確認してください。Jitsi ハンドブックには、HTTP トラフィックがリバースプロキシによって処理される場合でも、Videobridge メディア アドレスは有効であると明記されています。

リバースプロキシを使用すべき場合

上記の直接設定は、Jitsi Webコンテナがパブリックポート80番と443番を占有できる場合に適しています。同じサーバーで既にNginx、Apache、Caddy、Traefik、または他のプロキシがこれらのポートで実行されている場合は、Jitsiを同時にこれらのポートにバインドしようとしないでください。

同一ホストのリバースプロキシの場合、公式の Jitsi Docker ガイドでは、Jitsi コンテナ内で HTTPS を無効にし、内部 Web ポートを外部に公開しないようにし、リクエストをコンテナの HTTP イングレスに転送することを推奨しています。プロキシは WebSocket 転送もサポートする必要があります/xmpp-websocket。一般的な Jitsi 側の環境は次のとおりです。

DISABLE_HTTPS=1
ENABLE_HTTP_REDIRECT=0
ENABLE_LETSENCRYPT=0
PUBLIC_URL=https://meet.example.com

次に、リバースプロキシで信頼済み証明書を終了させます。これは、1つのプロキシで複数のアプリケーションの証明書を管理する場合に最適な方法です。外部から見えるURLを変更する必要はありませんPUBLIC_URL。ユーザーは引き続き最終的なHTTPSドメインを確認できます。

カスタムドメインの障害のトラブルシューティング

.envを編集した後も古いドメインが表示されたままです

コンテナを再作成するには、 にdocker compose down続いてを実行してくださいdocker compose up -d。また、.env実際に開始する Compose プロジェクトで使用されるファイルを編集したことを確認してください。

HTTPS証明書の検証に失敗しました

組み込みの直接証明書フローを使用する場合、DNSのA/AAAAレコードがチャレンジを受信するサーバーを指していること、およびパブリックポート80にアクセスできることを確認してください。docker compose logs web別のリクエストを行う前に、正確なACMEエラーを確認してください。

ページは読み込まれるが、参加者には音声も映像も表示されない。

UDP 10000 を確認し、NAT 環境の場合は正しい設定を行ってくださいJVB_ADVERTISE_IPS。リバースプロキシは Web トラフィックを処理するものであり、Videobridge のメディアパスを置き換えるものではないことに注意してください。

ブラウザは動作するが、モバイルアプリはサーバーを拒否する

証明書チェーンを確認してください。Jitsi Docker ハンドブックには、モバイルアプリはデフォルトの自己署名証明書では動作しないと記載されています。公開されている信頼できる証明書を使用するか、アプリが信頼できる証明書チェーンを受け取るようなインフラストラクチャ設計を使用してください。

最終確認チェックリスト

• meet.example.com意図した公開アドレスに解決されます。
• PUBLIC_URL=https://meet.example.comブラウザのURLと完全に一致します。
• TLS証明書は信頼されており、をカバーしていますmeet.example.com。
• 直接設定を行うには、ポート80/TCPとポート443/TCPにアクセスできます。
• UDP 10000番ポートがJitsi Videobridgeホストに到達します。
• JVB_ADVERTISE_IPSこれは、サーバーがNATの背後にある場合、または明示的にアドレスを公開する必要がある場合に正しいです。
• docker compose ps必要なコンテナが実行されていることを示します。
• 2人参加のテストで、音声と動画の送信に成功した。

これらのチェックに合格すると、カスタムドメインはJitsiを指すだけでなく、実際の会議で実際に重要な部分、つまりHTTPS、シグナリング、メディア転送についても設定されます。

公式資料

• Jitsi Meet セルフホスティングガイド — Docker
• docker-jitsi-meet env.example
• 公式のdocker-jitsi-meetリポジトリ