【3.6】能否将config里hostname解析的protocol传递给playlist？

[blurainer]

默认没有开启xff，反代用的https，但是发现拿到的playlist用的是http，即使显式在hostname=https://**
好像只有在xff的时候才会被替换proto，config里的hostname的protocal被无视了

[stackia]

对的，在 v3.6.0 调整了这里的逻辑。现在使用反代的时候，建议都开启 xff 选项

这个改动因为对原先用法是不兼容的，我原本计划放到 v4 再发出来，但 v4 可能还需要比较长时间开发，所以我还是决定在 v3.6 先发布了。

[stackia]

https://github.com/stackia/rtp2httpd/blob/main/docs/configuration.md#公网访问建议

这里文档也做了更新，参考一下最新的建议。

hostname 现在不会影响 m3u 的地址替换了

[blurainer]

嗯，能兼容下最好了，就是默认的proto是hostname解析出来的，而不是固定的http 因为偷懒用了群晖dsm的反代，然后好像又不支持自定义xff。。。 anyway，我先回退到3.5了

[stackia]

了解，考虑到你的这种使用场景，我会兼容一下

[stackia]

https://github.com/stackia/rtp2httpd/releases/tag/v3.6.1

[lancsir]

为啥https访问player网址的时候，生成的playlist.m3u里面的地址用http，为什么不跟域名一样，这么做有何用意

[github-actions]

这个问题已经在 v3.6.1 版本中得到了改进。让我解释一下为什么会出现这种情况以及如何解决：

问题原因

rtp2httpd 本身通常监听在本地的 HTTP 端口（默认 5140），当你通过 HTTPS 访问时，实际上是通过反向代理（如 Nginx、Caddy、群晖 DSM 等）来转发请求的。rtp2httpd 只能看到来自反向代理的本地 HTTP 连接，所以默认会生成 http:// 的地址。

解决方案

有两种方式可以让 playlist.m3u 使用正确的 HTTPS 协议：

方式 1：配置 hostname（推荐用于不支持自定义 XFF 的反代）

在配置文件中明确指定完整的 HTTPS 域名：

[global]
hostname = https://your-domain.com

v3.6.1 版本会自动从 hostname 中提取协议（https://），并用于生成 playlist 中的地址。

方式 2：启用 XFF 选项（推荐用于标准反代）

如果你的反向代理支持传递 X-Forwarded-Proto 等标头（大多数反代都支持），可以启用：

[global]
xff = yes

这样 rtp2httpd 就会从 X-Forwarded-Proto 头中读取协议类型，自动使用 https://。

对于 Nginx，参考配置：

proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

设计考虑

这样设计的原因是：rtp2httpd 不会自动检测客户端的访问协议，因为它位于反向代理之后，只能看到本地连接。必须通过配置或 HTTP 头来告诉它正确的协议。这样做既保证了灵活性，也提高了安全性。

建议：如果你的反代不方便配置 XFF，使用方式 1 即可。如果可以配置 XFF，方式 2 更加灵活自动。