有效配置在另一篇文里,本文主要解释配置。
qbit开发者只写了Nginx版本的反向代理配置,首先提供原文如下。
proxy_pass http://127.0.0.1:port/;
proxy_http_version 1.1;
http2_push_preload on;
proxy_set_header Host 127.0.0.1:port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP $remote_addr;
proxy_cookie_path / "/; Secure";
作为初学者看到这些是非常困惑地,特别是我要将其转换成Apache2配置时,在经过一阵鸡飞狗跳的调试后,我配置的有效配置如下。
ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:port/
ProxyPassReverse / http://127.0.0.1:port/
<Proxy *>
Require all granted
</Proxy>
根据最后测试得到实际有效配置看,ProxyPassReverse
实际上起到了Nginx中几个proxy_set_header
语句的作用,在Apache2中对于请求头的部分是自动完成的,一般无需特殊配置。
proxy_set_header Host 127.0.0.1:port;
该句将请求的Host头部设置为”127.0.0.1:port”,抹去了原有的请求头,在Apache2实际上导致了请求 Header 中 Origin 与 XFH/Host 不匹配,进而导致qbit拒绝访问,正确的配置实际上是令ProxyPreserveHost为On。
proxy_set_header X-Forwarded-Proto $scheme;
配置X-Forwarded-Proto
头部起指示原始请求是通过HTTP还是HTTPS发送的作用,但是配置本身就是为了通过反向代理加密内网服务,后端实际上不需要辨别是否重定向到https。
proxy_set_header X-Forwarded-Host $http_host;
该句设置的X-Forwarded-Host
意在使转发后的请求头包含原始请求的Host头部值,实际上是对第一条设置Host的补充,在Apache2中该工作已经由ProxyPreserveHost
一次性完成了。
proxy_set_header X-Forwarded-For $remote_addr;
设置X-Forwarded-For
头部是为了保存发起请求的客户端的IP地址,这个工作在Apache2中同样由ProxyPreserveHost
控制。况且在现在普遍NAT的情况下,得到也只是NAT地址。
proxy_set_header X-Real-IP $remote_addr;
该句与X-Forwarded-For
类似,但它只包含单个IP地址,即直接连接到Apache的客户端的IP地址。X-Real-IP
有时被用作X-Forwarded-For
的简化版,特别是当你知道请求只经过了一个代理(即Apache)时。但X-Real-IP不是一个标准的HTTP头部,它的解释可能因应用程序而异。这里实际上出现了重复配置,十分令人疑惑。
proxy_cookie_path / "/; Secure";
该句作用是将所有通过代理传递的Cookie的路径设置为根路径(“/”),并且标记为安全(Secure),令Cookie只能通过HTTPS连接发送。而Apache本身不提供直接修改Cookie路径的功能,经常是通过headers模块结合外部命令实现。
官方Wik中在http反代和https反代中给出的配置建议并不相同,甚至相反,令人困惑,以下列出http代理。
proxy_pass http://127.0.0.1:port/;
proxy_http_version 1.1;
proxy_set_header Host 127.0.0.1:port;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_cookie_path / "/; Secure";
其中X-Forwarded-Proto
和X-Real-IP
被标注为not used by qBittorrent
,总之我很迷惑。
而对于proxy_cookie_path
维护者是这样解释的,同样令人迷惑。
# Since v4.2.2, is possible to configure qBittorrent
# to set the "Secure" flag for the session cookie automatically.
# However, that option does nothing unless using qBittorrent's built-in HTTPS functionality.
# For this use case, where qBittorrent itself is using plain HTTP
# (and regardless of whether or not the external website uses HTTPS),
# the flag must be set here, in the proxy configuration itself.
# Note: If this flag is set while the external website uses only HTTP, this will cause
# the login mechanism to not work without any apparent errors in console/network resulting in "auth loops".
在经过半天的搜索后我又回到了最开始的地方,继续用我两年前就知道的Apache2配置。
只需将一些过时代码更新一下,将Order Deny,Allow
、Allow from all
替换为Require all granted
。
在Apache2.2版本以前,Order Deny,Allow
和Allow from all
指令用于组合在一起设置访问控制策略。Order Deny,Allow
用于指定处理顺序,Allow from all
指放行所有来源的访问。在2.4版本以后Require all granted
可以达到以上组合指令的效果,更简洁更细致。
在没有http基础的前提下了解这些配置真的很容易令人困惑,中文环境下所有帖子实际上都是同一坨屎,相比之下虽然英文回答经常是十年前的帖子而且只是给出起效的配置,但至少它有效。
如果想要了解详细的配置,还是需要回到官方文档才能了解这些配置到底是为什么。
另外,以上解释部分来自文心一言。