OpenWrt反向代理如何实现HTTPS卸载与后端HTTP转发？

Question

在OpenWrt上配置反向代理实现HTTPS卸载（SSL Termination）与后端HTTP转发时，常见问题为：**Nginx或uHTTPd启用TLS后，后端服务（如Home Assistant、Pi-hole）仍被强制跳转HTTPS或返回502/503错误，且响应头中`Location`、`Set-Cookie`等字段未正确重写，导致混合内容或会话失效。** 根本原因常包括：① 未在代理配置中设置`proxy_set_header Host $host`及`proxy_set_header X-Forwarded-Proto https`；② 后端应用未配置信任反向代理的`X-Forwarded-*`头，导致其误判请求协议；③ uHTTPd默认不支持SNI和现代TLS配置，而Nginx需手动编译含OpenSSL支持的版本；④ Let’s Encrypt证书自动续期后未触发代理服务重载，造成证书过期中断。此外，OpenWrt资源受限，不当启用HTTP/2或过多worker进程易引发内存溢出。如何在有限内存（如128MB RAM）下安全、稳定地完成HTTPS卸载并确保后端HTTP服务无感知兼容，是典型落地难点。

Answer 1

```html

一、现象层：典型故障表征与日志线索定位

在OpenWrt（如23.05.x）上启用反向代理后，常见终端表现为：Home Assistant 页面白屏并控制台报 Mixed Content: The page at 'https://home.example.com/' was loaded over HTTPS, but requested an insecure resource 'http://192.168.1.100:8123/frontend_latest/core.b9a7f.js'；Pi-hole 管理界面反复重定向至 https://pi-hole.local/admin/（非代理域名），返回 301 或 503；logread | grep -i "nginx\|uhttpd" 显示 upstream timed out (110: Operation timed out) 或 no live upstreams while connecting to upstream。这些是SSL卸载失败的“症状级”信号，需立即捕获 /var/log/nginx/error.log 与 uci show uhttpd 输出交叉比对。

二、协议层：X-Forwarded-* 头缺失引发的协议误判链

• proxy_set_header Host $host; 缺失 → 后端收到 Host: 192.168.1.100:8123，触发 Home Assistant 的 base_url 校验失败
• proxy_set_header X-Forwarded-Proto https; 缺失 → Pi-hole 的 lighttpd 默认以 http 构造 Location 响应头，导致 302 跳转到 HTTP 地址
• proxy_set_header X-Forwarded-For $remote_addr; 缺失 → HA 的登录会话无法绑定真实客户端IP，Set-Cookie 中 Secure 属性被错误忽略

三、服务层：uHTTPd vs Nginx 的能力边界与选型决策

能力项	uHTTPd（OpenWrt原生）	Nginx（需opkg安装）
TLS 1.3 / SNI 支持	❌ 仅支持 TLS 1.2，无SNI（单证书绑定单域名）	✅ 完整支持（需 nginx-full + OpenSSL 3.0+）
内存占用（空载）	≈ 2.1 MB RSS	≈ 4.7 MB RSS（worker_processes 1）
Header 重写能力	仅支持基础 redirect，无 sub_filter 或响应头动态改写	✅ 支持 proxy_redirect、sub_filter、more_set_headers（需 nginx-mod-http-headers-more）

四、配置层：Nginx 零内存溢出安全模板（128MB RAM适配）

# /etc/nginx/conf.d/home-assistant.conf
upstream ha_backend {
    server 192.168.1.100:8123;
    keepalive 16;
}
server {
    listen 443 ssl http2;
    server_name home.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;

    # ⚠️ 关键：强制关闭HTTP/2（避免TLS握手内存峰值）
    http2 off;

    location / {
        proxy_pass http://ha_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Port 443;

        # 修复Location重定向（Home Assistant 2023.10+要求）
        proxy_redirect http:// https://;

        # 修复Set-Cookie Secure属性（关键！）
        proxy_cookie_flags ~ secure httponly;
    }
}

五、后端层：Home Assistant 与 Pi-hole 的信任链显式配置

Home Assistant 必须在 configuration.yaml 中声明：

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 192.168.1.1   # OpenWrt路由器IP
  ip_ban_enabled: true
  login_attempts_threshold: 5

Pi-hole 需修改 /etc/lighttpd/lighttpd.conf，在 $HTTP["host"] =~ "pi-hole.example.com" 块内添加：

setenv.add-environment = (
  "HTTPS" => "on",
  "HTTP_X_FORWARDED_PROTO" => "https"
)

六、运维层：Let’s Encrypt 续期与服务热重载原子化

使用 acme.sh 替代 certbot（更轻量），并定义钩子脚本：

# /etc/acme.sh/home.example.com/deploy.sh
#!/bin/sh
/etc/init.d/nginx reload 2>/dev/null || true
# 验证证书有效性（防reload失败静默）
openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -checkend 86400 >/dev/null 2>&1 || logger -t acme "CERT EXPIRES IN <1 DAY!"

通过 crontab -e 添加：0 3 * * * /usr/bin/acme.sh --renew --domain example.com --deploy-hook /etc/acme.sh/home.example.com/deploy.sh

七、验证层：端到端连通性诊断流程图

graph TD
  A[客户端访问 https://home.example.com] --> B{Nginx 是否监听 443？}
  B -->|否| C[检查 nginx -t && /etc/init.d/nginx restart]
  B -->|是| D[抓包验证 Client Hello SNI 是否为 home.example.com]
  D --> E{证书是否有效？}
  E -->|否| F[acme.sh --issue ...]
  E -->|是| G[检查 proxy_pass 目标是否可达：curl -v http://192.168.1.100:8123/api/]
  G --> H{响应头含 X-Forwarded-Proto: https？}
  H -->|否| I[检查 proxy_set_header 指令是否生效]
  H -->|是| J[浏览器开发者工具 → Network → 查看 Set-Cookie 是否带 Secure]

八、加固层：内存与连接数硬限策略

在 /etc/nginx/nginx.conf 全局块中强制约束：

worker_processes 1;
events {
    worker_connections 64;  # 单worker最大并发连接数
    multi_accept off;
}
http {
    client_max_body_size 16m;
    client_body_timeout 12;
    send_timeout 10;
    keepalive_timeout 30 30;
    reset_timedout_connection on;
    # 禁用所有非必要模块以减内存
    load_module /usr/lib/nginx/modules/ngx_http_ssl_module.so;
    # 注释掉：/usr/lib/nginx/modules/ngx_http_v2_module.so
}

九、演进层：从 Nginx 到 Caddy 2 的轻量化替代路径

当设备升级至 OpenWrt 24.10+（musl 1.2.4+, aarch64），可评估 caddy（静态链接二进制，≈3.2MB）：

home.example.com {
    reverse_proxy 192.168.1.100:8123 {
        transport http {
            keepalive 30s
        }
    }
    header_up Host {http.request.host}
    header_up X-Forwarded-Proto {http.request.scheme}
    header_up X-Forwarded-For {http.request.remote}
}

Caddy 自动处理 Let’s Encrypt、HTTP/2、TLS 1.3，并内置 header_up 动态注入，规避 Nginx 模块编译复杂度。

十、兜底层：故障快速回退机制设计

建立双配置快照与一键切换脚本：

# /root/nginx-rollback.sh
cp /etc/nginx/conf.d/home-assistant.conf.bak /etc/nginx/conf.d/home-assistant.conf
/etc/init.d/nginx reload
logger -t nginx "Rolled back to backup config at $(date)"

配合 watch -n 30 'free -m | grep Mem:' 实时监控内存，当 MemAvailable < 15MB 时自动触发 /root/nginx-rollback.sh（通过 procd 守护进程实现）。

```