目標：LAN 内のあらゆる機器（パソコン、スマホ、テレビ）で、STB なしに IPTV を直接視聴できるようにする
効果：一度構築すれば家中のすべての機器で視聴可能。チャンネル切替速度や同時視聴数も自分で制御できます
難易度：中程度 —— まず ONU をブリッジモードにし、そのうえで NAS 上で Docker コンテナを 1 つ動かす必要があります
所要時間：約 30 分
1. なぜ「マルチキャスト→ユニキャスト」が必要なのか
マルチキャストとは
通信事業者の IPTV はマルチキャスト（Multicast）を使っています。1 つのデータストリームを送信元から一度だけ流し、
ネットワーク内でそのチャンネルを「購読している」すべての機器が同時に受け取ります。
利点は帯域の節約です。100 人が同じチャンネルを見ても、事業者が送るデータは 1 つだけです。
問題：一般の機器ではマルチキャストを再生できない
マルチキャストは IGMP プロトコルに依存しており、このプロトコルはLAN 内部でしか機能しません。
問題点は次のとおりです：
- スマホ、タブレット、スマートテレビの多くは IGMP に対応していない
- 対応していても、事業者のVLAN 付きマルチキャスト
- サブネットをまたぐ場合（Wi-Fi 機器など）はなおさら再生できない
結果として、あなたのセットトップボックスでは見られても、スマホ・PC・Apple TV では見られません。
マルチキャスト→ユニキャストで解決できること
LAN 内で転送サービスを動かします。これが行うのは：
- IGMP でマルチキャストストリームを購読する
- マルチキャストストリームを通常の HTTP ユニキャストストリームに変換する
- プレイヤーで HTTP アドレスを開ける機器なら、どれでも視聴できる
事業者のマルチキャストストリーム -> [NAS 上の転送サービス] -> HTTP ユニキャスト -> 任意の機器
rtp://239.x.x.x:4120 http://NAS_IP:5893/rtp/239.x.x.x:4120```
詳細な手順は [ を参照してください。](/optical-modem-bridge-mode-tutorial)。
---
## 2. 前提条件（この 2 つを必ず先に完了）
### 1. ONU をブリッジモードにする
**この手順は必須です。** ONU がルーターモードのままだと、IPTV の VLAN データが NAS に届きません。
詳細な手順は [ONU ブリッジモードの手順](/optical-modem-bridge-mode-tutorial) をご覧ください。ここでは要点だけ述べます：
- ONU のスーパーパスワードを入手する
- 元の設定をバックアップする
- インターネット用の VLAN をブリッジに変更し、自前のルーターで PPPoE 接続する
- **重要**：IPTV の VLAN は **そのまま維持** し、一緒にブリッジ化しないでください
### 2. ルーター／ソフトウェアルーターで IGMP プロキシを有効化
ルーターの IPTV 設定で **IGMP Proxy**（IGMP Snooping／マルチキャストプロキシと呼ばれることもあります）をオンにします。
システムごとの場所：
| システム | 場所 |
|---|---|
| OpenWrt | ネットワーク → インターフェース → IPTV インターフェース → IGMP Proxy にチェック |
| iKuai | 詳細アプリ → マルチキャスト設定 |
| ASUS | 内部ネットワーク → IPTV → IGMP Proxy を有効化 |
| Synology Router | 通常は追加設定不要 |
### 3. 事業者のマルチキャストアドレスを入手する
**マルチキャストアドレスは地域と事業者によって異なり、汎用的な値はありません。**取得方法：
1. **パケットキャプチャ**：STB が正常に再生している間に、ルーターでパケットキャプチャして IGMP Join パケットを探す
2. **ネットで検索**：「[あなたの都市] [事業者] iptv マルチキャストアドレス」で検索
3. **設置担当者に聞く**：直接教えてもらえることもあります
必要なのは次の 2 つです：
- **VLAN ID**（例：85、3961 など。事業者によって異なります）
- **マルチキャスト IP とポート**（例：`239.125.2.66:4120`）
> ついでに現在のネットワーク環境も確認しておきましょう：[NAT タイプ検出ツール](/nat-test.php)
---
## 3. 3 つの方式の選び方（核心）
結論から言うと：**この 3 つのツールは同じことをしており、違いはメンテナンス状況と性能です。**
### 方式 1：udpxy —— 最も古株で資料が最も多い
**これは中国語圏の IPTV で 10 年以上使われてきた方式です。**
| 項目 | 説明 |
|---|---|
| 長所 | Docker イメージが成熟（`ifmm/udpxy` は **19,691 回プル**）、チュートリアルが最多、落とし穴の情報も揃っている |
| 短所 | **公式は 4 年間メンテナンスされていない** |
| 向いている用途 | 初めての挑戦、単一機器での視聴 |
**知っておくべき事実**：udpxy の公式 README にもこう書かれています：
udpxy has not been extended or supported for 4+ years,
having been replaced by Gigapxy - a superior enterprise-oriented product.
**それは使えないという意味ではない** —— 10 年以上安定して動作してきただけで、更新が止まっているだけです。
ただし、より高い性能や新しい機能を求めるなら、次の 2 つを見てください。
### 方式 2：msd_lite —— udpxy の現代的代替
**名前は Multi Stream daemon に由来し、コミュニティで udpxy の代替として広く認められています。**
| 項目 | 説明 |
|---|---|
| 長所 | より軽量、リソース消費が少ない、性能が高い |
| 短所 | 中国語の資料は udpxy より少ない |
| 向いている用途 | OpenWrt ルーター、長期的に安定運用したい場合 |
**Enshan などのフォーラムで「udpxy 代替」を検索すると、真っ先に勧められるのがこれです。**
### 方式 3：rtp2httpd —— 機能が最も豊富
**このプロジェクトは「udpxy の現代版」を標榜しており、作者が V2EX で公開しました。**
| 項目 | 説明 |
|---|---|
| 長所 | 対応：**FCC 高速チャンネル切替プロトコル**に対応、RTP/RTSP など複数プロトコルをサポート |
| 短所 | 設定は udpxy よりやや複雑 |
| 向いている用途 | 複数機器の同時視聴、切替速度を重視する場合 |
### 比較まとめ
| 観点 | udpxy | msd_lite | rtp2httpd |
|---|---|---|---|
| メンテナンス状況 | 停止（4 年以上）| 活発 | 活発 |
| 導入難易度 | 最も低い | 中 | 中〜高 |
| リソース消費 | 中 | **低** | 中 |
| 切替速度 | 普通 | 良好 | **最高（FCC）** |
| 中国語資料 | **最多** | 中 | 少 |
| おすすめの用途 | 初めての挑戦 | 長期運用 | 体験重視 |
**：**：
- **初めて試す場合**：udpxy は情報が多く、問題が起きたときに調べやすい
- **安定運用後に最適化したい場合**：msd_lite に切り替える
- **複数機器＋切替速度重視**：rtp2httpd を選ぶ
udpxy**udpxy** を使って実演します。最も導入しやすく、他の 2 つへ移行する際の考え方もまったく同じだからです。
---
## 4. 実践：NAS 上で Docker を使って udpxy をデプロイ
### なぜルーターではなく NAS なのか
ルーターでも動きますが、NAS にはいくつか利点があります：
- **CPU が通常より強力**、多重同時配信でもより安定
- **24 時間稼働**、ルーターの負荷を気にしなくてよい
- **Docker の管理が簡単**で、更新やロールバックが容易
- ついでに他のもの（メディアライブラリなど）も動かせる
### docker-compose.yml
NAS の Docker ディレクトリの下に `udpxy` フォルダを新規作成し、このファイルを置きます：
```yaml
version: "2"
services:
udpxy:
image: ifmm/udpxy
container_name: udpxy
network_mode: host
restart: always
そして起動します：
docker-compose up -d
より複雑な compose 設定を生成したい場合は を参照してください。 をご利用ください。
必ず押さえるべき 3 点
1. network_mode: host は必須
これが最も踏みやすい落とし穴です。 udpxy はマルチキャストトラフィックを直接リッスンする必要があり、
Docker のデフォルトブリッジネットワークを使うと、** を参照してください。**。
そのため network_mode: host は省略できません。
2. ポート 5893
udpxy は 5893 ポートを固定で使い、同時に 2 つの機能を提供します：
http://NAS_IP:5893/status/http://NAS_IP:5893/restart/http://NAS_IP:5893/rtp/マルチキャストIP:ポート3. NAS のネットワーク設定
NAS と IPTV の VLAN が同じレイヤー 2 ネットワークにある必要があります。
よくある 2 つのやり方：
- NAS のデュアル NIC：1 つのポートを通常のネットワークに、もう 1 つを IPTV VLAN に接続
- スイッチのトランク：スイッチで IPTV VLAN を NAS に透過させる
バイパスルーター構成を使う場合は を参照してください。 を参照してください。
成功したか確認する
ステップ 1ステップ 1
http://NAS_IP:5893/status/
：ブラウザでステータスページを開く
**統計情報が見えればサービスは動いています。**ステップ 2
# マルチキャストアドレスが 239.125.2.66:4120 だと仮定
curl -I 'http://NAS_IP:5893/rtp/239.125.2.66:4120'
：1 つのチャンネルをテストするHTTP/1.0 200 OK が返れば転送は正常です。
5. プレイヤーでの利用
アドレス形式
この変換ルールだけ覚えれば十分です：
rtp://239.125.2.66:4120http://NAS_IP:5893/rtp/239.125.2.66:4120パソコン側
mpv http://NAS_IP:5893/rtp/...テレビ／STB
- Kodi：PVR IPTV Simple Client アドオンをインストールし、m3u プレイリストを読み込む
- スマートテレビ：テレビ内蔵プレイヤーを使うか、VLC for Android TV をインストール
- Apple TV：VLC または Infuse を使う
おすすめの方法：全チャンネルのアドレスを 1 つの .m3u ファイルにまとめれば、
プレイヤーに一度読み込ませるだけで全チャンネルを視聴でき、毎回アドレスを入力する必要がありません。
#EXTM3U
#EXTINF:-1, CCTV-1 総合
http://NAS_IP:5893/rtp/239.125.2.66:4120
#EXTINF:-1, CCTV-2 経済
http://NAS_IP:5893/rtp/239.125.2.67:4120
6. どの NAS なら動くか
良い知らせ：マルチキャスト→ユニキャストは I/O 集約型の処理で、CPU への要求は高くありません。
悪い知らせ：4K を複数同時に流す場合は、CPU とネットワークの両方に要求が出ます。
おおよその目安（実測ではないため、ご自身の環境で確認してください）
見落としがちな点：
- CPU よりネットワークポートが重要 —— ギガビットポートで 4K 3 路は厳しくなります
- NAS 上の他サービスがリソースを奪う —— Plex のトランスコードを同時に動かすなら余裕を残すこと
- ARM NAS でも動作する ——
ifmm/udpxyイメージは arm64 と armv7 に対応
特定モデルのスコアを調べたい場合は NAS CPU 性能ランキング の CoreMark 実測データをご覧ください。
7. よくある質問
Q1：再生できず、ずっと読み込み中のままです
この順序で切り分けてください：
- まずステータスページを確認（
/status/）が開けるか —— 開けなければコンテナが起動していません network_mode: hostを確認 —— これが最も多い原因です- マルチキャストアドレスが正しいか確認 —— 記憶に頼らずパケットキャプチャで照合してください
- ルーターで IGMP プロキシが有効か確認
- NAS が IPTV の VLAN にいるか確認
Q2：視聴できるがひどくカクつく場合の切り分けは？
まず「元ソースのカクつき」か「ネットワークのカクつき」かを切り分けます：
- 別のチャンネルを試す —— 特定のチャンネルだけなら元ソースの問題
- 有線接続で試す —— Wi-Fi でカクつき有線でカクつかないなら無線帯域の問題
- ステータスページのトラフィック統計を見る —— 転送自体がパケットを落としていないか確認
Q3：チャンネル切替に 3〜5 秒かかるのは正常ですか？
正常です。 マルチキャスト→ユニキャストの切替遅延は主に次に由来します：
- プレイヤーが HTTP リクエストを再発行する
- サービスが再度 IGMP Join する
- キーフレーム（I フレーム）を待つ
より速くしたい場合：FCC 高速チャンネル切替プロトコル に対応した rtp2httpd を使ってください。
Q4：一部のチャンネルしか視聴できないのはなぜ？
よくある原因：
- チャンネルリストが不完全 —— キャプチャしたマルチキャストアドレスは、その時 STB が購読していたものだけです
- 一部のチャンネルが暗号化されている —— STB の認証が必要で、転送できません
- VLAN が違う —— 事業者によってはライブと見逃し配信が別の VLAN にあります
Q5：スマホを Wi-Fi につないで見られますか？
見られます。スマホと NAS が同じ LAN にあれば問題ありません。
ただし NAS が IPTV VLAN にあり、スマホが通常ネットワークにいる場合は、ルーターでVLAN 間ルーティング を参照してください。
Q6：帯域を大量に消費しますか？
重要な考え方：マルチキャストはLAN 内では、何人が見ても帯域を 1 本分しか使いません。
ただしユニキャストに変換すると、視聴者ごとに 1 本分を消費します を参照してください。
ギガビット LAN なら十分ですが、Wi-Fi の場合は電波品質に注意が必要です。
Q7：事業者に LAN 内転送がバレますか？
技術的には：転送はあなたの LAN 内部で行われ、事業者側から見えるのは STB と同じ IGMP 購読です。
実際には：事業者によっては同時購読数を制限しており（例えば 2 路まで）、超えると拒否されます。
提案：過度な同時視聴は避けてください。体験を損なうだけでなく制限を誘発する可能性があります。
Q8 補足：マルチダイヤルは IPTV に影響しますか？
影響します。 シングルライン多段ダイヤルを併用している場合、それによって生じる複数の回線出口が IPTV の VLAN を妨害し、
STB が IGMP マルチキャストを受けられなくなることがあります。
提案：IPTV インターフェースを mwan3 の負荷分散から除外してください。具体的な方法は
OpenWrt シングルライン多段ダイヤルの手順：mwan3 による速度の集約 を参照してください。
Q8：Synology / QNAP / Zspace でも動きますか？
すべて動きます。Docker が動けば問題ありません。
唯一の違いはネットワーク設定の方法 —— シングル NIC とデュアル NIC では設定が異なります。
8. まとめ
3 つの方式を一言で
最も踏みやすい 3 つの落とし穴
network_mode: hostを忘れる —— マルチキャストを受け取れず「ずっと読み込み中」になる- ONU がルーターモードのまま —— VLAN が NAS に届かないので、先にブリッジ化する
- ルーターの IGMP プロキシを有効にしていない —— マルチキャストパケットが LAN に入ってこない
核心的な価値
この構成の本質は、事業者の IPTV を「1 台の STB」から解放し、
「LAN 内の 1 本の HTTP ストリーム」に変えることです —— これでどの機器でも視聴でき、
プレイヤーもチャンネルリストも自由に選べます。
導入コストはほぼゼロ（NAS はもともと動いているため）で、得られる体験の向上は非常に大きいものです。