在使用 Lucky 反代后出现 400 BadRequest 的错误，搜索了下，很好解决。进入 Home Assistant 容器的终端，修改 configuration.yaml 文件，添加如下内容：
就是将自己的 IP 段加入 trusted_proxies 中，比如我的小米路由器是 192.168.31.0/24 。改完之后保存，接着重启。
如何编辑configuration.yaml 文件呢？
直接在设置➡️应用➡️安装file editor
安装完成之后打开
点开左上角文件夹的图标就可以看到configuration.yaml 文件，进去修改后保存。
重启之后就可以了。
这次修改的本质：告诉 Home Assistant “我前面确实有一层反向代理，并且这层代理是可信的”，从而允许它采信代理转发过来的请求头（X-Forwarded-*）。否则 HA 会把这些头当成“伪造/不可信来源”，直接拒绝或按错误方式处理，于是你看到
400 BadRequest。下面把“原理—为什么会 400—为什么加了就好”讲透：
1) 反代场景里，请求到底长什么样
你访问域名（或外网地址）→ Lucky（反向代理）→ Home Assistant（HA 容器）。
Lucky 通常会把“客户端真实信息”放进转发头，比如：
X-Forwarded-For: 客户端真实 IP
X-Forwarded-Proto: 原始协议（http/https）
X-Forwarded-Host: 原始 Host（你访问的域名）
- （有时还有）
X-Real-IP
这些头的意义是：后端应用（HA）能知道“用户真正从哪里来、用的是什么协议、访问的是什么域名”，以便正确做：
- 登录/会话安全判断（cookie 的 secure、same-site 等）
- 生成回跳链接、WebSocket URL
- IP 限制/频控/审计日志
- 判断是否允许某些请求（CSRF/host 校验等）
2) Home Assistant 为什么默认不信这些头
关键点：X-Forwarded-For 这类头非常容易被客户端伪造。
如果后端应用在“没有确定前面确实是可信代理”的情况下就直接信这些头，攻击者可以：
- 伪造
X-Forwarded-For绕过 IP 白名单/安全策略
- 伪造
X-Forwarded-Proto=https让应用误以为是 HTTPS（影响 cookie / 跳转 / 安全判断）
- 伪造
X-Forwarded-Host搞 Host 混淆、回跳到恶意域名等
所以 HA 的 HTTP 组件对“代理相关头”是 默认严格的：
只有当请求来自你明确声明的“可信代理 IP”时，它才允许启用并采信
X-Forwarded-*。3) 你的 400 BadRequest 常见触发机制（Lucky 反代 → HA）
当 Lucky 把请求转给 HA 时：
- Lucky 发来的请求 带着 X-Forwarded- 头
- 但 HA 没有配置
use_x_forwarded_for/trusted_proxies
- 或者
trusted_proxies不包含 Lucky 的来源地址（注意是HA 看到的上一跳地址）
这时 HA 会认为：
“你这个请求里带了代理头，但我不确定你是不是可信代理。为安全起见，我拒绝。”
结果就是你看到的
400 BadRequest（或者表现为登录失败、跳转异常、WebSocket 连不上等）。4) 这两行配置分别解决什么
你加的配置：
use_x_forwarded_for: true
意思是：允许 HA 使用
X-Forwarded-For 来识别真实客户端 IP（并且通常也会配合处理其他 Forwarded 头）。没有它，即使你声明了可信代理，HA 也可能仍然不用这些头。
trusted_proxies: 192.168.31.0/24
意思是：只要请求是从这个网段的“代理服务器（上一跳）”来的，我就信它带来的 X-Forwarded- 头*。
也就是说，你在向 HA 声明一个安全边界：
- 信任边界内（trusted_proxies）：X-Forwarded-* 可信
- 信任边界外：一律不信（防伪造）
因此加完后，Lucky → HA 的请求满足“来自可信代理”，HA 就不再拒绝，并能正确识别真实 IP / 协议 / host，于是反代恢复正常。
5) 为什么写 192.168.31.0/24 而不是写某一个 IP
两种写法都可以，取决于你的网络结构：
- 更严谨/推荐：写 Lucky 容器/主机的具体 IP（例如
192.168.31.50）
- 更省事但更宽：写整个网段（
192.168.31.0/24）
写网段的风险是：如果你的局域网里有其他设备也能直接连到 HA（绕过 Lucky），并且它能伪造这些头，那么 HA 会把它也当“可信代理”。
在很多家庭网络里这问题不大，但从安全角度，尽量缩小 trusted_proxies 范围会更好（只信 Lucky 实际来源 IP）。
6) “为什么重启容器才生效”
configuration.yaml 是 HA 启动时加载的配置。HTTP 相关参数属于启动配置项，一般需要重启 HA 才会应用。7) 一句话总结
你这次修改是把 HA 的“代理安全模型”补齐了：
启用对 X-Forwarded- 的支持 + 明确声明 Lucky 的来源地址是可信代理*，从而让 HA 不再把反代请求当成伪造/不安全请求而返回 400。
如果你愿意把你 Lucky 的部署方式（Docker/宿主机 IP、HA 与 Lucky 是否在同一网桥、Lucky 转发到 HA 用的地址）贴一下，我也可以帮你把
trusted_proxies 精确到“最小可信范围”，兼顾可用性和安全性。
