@hanguokai 2#，内嵌字幕流，那你就费劲了，需要播放器能够分离字幕流，目前我感觉普遍网页的播放器（其实就是浏览器的播放器）很少有这能力。
至于外置 srt 或者 ass，那倒是好办，js 解析，然后 div 层覆盖。

相对路径、绝对路径
看到问题，猜了大概，看到 6#确定了猜测。
但是解决这个问题，很大情况下源头不太好修改——因为如果他容易修改的话，他就不会用绝对路径这个 SB 的策略了——于是解决办法很有可能需要挨个 URL 做反代。

然后不知道 proxy_reverse

另外，location 最好用 2#的匹配，当然写你那样也没啥问题。然后结尾斜杠的问题，保持统一，要有都有，要没有都没有，/xxx 和 /xxx/是两个 URL 。

首先平台肯定二次编码，因为他要给观看用户不同的编码水平，这个你也控制不住。
其次你上传给平台的原始文件，也就是 PR 输出的，应当尽量清晰（也就是码率应当尽量高），4K 的应该 10M+，FHD 最低 2M+。
当然了，既然本地编辑，可以照着 20M+的输出，至于平台怎么二次处理，那就不你所能控制得了。

所以现在你没有说清楚，你本地输出的，到底多少码率。

最后，码率决定了体积，体积决定了上传时长。于是要引入编码器的概念，刚才说平台二次编码，他所用的编码器你控制不到；你也只能控制本地输出的编码，好在大部分编码平台都能识别； 4K 级别，一般用 x265/hevc 多一些。然后还有声音编码问题，要求不高就不说了。
最后再说一件事情，HDR/10bit，色彩空间的问题。这个话题就大了。如果能的话，LZ 先补习一下相关基础知识了。

@xgfan 64# 需要这么直接较真呢？我跟这说处理器呢，你跟我说 MBP 。
@sidkang 62# 是在比啊，十项全能里也有百米比赛

哦，堡垒机啊，那你应当选用具有审计功能的堡垒机。其实你这个 A 根本就不能称之为“堡垒机”，能 SSH 上去，然后再 SSH 到别的地方，审计，审啥啊，靠系统那点日志？得了吧。
再说了，A 能 SSH，你能确保 ssh 到 A 的不打洞？一旦打动，任何所谓的审计措施全都失效。

我没搞明白，从 LZ 到一众恢复，搁这儿强烈比较一个十项全能选手和一个百米冠军？
各位继续。。。

方法 1，SSH Tunnel，通过 A 的 ssh 建立 tunnel 到 B 、C 、D
方法 2，端口映射，A 上开（比如 60022 、60122 、60222 之类）端口映射 B 、C 、D 的 22 。

方法 1 安全一些，毕竟只暴露 A 的 22，B\C\D 的 22 不直接暴露，但是就是每次建立的时候，费点劲；
方法 2 省事一些，直接连接连接

方法 1，用 ssh 命令实现；方法 2 在 A 上用 iptables 或者 firewall-cmd 实现。两者都需要打开 port-forwarding，具体找文章。

在视频领域这个“压缩”可不是类似 winzip 、winrar 的压缩啊。
视频的压缩，普遍都是有损压缩，不存在“解压”这个概念，所谓的解压是基于有损的信息的重采样编码，效果肯定不行啊。

至于上传，上传分三步：客户端往服务器传，网络传输，服务器接收。那你觉得你所谓的“压缩”在哪一步完成呢？第一步？指望浏览器给你做视频压缩？第二步，网络交换机、路由器做压缩？第三步，服务器都已经接收到了原始数据，再压一遍，以后再“解压”，图啥？直接存储原始信息不好么。

然后客户端回显，现在 H5 的 video 标签，直接去服务器端请求数据，如果是本地能够解码的格式（比如 mp4 封装、h264 视频编码、mp3 音频编码）那就直接播放，如果不认编码格式，那就不能播放。

最后防盗链的一般手法是 host，二班手法是 header 里上 token，三班手法是 session，当然还有四五六班等等

@youngce 1# 把 javascript 作为字符串用对称加密（混淆），然后对称解密（反混淆）之后，eval 执行。
这是 js 混淆的手段之一。

从专业角度讲，能比气象台 NB，那我五体投地。路过过一次天天耳闻中的北京南郊观象台，自己可以卫星图看一下规模就知道了。
从自娱自乐角度讲，这事完全没难度，正如 @locoz 13#所述，简单地很。

A 口 B 口冲突了吧
按道理，掩码只负责子网判定，跟 IP 无关，所以按照 LZ 描述，A 口 B 口可以同时设置 192.168.128.5，那显然这是不允许的。