做视频直播或者搭建在线点播服务时，很多人只关注功能开发和界面设计，却忽略了背后一个不起眼但极其关键的环节——端口配置。其实，部署一套媒体软件，比如用 FFmpeg 做转码、用 Nginx-RTMP 模块推流，端口能不能通，直接决定了用户能不能看到画面。
为什么端口会影响部署结果？
想象一下你在公司内网搭了个直播服务器，本地测试一切正常，可同事在外面怎么也连不上。问题很可能出在端口上。你可能用了 1935 端口跑 RTMP 服务，但防火墙没开这个口，外部请求根本进不来。这时候就算程序跑得再稳，也是对牛弹琴。
另一个常见情况是端口冲突。比如你打算用 8080 启动 Web 页面展示播放器，结果发现之前跑了个测试服务占着这个端口，新服务起不来，页面自然打不开。这种“撞车”现象在多人共用服务器时特别容易发生。
典型配置示例：Nginx + RTMP
下面是一个常见的 Nginx 配置片段，用来支持 RTMP 推流：
rtmp \{
server \{
listen 1935；
chunk_size 4096；
application live \{
live on；
record off；
\}
\}
\}
这里明确指定了监听 1935 端口。部署时不仅要确保 nginx 能加载这个模块，还得检查系统是否允许该端口被占用。如果是云服务器，安全组策略也得加上对应规则，否则等于大门锁着，钥匙却挂在门外。
HTTPS 和 WebSocket 的端口搭配
现在越来越多媒体应用通过浏览器播放，依赖 WebSocket 传输音视频数据。比如你用 WebRTC 或者 HLS over HTTPS 提供服务，通常会结合 443 端口对外暴露。这时候 Nginx 不仅要处理 HTTP/HTTPS 请求，还要代理 WS/WSS 连接。
例如前端通过 wss://your.media.com/live 接收流，后端可能实际转发到 8081 端口的 Node.js 服务。这种跨端口代理必须在反向代理配置中写清楚，否则握手失败，连接建立不起来。
容器化部署中的端口映射
现在很多团队用 Docker 部署媒体服务。比如启动一个运行 SRS（Simple Realtime Server）的容器：
docker run -d -p 1935:1935 -p 8080:8080 ossrs/srs:latest这里的 -p 参数就是把宿主机的 1935 和 8080 映射到容器内部。如果漏写某个端口，比如只映射了 1935，那网页访问 8080 就会失败。即使容器里服务都正常，外面也看不到内容。
更麻烦的是，Kubernetes 环境下还有 Service 和 Ingress 层层转发，每一级都要确认端口路径是否打通。一个配置疏忽，整个链路就断了。
调试小技巧
遇到连不上服务的情况，可以用 telnet 或 nc 测试端口连通性：
telnet your.server.com 1935如果连接超时，先查本地防火墙，再看云平台安全组，最后确认服务是否真正在监听。用 netstat 也能快速查看：
netstat -tuln | grep 1935看到 LISTEN 状态才算真正准备好。别等到上线才发现门没开。