Agora의 기업 방화벽 우회 전략 — Cloud Proxy와 Firewall Whitelist
병원이나 은행처럼 방화벽이 빡빡한 기업 망에서도 Agora 화상통화가 왜 끊기지 않을까? 답은 Agora가 직접 운영하는 우회 인프라에 있다. 이 글은 도메인과 포트만 열어주는 Firewall Whitelist와, UDP가 통째로 막힌 환경에서도 TCP 443으로 트래픽을 우회시키는 Cloud Proxy를 비교하고, 어떤 망에서 어느 쪽을 골라야 하는지 정리한다. SD-RTN 백본망이 그 안정성을 어떻게 떠받치는지까지 함께 짚는다.
목차(17개 항목)
- Agora가 제공하는 두 가지 방식
방식 1 — Firewall Whitelist (도메인 + 포트 허용)
방식 2 — Cloud Proxy (클릭 시 시각화)
- SD-RTN® 이란?
- 핵심 요약
Cloud Proxy 역할 상세
- Firewall Whitelist만으로 충분한가?
- Firewall Whitelist 설정
- 관련 글
- 참고 자료
Agora는 자체 솔루션으로 기업 방화벽을 우회합니다. 핵심은 Cloud Proxy입니다. 이 글에서는 Agora가 제공하는 두 가지 방식(Firewall Whitelist, Cloud Proxy)과, 언제 어떤 방식을 쓰면 되는지 정리합니다.
Agora가 제공하는 두 가지 방식
| 방식 | 설명 |
|---|---|
| 방식 1 | Firewall Whitelist — 도메인·포트 허용 |
| 방식 2 | Cloud Proxy — (제한된 환경용) |
방식 1 — Firewall Whitelist (도메인 + 포트 허용)
"IP 말고 도메인으로 허용해라"가 핵심입니다. 일반 TURN은 IP를 허용해야 하는데, Agora는 도메인 기반 허용을 권장합니다.
허용해야 할 도메인 (예시)
포트 허용
| 포트 | 타입 | 용도 |
|---|---|---|
| 443, 80 | TCP | 기본 통신 (HTTPS 포트라 거의 안 막힘) |
| 3478 | UDP | TURN 표준 포트 |
| 4700~5000 | UDP/TCP | 미디어 전송 |
| 6443 | TCP | 보안 연결 |
IP가 아닌 도메인으로 허용하는 이유 → Agora 서버 IP는 수시로 바뀌기 때문에 IP 고정 허용이 불가능합니다.
방식 2 — Cloud Proxy (클릭 시 시각화)
화이트리스트도 못 하는 제한된 환경을 위한 솔루션입니다.
- 일반 WebRTC TURN: 클라이언트 → TURN 서버 → Peer
- Agora Cloud Proxy: 클라이언트 → Cloud Proxy → Agora SD-RTN® → 상대방
동작 흐름
- SDK가 Cloud Proxy에 연결 요청
- Cloud Proxy가 프록시 정보 반환
- SDK → Cloud Proxy → Agora SD-RTN® (Agora 글로벌 네트워크)
- SD-RTN® → Cloud Proxy → SDK (역방향)
코드 한 줄로 활성화
정정: enum 정수값은 SDK 버전에 따라 다르다. 현행 4.x 계열은
NONE_PROXY=0,UDP_PROXY=1,TCP_PROXY=2다. (구버전 3.x에서 통용되던UDP=3 / TCP=5값은 더 이상 표준이 아니다.) 상수명·정수값 모두 사용 중인 SDK 버전 레퍼런스에서 반드시 확인할 것.setCloudProxy는 채널 join 전에 호출해야 한다.
일반 TURN vs Agora Cloud Proxy
| 항목 | 일반 TURN | Agora Cloud Proxy |
|---|---|---|
| IP 허용 | 임의 Peer IP 추적 불가 | Agora Allowed IP 목록(고정 대역)만 등록 |
| 포트 | 3478 (UDP) | Force TCP는 TCP/TLS 443, Force UDP는 별도 UDP 대역 |
| 방화벽 우회 | 어려움 | Force TCP는 443 포트라 거의 통과 |
| 설정 | 복잡 | SDK 한 줄 + IP 화이트리스트 |
| 네트워크 | 단순 중계 | Agora 글로벌 SD-RTN® 경유 |
정정: Cloud Proxy는 도메인 화이트리스트를 지원하지 않는다. Firewall Whitelist(방식 1)와 달리, Cloud Proxy는 Agora가 게시하는 고정 Allowed IP 대역을 방화벽에 등록하는 방식이다. "IP 허용 불필요"는 부정확하며, 정확히는 "Agora 전체 인프라가 아니라 Cloud Proxy 전용 IP 대역만 허용하면 된다"가 맞다. 또 Force UDP 모드는 CDN 푸시·채널 간 미디어 릴레이를 지원하지 않으니, 이 기능이 필요하면 Force TCP를 써야 한다. [NEEDS VERIFICATION] 정확한 IP 대역·포트는 리전별로 다르므로 Agora의 Allowed IP List 문서를 직접 확인할 것.
SD-RTN® 이란?
SD-RTN = Software Defined Real-Time Network
Agora가 전 세계에 구축한 자체 미디어 전송 네트워크입니다. 일반 인터넷이 아닌 Agora 전용 백본망으로 데이터를 전송합니다.
핵심 요약
기업 방화벽에서 Agora가 살아남는 이유:
- 도메인 허용 → IP가 바뀌어도 문제 없음
- 443 포트 사용 → 거의 모든 방화벽이 HTTPS 포트는 열어둠
- Cloud Proxy → 극단적 제한 환경에서도 SDK 한 줄로 우회
- SD-RTN® → 일반 인터넷 대신 Agora 전용망 사용 → 안정성 ↑
Cloud Proxy 구조 시각화 (클릭 시 시각화)
Cloud Proxy 역할 상세
① 고정 진입점 제공 — 왜 필요한가?
Agora 일반 연결
- SDK →
*.agora.io→ 실제 서버 IP (1.2.3.4 or 5.6.7.8 or …) - 이 IP가 계속 바뀜 (글로벌 로드밸런싱)
기업 방화벽 입장: "어? 오늘은 1.2.3.4, 내일은 5.6.7.8… 어떤 IP를 허용해야 해?" → IP 기반 방화벽은 사실상 허용 불가
Cloud Proxy 연결
- SDK → Cloud Proxy (고정 IP 대역) → SD-RTN®
- 이 IP 대역만 방화벽에 등록하면 끝 (예: 148.153.x.x 대역만 허용)
핵심: Agora 전체 인프라 IP를 허용할 필요 없이, Cloud Proxy IP 대역만 허용하면 됩니다.
② 프로토콜 변환 — 구체적으로
기업 내부망 상황
- UDP 3478 → ❌ 차단
- UDP 4700~5000 → ❌ 차단
- TCP 443 → ✅ 허용 (HTTPS니까)
Cloud Proxy가 하는 일
즉, 클라이언트는 TCP 443으로 보내고, Cloud Proxy가 내부적으로 UDP로 변환해서 SD-RTN®에 전달합니다.
setCloudProxy(TRANSPORT_TYPE_TCP_PROXY)→ 클라이언트는 TCP 443 사용- Cloud Proxy 내부에서 변환
- SD-RTN®는 UDP로 수신 (성능 최적화)
Firewall Whitelist만으로 충분한가?
| 환경 | Whitelist 충분? | 이유 |
|---|---|---|
| 일반 기업 (도메인 허용 가능) | ✅ 충분 | *.agora.io 도메인 + 포트만 열면 됨 |
| UDP 전체 차단 기업 | ❌ 부족 | UDP 못 쓰면 미디어 전송 불가 |
| IP 기반 방화벽 (도메인 불가) | ❌ 부족 | Agora IP가 동적이라 허용 불가 |
| 병원 / 은행 / 군 | ❌ 부족 | Cloud Proxy 필수 |
Firewall Whitelist 설정
기업 IT 관리자에게 아래를 요청하면 됩니다.
도메인 허용
포트 허용
- TCP: 80, 443, 3433, 4700~5000, 5668, 5669, 6080, 6443, 8667, 9667
- UDP: 3478, 4700~5000
결론: Whitelist는 IT팀이 협조적이고 도메인 허용이 가능한 환경에서만 충분합니다. 그 외에는 Cloud Proxy가 필요합니다.
관련 글
- #8 왜 P2P가 막히는가 — NAT/STUN/TURN — Cloud Proxy가 우회하려는 바로 그 NAT·방화벽 문제의 1차 원인을 다룬다.
- #0 WebRTC란? ICE/STUN/NAT/TURN 기초 — 표준 WebRTC가 IP 기반 TURN으로 우회하는 방식과 Agora 방식의 차이를 이해하는 기초.
- #43 Agora 자체 코덱 vs Web SDK, SD-RTN, FEC — 이 글에 나온 SD-RTN® 백본망의 실제 구조와 전송 최적화(FEC)를 더 깊이 본다.
- #34 TTFB 분해 — DNS/TCP/TLS — Force TCP 모드가 TCP/TLS 443으로 핸드셰이크하는 비용(왜 UDP보다 느린가)을 분해한다.
- #47 WebRTC 벤더 지형도 — Cloud Proxy + SD-RTN처럼 "자체 인프라로 우회"하는 벤더 전략을 다른 벤더와 비교한다.
참고 자료
- Video Calling: Firewall requirements (Agora Docs) — 허용해야 할 도메인·포트 화이트리스트의 공식 레퍼런스.
- Video Calling: Connect through restricted networks with Cloud Proxy (Agora Docs) —
setCloudProxy, Force UDP/TCP 모드, proxyType enum의 1차 출처. - Video Calling: IP addresses for Cloud Proxy (Agora Docs) — Cloud Proxy에 등록해야 할 Allowed IP 대역·포트 목록.
- RFC 8656 — Traversal Using Relays around NAT (TURN) — 표준 TURN 릴레이 동작 정의. Agora Cloud Proxy와 비교 기준이 되는 IETF 표준.
- RFC 8445 — Interactive Connectivity Establishment (ICE) — NAT 통과 후보 수집·연결 절차 표준. 방화벽 우회의 이론적 토대.
- MDN — WebRTC API: Protocols — STUN/TURN/ICE/NAT 통과 개념의 입문 설명.
실제 데모
/agora-demo/rtc