分類
程式技術

有趣的iOS上Safari播放mp4問題

今天在測試一個 nginx reversed proxy 上, 代理 upstream server mp4 檔案時的播放問題.

之前沒特別有這個狀況, 但今天開始不能播放(感覺應該是在ios 12.4起發生), 十分有趣, 從 nginx server log 也看不出來原因, 只知道 nginx server 在 ios safari request 時, sent-byte 大小小於原始的 mp4 檔案, 所以也只能從 ios safari 的 developer mode 來著手.

先進行 ios safari developer mode, 可以參考:

https://unrealnavigation.com/blog/web-inspector-with-ios-simulator

然後發現原來 safari 會 request byte-range 0-1 這樣的狀況, 難怪都不會送出完整結果, 這樣一來原因就明確了, 實務上的狀況可以參考這篇:

https://www.stirtingale.com/guides/2018/10/mp4-not-working-cloudflare

若是原本的 server 沒有支援 byte-range 時, 會導致 status 200 而非 safari 預期的 206, 而導致失敗. 接下來就可以來找解決方案.

以 nginx proxy_pass 的反向代理結構來看, 可以利用這個方案:

https://stackoverflow.com/questions/22728016/nginx-is-not-accepting-range-of-bytes

使用 proxy_force_ranges on; 即可.

當然, 原本的 upstream 也需要有支援才能解決.

如此一來, 便能在 ios safari 於 request mp4 資源時, 下達的 byte-range 於快取或未快取內容皆可正常工作.

PS. 於查找過程找到一篇介紹 nginx revered proxy hash key 算法資料可供參考:
https://tomme.me/nginx-proxy-cache-server/

分類
FreeBSD/Linux

[nginx]Reverse Proxy with Cache SSL fails

一般我們在實作 Nginx 的 Reverse Proxy with Cache 時, 可以參考這篇:

https://www.nginx.com/resources/wiki/start/topics/examples/reverseproxycachingexample/

不過若是 proxy_pass 的 upstream 是 https://example.com/ 時, 會發生以下錯誤:

SSL_do_handshake() failed (SSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure) while SSL handshaking to upstream

從 log 來看, 其實原因很單純, 因為預設往 upstream 的 web request 會使用 ip 的方式連接, 而導致錯誤 (前端收到為 502 bad gateway), 解決方式只需要新增一個值:

proxy_ssl_server_name on;

如此即可, 請參閱: