はじめに
前回、mDNS という技術の説明から始まり、HTTPS テスト環境に mDNS を導入する方法について解説してきました。
今回は、過去記事「開発環境について/外部アクセス対応のHTTPSテスト環境の構築」で構築した環境へ実際に mDNS を導入し、その動作確認を行っていきたいと思います。
サーバー環境は、引き続き Windows 11 pro を使用します。また、外部端末として、iPhone を使用します。
使用した OS のバージョンは下記の通りです。
- Windows 11 pro : Windows 11 Pro 25H2 26200.9457
- iOS : iOS 27.0.1
※ iOS 上のブラウザには、Chrome を使用しています。
mDNS の導入作業
既存の HTTPS テスト環境に mDNS を導入していく形で作業をすすめたいと思います。作業手順は以下の通りです。
- Node.js の bonjour モジュールの導入
- LAN 内で使用するホスト名を含めた HTTPS 証明書の再作成
- Express サーバーに、bonjour 機能組み込み
- 再作成した証明書で HTTPS サーバーの再立ち上げ
- 動作確認
それでは、順番に詳しくみていきたいと思います。
1. Node.js の Bonjour モジュールの導入
1-1. ターミナルの起動
Windowsの場合:
以降の作業は管理者ではない「ターミナル」アプリのウインドウから、コマンド入力により作業を行っていきます。
- スタートボタンを右クリック
- 「ターミナル」をクリック
👉 これからの作業はすべて起動された「ターミナル」のウインドウに入力します。
1-2. テスト対象となるプロジェクトへの移動
テスト対象となるプロジェクトのフォルダーも、引き続き c:\Users\test\serverTest を使用します。
以下を入力:
cd c:\users\test\serverTest
1-3. bonjour モジュールの導入
mDNS 機能を提供する bonjour モジュールを導入します。
以下を入力:
npm install bonjour
2. LAN 内で使用するホスト名を含めた HTTPS 証明書の再作成
LAN 内で使用するホスト名を含めた HTTPS 証明書を再作成します。今回、ホスト名には mylocaldevserver.local を使用します。
以下を入力:
mkcert localhost 127.0.0.1 192.168.10.108 ::1 mylocaldevserver.local
👉 下記のファイルが作成されれば、成功です。
- localhost+4-key.pem
- localhost+4.pem
注)ファイル名( localhost+4 の部分)は、若干異なる場合があります。以降の作業は、作成された実際のファイル名に合わせてください。
3. HTTPS サーバーに、bonjour 機能組み込み
3-1. server.js ファイルの読み込み
server.js ファイルをエディタ(notepad)に読み込みます。
以下を入力:
notepad server.js
3-2. bonjour モジュールの読み込み部分追加
エディタ(notepad)上で、server.js に bonjour モジュールの読み込み部分を追加します。
※ 使用しているモジュール形式に応じて選択してください。.js ファイルの場合、一般的には package.json の type プロパティが "module" であれば ES Modules、"commonjs" または type の指定がなければ CommonJS として扱われます。以下のコードの主な違いは、モジュールの読み込み方法(require / import)です。
【 CommonJS の場合】
:
const https = require("https");
const fs = require("fs");
const express = require("express");
:
👇
:
const https = require("https");
const fs = require("fs");
const express = require("express");
const bonjour = require("bonjour"); // bonjour モジュール
:
【 ES Modules の場合】
:
import https from "https";
import fs from "fs";
import express from "express";
:
👇
:
import https from "https";
import fs from "fs";
import express from "express";
import bonjour from "bonjour"; // bonjour モジュール
:
3-3. Bonjour (mDNS) サービスの公開部分の追加
エディタ(notepad)上で、server.js に Bonjour (mDNS) サービスの公開部分を追加します。
※ 以降のコードは CommonJS / ES Modules 共通です。
:
// 静的ファイル
app.use(express.static("public"));
// HTTPS サーバー起動
https.createServer(
:
👇
:
// 静的ファイル
app.use(express.static("public"));
// Bonjour (mDNS) サービスの公開
const mdns = bonjour();
mdns.publish({
name: 'My Local Dev Server',
host: "mylocaldevserver.local",
type: 'https',
port: 3000
});
// HTTPS サーバー起動
https.createServer(
:
3-4. server.js 書き込み
メモ帳にて、server.js ファイルの HTTPS 証明書読み込み部分を調整して上書き保存します。
// HTTPS サーバー起動
https.createServer(
{
key: fs.readFileSync("localhost+3-key.pem"),
cert: fs.readFileSync("localhost+3.pem")
},
app
👇
// HTTPS サーバー起動
https.createServer(
{
key: fs.readFileSync("localhost+4-key.pem"),
cert: fs.readFileSync("localhost+4.pem")
},
app
※ ファイル名は、前述の「2. LAN 内で使用するホスト名を含めた HTTPS 証明書の再作成」で作成されたファイル名に合わせてください。
4. 再作成した証明書で HTTPS サーバーの再立ち上げ
Node.js コマンドで、Expressサーバーを起動します。
※ 既に Express サーバーが起動済みの場合は、該当ターミナルで Ctrl + C キーを入力して終了させてから、再度起動してください。
以下を入力:
node server.js
5. 動作確認
iPhone の Chrome ブラウザを起動し、URL 欄に 以下を入力:
https://mylocaldevserver.local:3000/
警告画面や警告表示がなく、サイトが表示されることを確認します。
IP アドレス指定の時と同様に、HTTPS接続によって Secure Context として扱われるため、Secure Context を必要とする OPFS も利用できます。
※ 使い方については、「データ保存技術/OPFS の動作確認(非同期操作)」を参照してください。
※ 筆者の環境では、 下記の組み合わせで確認を実施しています。いずれも問題なく、ホスト名でアクセス出来ています。
| OS | OSバージョン | ブラウザ | ブラウザバージョン |
|---|---|---|---|
| iOS | iOS 27.0.1 | Safari | 27.0.1 |
| iOS | iOS 27.0.1 | Edge | 153.0.4234.46 |
| iOS | iOS 27.0.1 | Chrome | 155.0.8059.37 |
| iOS | iOS 27.0.1 | Firefox | 157.0(77252) |
| Windows | Windows 11 Pro 25H2 26200.9457 | Edge | 154.0.4258.48(公式ビルド)(64 ビット) |
| Windows | Windows 11 Pro 25H2 26200.9457 | Chrome | 155.0.8059.12(公式ビルド)(64 ビット) |
| Windows | Windows 11 Pro 25H2 26200.9457 | Chromium | 157.0.8098.0(Developer Build) (64 ビット) |
| Windows | Windows 11 Pro 25H2 26200.9457 | Firefox | 157.0(公式ビルド)(64 ビット) |
| macOS | macOS Sequoia 15.7.3 | Safari | 26.2 (20623.1.14.18.4) |
| macOS | macOS Sequoia 15.7.3 | Edge | 154.0.4258.48(公式ビルド)(x86_64) |
| macOS | macOS Sequoia 15.7.3 | Chrome | 153.0.8010.53(公式ビルド)(x86_64) |
| macOS | macOS Sequoia 15.7.3 | Chromium | 157.0.8085.0(Developer Build)(x86_64) |
| macOS | macOS Sequoia 15.7.3 | Firefox | 157.0(公式ビルド)(64 ビット) |
| Linux | Arm64 版 Debian GNU/Linux 12 (bookworm) | Chrome | 153.0.8010.52(公式ビルド)(arm64) |
| Linux | Arm64 版 Debian GNU/Linux 12 (bookworm) | Chromium | 154.0.8037.92(公式ビルド)built on Debian GNU/Linux 12(bookworm)(arm64) |
| Linux | Arm64 版 Debian GNU/Linux 12 (bookworm) | Firefox | 157.0(公式ビルド)(aarch64) |
テスト環境で使用する OS やブラウザを限定できるのであれば、mDNS は非常に便利に使えます。
補足
時折、mDNS は不安定だという話を耳にすることがあります。
実は今回使用した際に、筆者の環境でも、mDNS のホスト名が検出できないことがありました。ただ、これは結果からいうと mDNS が不安定なわけではなく、筆者の環境のルーターに少し問題があったからでした。
現象としては、mDNS のマルチキャスト がまったくプライベートネットワークに送信されておらず、HTTPS サーバーの再起動、パソコンの再起動、ルーターの再起動、設定変更などを繰り返しているうちに、いつのまにかつながるようになるという不可解なものでした。
当初は、mDNS の環境が整うまでの遅延の可能性も疑ったのですが、あまりにも時間がかかりすぎることや、場合によっては、まったくつながらないままということもあったため、この可能性は排除しました。
そこで、ルーターの設定内容に問題があるのではとあたりをつけ、順番に設定を1つずつ確認しテストを繰り返したところ、筆者の環境では、DHCP の IP アドレス固定化設定との組み合わせで mDNS 通信に影響する現象が発生しました。
案の定、IP アドレスの固定化を外すと、いままでのことが嘘のようにサクサクとつながりだしたのです。逆に、再設定してみると、やはりマルチキャストが阻害されてしまいました。
調べてはみたのですが、残念ながらなぜそうなるかまではつきとめることができませんでした。ただ事実として、筆者の環境のルーターでは、IP アドレスの固定化と mDNS の共存ができないようです。それが、仕様なのかバグなのかも残念ながら不明です。
今回のようなケースは稀だとは思いますが、 mDNS がマルチキャストを前提にしていることから、ネットワーク環境によっては、似たような問題にぶつかる可能性が考えられます。
例えば、周波数の異なる無線 LAN や、有線 LAN が混在したネットワークで、マルチキャストが制限されている環境や、パケットの輻輳を避けるため、ルーターやブリッジがマルチキャストを制限している場合なども、似たような状況になると思われます。
このように、mDNS がうまくつながらなかったり、不安定な場合は、ネットワークを疑ってみることも必要です。