목표: LAN 안의 모든 기기(PC, 스마트폰, TV)에서 셋톱박스 없이 IPTV를 바로 시청
효과: 한 번 구축하면 집 안 모든 기기에서 시청 가능하고, 채널 전환 속도와 동시 시청 수를 직접 제어할 수 있습니다
난이도: 중간 —— 먼저 광 모뎀을 브리지 모드로 바꾸고, 그다음 NAS에서 Docker 컨테이너 하나를 실행해야 합니다
소요 시간: 약 30분
1. 왜 '멀티캐스트→유니캐스트'가 필요한가
멀티캐스트란
통신사의 IPTV는 멀티캐스트(Multicast)를 사용합니다. 하나의 데이터 스트림을 송신원에서 한 번만 보내면,
네트워크 안에서 그 채널을 '구독한' 모든 기기가 동시에 받습니다.
장점은 대역폭 절약입니다. 100명이 같은 채널을 봐도 통신사는 데이터를 한 번만 보냅니다.
문제: 일반 기기로는 멀티캐스트를 재생할 수 없음
멀티캐스트는 IGMP 프로토콜에 의존하는데, 이 프로토콜은 LAN 내부에서만 유효합니다.
문제는 다음과 같습니다:
- 스마트폰, 태블릿, 스마트 TV대부분이 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. 사전 조건 (이 두 가지를 반드시 먼저 완료)
### 1. 광 모뎀을 브리지 모드로
**이 단계는 필수입니다.** 광 모뎀이 아직 라우터 모드라면 IPTV의 VLAN 데이터가 NAS에 도달하지 않습니다.
전체 절차는 [광 모뎀 브리지 모드 가이드](/optical-modem-bridge-mode-tutorial)를 보시고, 여기서는 요점만 말씀드립니다:
- 광 모뎀 슈퍼 비밀번호를 확보합니다
- 기존 설정을 백업합니다
- 인터넷용 VLAN을 브리지로 변경하고 자체 공유기로 PPPoE 접속합니다
- **핵심**: IPTV의 VLAN은 **그대로 유지**하고 함께 브리지로 바꾸지 마십시오
### 2. 공유기 / 소프트웨어 라우터에서 IGMP 프록시 활성화
공유기의 IPTV 설정에서 **IGMP Proxy**(또는 IGMP Snooping / 멀티캐스트 프록시)를 켭니다.
시스템별 위치:
| 시스템 | 위치 |
|---|---|
| OpenWrt | 네트워크 → 인터페이스 → IPTV 인터페이스 → IGMP Proxy 체크 |
| iKuai | 고급 애플리케이션 → 멀티캐스트 설정 |
| ASUS | 내부 네트워크 → IPTV → IGMP Proxy 활성화 |
| Synology Router | 보통 별도 설정이 필요 없음 |
### 3. 통신사의 멀티캐스트 주소 확보
**멀티캐스트 주소는 지역과 통신사에 따라 다르며 범용 값이 없습니다.**획득 방법:
1. **패킷 캡처**：셋톱박스가 정상 재생 중일 때 공유기로 패킷 캡처하여 IGMP Join 패킷을 찾습니다
2. **인터넷 검색**：「[도시] [통신사] iptv 멀티캐스트 주소」로 검색
3. **설치 기사에게 문의**: 바로 알려 주는 경우도 있습니다
필요한 것은 다음 두 가지입니다:
- **VLAN ID**（예: 85, 3961 등 통신사마다 다름）
- **멀티캐스트 IP와 포트**(예: `239.125.2.66:4120`)
> 겸사겸사 현재 네트워크 환경도 확인해 보십시오:[NAT 유형 검출 도구](/nat-test.php)
---
## 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: 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** 로 시연합니다. 가장 시작하기 쉽고, 나머지 둘로 옮겨 갈 때의 방식도 완전히 같기 때문입니다.
---
## 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 설정을 생성하려면 를 참고하십시오.를 사용하십시오.
반드시 지켜야 할 세 가지
1. network_mode: host 는 필수
가장 많이 빠지는 함정입니다. udpxy는 멀티캐스트 트래픽을 직접 수신해야 하는데,
Docker의 기본 브리지 네트워크를 사용하면 를 참고하십시오..
따라서 network_mode: host 는 생략할 수 없습니다.
2. 포트 5893
udpxy는 5893 포트를 고정으로 사용하며 두 가지 기능을 함께 제공합니다:
http://NAS_IP:5893/status/http://NAS_IP:5893/restart/http://NAS_IP:5893/rtp/멀티캐스트IP:포트3. NAS 네트워크 설정
NAS와 IPTV VLAN이 같은 2계층 네트워크에 있어야 합니다.
흔히 쓰는 두 가지 방법:
- NAS 듀얼 NIC：한 포트는 일반 네트워크에, 다른 포트는 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'
: 채널 하나 테스트HTTP/1.0 200 OK 이 반환되면 포워딩이 정상입니다.
5. 플레이어에서 사용하기
주소 형식
이 변환 규칙만 기억하면 됩니다:
rtp://239.125.2.66:4120http://NAS_IP:5893/rtp/239.125.2.66:4120PC에서
mpv http://NAS_IP:5893/rtp/...TV / 셋톱박스
- Kodi: PVR IPTV Simple Client 애드온을 설치하고 m3u 재생목록을 가져옵니다
- 스마트 TV: TV 내장 플레이어를 쓰거나 VLC for Android TV를 설치합니다
- Apple TV: VLC 또는 Infuse 사용
권장 방법: 모든 채널 주소를 하나의 .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: 일부 채널만 볼 수 있는 이유는?
흔한 원인:
- 채널 목록이 불완전 —— 캡처한 멀티캐스트 주소는 그 시점에 셋톱박스가 구독한 것뿐입니다
- 일부 채널은 암호화됨 —— 셋톱박스 인증이 필요해 포워딩할 수 없습니다
- VLAN이 다름 —— 일부 통신사는 라이브와 다시보기 VOD를 다른 VLAN에 둡니다
Q5: 스마트폰을 Wi-Fi에 연결해 볼 수 있나요?
가능합니다. 스마트폰과 NAS가 같은 LAN에 있으면 됩니다.
다만 NAS가 IPTV VLAN에 있고 스마트폰이 일반 네트워크에 있다면 공유기에서 VLAN 간 라우팅를 참고하십시오.
Q6: 대역폭을 많이 차지하나요?
핵심 개념: 멀티캐스트는 LAN 내에서는 몇 명이 보든 대역폭을 한 몫만 사용합니다.
하지만 유니캐스트로 변환하면 시청자마다 한 몫씩 차지합니다를 참고하십시오.
기가비트 LAN이면 충분합니다. 다만 Wi-Fi라면 신호 품질에 주의하십시오.
Q7: 통신사가 내부 포워딩을 알아챌까요?
기술적으로: 포워딩은 사용자의 LAN 내부에서 일어나며, 통신사 측에서 보이는 것은 셋톱박스와 동일한 IGMP 구독입니다.
실제로는: 일부 통신사는 동시 구독 수를 제한하며(예: 2채널만 허용), 초과하면 거부합니다.
제안: 과도한 동시 시청은 피하십시오. 체감을 해칠 뿐 아니라 제한을 유발할 수 있습니다.
Q8 보충: 멀티 다이얼이 IPTV에 영향을 주나요?
영향을 줍니다. 단선 멀티 다이얼을 함께 사용하면 그로 인해 생긴 여러 회선 출구가 IPTV VLAN을 방해해,
셋톱박스가 IGMP 멀티캐스트를 받지 못할 수 있습니다.
제안: IPTV 인터페이스를 mwan3 부하 분산에서 제외하십시오. 구체적인 방법은
OpenWrt 단선 멀티 다이얼 가이드: mwan3로 속도 합치기를 참고하십시오.
Q8: Synology / QNAP / Zspace 모두 가능한가요?
모두 가능합니다. Docker만 돌아가면 됩니다.
유일한 차이는 네트워크 설정 방식 —— 단일 NIC과 듀얼 NIC은 설정이 다릅니다.
8. 정리
세 가지 방식을 한 줄로
가장 많이 빠지는 세 가지 함정
network_mode: host를 잊음 —— 멀티캐스트를 못 받아 '계속 로딩'으로 나타남- 광 모뎀이 아직 라우터 모드 —— VLAN이 NAS에 도달하지 않으니 먼저 브리지로
- 공유기 IGMP 프록시를 켜지 않음 —— 멀티캐스트 패킷이 LAN으로 들어오지 못함
핵심 가치
이 구성의 본질은 통신사의 IPTV를 '셋톱박스 한 대'에서 해방시켜,
'LAN 안의 하나의 HTTP 스트림'으로 바꾸는 것입니다 —— 이제 어떤 기기로든 볼 수 있고,
플레이어도 채널 목록도 자유롭게 고를 수 있습니다.
구축 비용은 거의 없습니다(NAS는 이미 돌고 있으니까요). 그리고 얻는 체감 향상은 매우 큽니다.