@CNZCC #10
无法直接 ping 倒是也挺常见的，那你可能需要试一下 tcping 和 tcptraceroute


mac 下的 tcping 需要手动安装，到这里下载：
https://github.com/paradiseduo/tcping/releases

然后：
tcping 114.114.114.114 53

把 114.114.114.114 替换为相应的 IP，53 替换为相应的端口


至于 tcptraceroute，如果你装了 brew 的话，可以直接
brew install tcptraceroute

然后：
sudo tcptraceroute 114.114.114.114 53

把 114.114.114.114 替换为相应的 IP，53 替换为相应的端口

@CNZCC #8
先 ping ……

如果 ping 的延迟不是很高，那软件问题的可能性就更大一些，就可以先不 traceroute

如果 ping 的延迟很高，同时没有 traceroute 到太多的信息。
那可以先简单对比一下你这三个设备的网络运营商。

@CNZCC #6
啥？ 你把 1.2.3.4 替换成你要连接的那个公网 IP 啊。

比如你公司电脑的公网 IP 是 233.233.233.233 ，那你就把命令改成：
ping 233.233.233.233
traceroute 233.233.233.233

我不知道你的公网 IP 是多少，肯定不能给你完整的命令啊……

@CNZCC #4
替换成你所连接的公网 IP 啊…………

@CNZCC #2
那建议先检查一下延迟：
ping 1.2.3.4
traceroute 1.2.3.4

看一下是否存在线路上的问题。


另外就是使用微软官方客户端试试：
https://install.appcenter.ms/orgs/rdmacios-k2vy/apps/microsoft-remote-desktop-for-mac/distribution_groups/all-users-of-microsoft-remote-desktop-for-mac

公司的 Windows 机器是直接拥有公网 IP 的么？还是通过其它方式暴露到公网的？
另外，讲一下你是使用什么软件进行远程的，RDP ？ TeamViewer ？

可以在你本机 tracert 一下你远程的目标 IP，看看是否存在线路问题。

LTSC 不是精简版，是完整版

修正一下措辞，okhttp 不是不支持 307，是对 307 的支持不标准。

这里举一个不支持 307 的例子：
https://github.com/square/okhttp/blob/master/CHANGELOG.md#version-460

相应的代码在这里：
https://github.com/square/okhttp/pull/5990

这个的问题，在 2014 年就被引入，2016 年就被提出，却直到今年才被修正：
https://github.com/square/okhttp/pull/944#issuecomment-248449263


这个库，就是大名鼎鼎的 okhttp，做 Android 开发的应该基本都用过它 ~

@daimaosix #14
比较新一点的客户端应该都还不错，大部分情况下应该不用操心。
没找到请求库相关的，只找到一份浏览器的：
http://test.greenbytes.de/tech/tc/httpredirects/


如果很担心的话，可以在重定向的时候加一点标记，然后两边统计一下请求数量。

@daimaosix #10
hhh 307 能用就最好，有些客户端对 307 的支持不是很好。

@daimaosix #5
然后我们说 m3u8 文件修改的方案。

首先，最简单的方法肯定是直接改文件本身，可以写个小程序去批量修改。

其次，就是直接使用 nginx 的 ngx_http_substitutions_filter_module 模块动态修改。
https://www.nginx.com/resources/wiki/modules/substitutions/
https://github.com/yaoweibin/ngx_http_substitutions_filter_module

这个模块的功能也很简单，就是查找替换，比起官方的 ngx_http_sub_module 多支持了正则。
需要注意的是，这是个第三方模块，且近期似乎没有太多维护，要做好测试。


不知道你们的请求分布情况是怎么样的，按道理来说，对于大量请求的文件，还是尽量直接修改掉会比较好。

@daimaosix #4
我们先来说直接 https 的方案，其实并不需要 b_com 上有 a_com 的证书。

你可以在 b_com 上配置 SNI 反代，具体可以参考这个模块的使用：
http://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html

这样实现之后的效果的：
只要 b_com 发现流量是要访问 a_com 的，就直接转发到 a_com （没有解密过程）。
如果 b_com 和 a_com 在同一个内网，这样操作还是有一点点意义的。

少回答了一个问题，如果直接反代，那流量确实会受限于 a_com 的带宽。


另外，既然是视频业务，不清楚你们 a_com b_com 上具体放的是什么？
假如是 HLS 流的话，那么 a_com 先返回的是 m3u8 文件？
假如是这种情况，可以考虑篡改相应的文件，将文件內 ts 的地址都修改到 b_com，这样也是可以的。

是否支持重定向，要在客户端上测试一下做确认（大部分情况下都可以）。

要注意使用 301 302 可能会导致 POST 请求变为 GET 请求，如果这里存在问题，可以测试一下 307 是否正常。


另：不能直接将 a.com 指到 b.com 去嘛？