一、三个网段，两套调阅需求
先说一个真实的现场。
某变电站联网平台项目，一台平台服务器要同时跨三个网段干活：从监控专网接入摄像头取流，同时要被监控专网、办公网、上级网络三边的用户调阅图像和录像。
项目组最初的方案是上某大厂的平台。评估做下来，网络部分先扛不住了：要打通这三个网段的互访，得增加一批网络设备和转发设备——交换机、路由策略、地址转换一层套一层，硬件采购加集成实施，成本直接把项目利润吃掉一块。
最后落地的方案出乎意料地简单：机房里的网络设备一台不动，只在平台侧做了简单的 IP 规则配置，三个网段的接入和调阅全部跑通。
这件事引出一个很多团队吃过亏的结论：在视频联网项目里，真正让工期失控的往往不是协议，是网络。 协议对接再难，抓包总能定位；网络方案一旦选错，返工就是推倒重来。
二、多 IP 的设备，为什么成了难题
先讲机理。一台服务器插多块网卡、配多个 IP，在操作系统层面是再正常不过的事。但放到视频平台场景里，问题立刻暴露出来，核心在于**"信令地址"和"媒体地址"不是一回事**。
设备向平台注册（或者平台间级联）时，SIP 信令从网卡 A 的地址发出来；但随后协商媒体的 SDP 报文里，声明的却是另一个地址——可能是配置里写死的默认 IP，也可能是另一个网卡的地址。接收方按 SDP 里声明的地址去取流，如果这个地址在自己所在的网段根本不可达，表现就是：注册成功，取流黑屏。
这类故障在现场通常有三种长相：
- 注册成功但取流失败：信令走通了，媒体地址不可达；
- 换个网段访问就黑屏：监控专网里调阅一切正常，办公网一调就挂——因为媒体流只会从"它认为对"的那个出口出去；
- 重启后 IP 漂移：多网卡环境没有绑定策略，服务重启后出口地址变了，前一天还能用的链路第二天全断。
根因一句话概括：SDP 里声明的媒体地址与信令来源地址不一致，而多网卡/NAT 环境下没有统一的选路策略。
解法对应的就是三件事：多 IP 地址管理、IP 规则配置、智能选路。把"哪类业务从哪个网段走"变成显式规则，而不是靠操作系统默认路由碰运气：
| 规则场景 | 配置逻辑 | 典型用途 |
|---|---|---|
| 同网优先 | 取流方与设备同网段时，媒体流直接走同网段地址 | 监控专网内部调阅，零跨网流量 |
| 指定出口 | 按对端网段固定媒体出口地址 | 上级平台级联，出口可预期 |
| 按业务分流 | 预览、回放、对讲走不同网段/链路 | 多网段并存、带宽隔离 |
回到开头那个变电站项目：一台服务器、三个网段，靠的就是这套 IP 规则配置——摄像头从监控专网进来，三边用户各走各的最优路径，没有新增任何网络与转发设备。
三、内外网隔离：安全要求下的必然题
第二类问题更普遍：视频平台在内网，应用在公网。
这不是谁的方案设计问题，而是行业监管的硬要求——电力、公安、海油这类行业，等保、密码评测、行业安全检查层层设卡，视频平台按安全监管要求不允许外部用户直接访问。可业务侧的应用偏偏要部署在公网服务器上，用户通过公网应用调阅视频、发起对讲，流量必须"穿"进内网。
常见的三种做法，代价差异很大：
| 做法 | 优点 | 代价 |
|---|---|---|
| 直接放通端口 | 简单粗暴 | 安全风险大，等保和检查过不了 |
| 加网络设备/转发机 | 隔离彻底 | 硬件成本高、链路长、延时大 |
| 反向代理 + 单端口复用 | 不增加设备，配置可控 | 需要平台侧支持端口收敛 |
第三种是我们在某海油执法仪联网平台项目里实际走通的路线：视频平台部署在内网服务器，用户应用在公网，中间通过在平台上方设置 nginx 反向代理，解决了内外网双向通信问题——公网应用穿透到内网平台，视频预览和语音对讲都跑通了，全程没有为此新增网络设备。
这里有个容易被忽略的前提：反向代理这条路，平台侧必须配合。原因就藏在下一节。
四、单端口复用：代理方案成立的关键
视频平台天然是个"端口大户"。把一个典型平台的端口清单摊开看：SIP 信令一个，RTP/RTSP 媒体传输一段，录像回放一个，语音对讲一个，Web 管理一个，再加 WebSocket、接口服务……六到八个端口起步。
端口一多，麻烦就指数级上涨：反向代理规则要一条条配，防火墙策略要一条条开，等保测评时每一个放通的端口都要给出说明。一个平台过去常见"几十条"代理和防火墙规则——运维成本高，攻击面也大。
单端口复用做的事，是把信令、媒体、回放、对讲、Web 这几类业务收敛到同一个端口上复用传输。效果直接体现在代理配置上：防火墙策略从"几十条"降到"一条"，nginx 那边一条转发规则搞定，等保检查时也只需解释一个端口。
这也是为什么上一节的方案里要强调"平台侧支持端口收敛"——市面上不少平台把端口写成固定的，代理方案再漂亮也落不了地。
五、现场排查清单
最后给一份可以照着查的清单，多网段/NAT 环境的视频平台联调，按这个顺序走能省掉大部分扯皮：
- IP 规则核对：设备注册 IP 与媒体声明 IP 是否一致？不一致的，明确选路规则；
- 取流路径：每个网段的调阅请求，是否走了该网段的最短出口，而不是绕默认路由；
- SDP 重写：NAT 环境下，SDP 里的媒体地址是否需要平台侧重写为可达地址；
- 代理层能力：反向代理是否支持 WebSocket/长连接？语音对讲的双向通道（RTP 收发两个方向）是否都穿透了？
这四条里最容易被漏掉的是第四条：图像穿透了，对讲不通，往往就是代理层只转了单向 RTP。
写在最后
网络方案在视频项目里是隐形的地基：选对了，一台服务器服务三个网段相安无事；选错了，后面每加一路业务都在还债。
这类跨网段、内外网互通的场景，智联视频超融合平台已经在变电站联网、海油执法仪联网等项目里落地——多 IP 管理与智能选路，让一台服务器同时服务监控专网、办公网和上级网络，不新增网络设备；反向代理配合单端口复用，让公网应用穿透到内网做视频预览和语音对讲。接入侧兼容 GB/T 28181、RTSP 与各类私有协议，级联支持智能流量调度与负载均衡，并有全国产化信创适配，从芯片到操作系统全链路可替换。
你的项目里，有没有被网段和防火墙折磨过的经历？欢迎留言或私信聊聊，网络这一层的坑，我们大概率替你踩过。