拯救者R9000P nginx反向代理502报错：Win11环境排查实录

手里这台拯救者 R9000P 我已经当主力开发机用了好几年，最近在家折腾 Home Assistant + 内网穿透方案，用 nginx 做反向代理。结果一跑就给我甩一脸 502 Bad Gateway，说真的那一刻确实有点破防。折腾了大半天，把排查思路和最终能落地的配置整理出来，给同样踩坑的朋友省点时间。拯救者 R9000P 这台机器跑容器和前端服务其实相当能打，但 Windows 平台和 Linux 的行为差异摆在那儿，很多从服务器迁移过来的配置直接翻车，太常见了。

一、问题现象与环境背景

先交代清楚这次的”案发现场”，方便后面按图索骥：

• 硬件平台：联想拯救者 R9000P（R7-7745HX / 16GB / 1TB），BIOS 已经是当时官网最新的版本，Legion Zone 切到了「野兽模式」
• 系统：Windows 11 23H2（22631.4391），暂未加入 Insider 预览通道
• nginx 版本：1.24.0（官方 Windows zip 包，直接解压到 C:\nginx 运行，没用 Scoop 或 Chocolatey）
• 后端服务：Home Assistant Core 2024.6 监听 8123；外加一个自建的 Node.js 接口服务监听 3000；偶尔还会起一个 Portainer 管 Docker
• 网络拓扑：拯救者接在家里的主路由下，home.lan.local 通过路由器 DNSmasq 解析到 192.168.1.20
• 访问方式：浏览器输入 https://home.lan.local:8443/ 后立即返回 502，浏览器控制台没 CORS 报错

直接看 C:\nginx\logs\error.log，反复出现的就是这一行：

connect() failed (10061: No connection could be made because the target machine
actively refused it) while connecting to upstream

10061 是 Windows Sockets 专属的错误码，对应 WSAECONNREFUSED。在 Linux 上你更常见的可能是 111: Connection refused，两者含义一样，但 Windows 上要特别注意这是「主动拒绝」而不是「超时」——这往往是定位问题方向的关键，别一开始就往网络延迟那条路上去查。

二、深度原因分析（按出现概率排序）

Win11 + nginx 这套组合出 502，通常逃不开下面几个方向，而且常常是几个问题叠在一起出现的：

1. 后端服务没真正监听在 127.0.0.1 上

很多教程直接告诉你 proxy_pass http://127.0.0.1:8123;，但你后端服务如果绑定的是 ::1（IPv6 only），那 nginx 用 IPv4 走过去肯定被拒。这一现象在 Home Assistant 的某些版本里出现过，http.server_host 默认值会跟着 Python 版本走，不同版本行为不太一样。

2. Windows Defender 防火墙 / 第三方杀软拦截

拯救者 R9000P 自带 Legion Zone（不是 Vantage，很多人会搞混），另外部分用户还会装 360、火绒、卡巴斯基这类杀软，它们的「流量防护」「WEB 防护」会在回环连接（loopback）上做 DPI 识别，把 127.0.0.1:8123 的请求当成”可疑外联”给拦了。nginx 主进程虽然被放行了，但 nginx 派发出去的 socket 请求是另一条路径，规则不通用。

3. proxy_pass 与 upstream 块冲突

不少人从网上 copy 来的配置同时写了 upstream home_backend {} 和 location / { proxy_pass http://home_backend; }，但 upstream 里的 server 写的是域名而不是 IP，导致 DNS 解析失败，从而 502。

4. 非官方渠道分发的 nginx

网上有些所谓「绿色版」「便携版」nginx 包，路径里可能带空格或中文，解压到 Program Files 这种带空格的目录里、或者包含特殊字符路径时，启动行为会变得很迷——轻则 warning，重则根本没读到正确的 conf 文件，nginx 用默认配置跑起来，任何自定义反向代理当然就 502 了。建议老老实实用官方 zip 包解压到纯英文无空格目录。

5. SNI / TLS 版本不匹配

nginx 1.24 默认支持 TLS 1.3，如果你后端是 HTTPS（比如自建的 Vaultwarden），老旧客户端握手失败也会被记成 502。这种情况需要把 ssl_protocols TLSv1.2 TLSv1.3; 显式声明，并在 proxy_ssl_server_name on; 打开。

6. IPv6 优先级问题

Win11 默认 IPv6 优先级高于 IPv4，如果 proxy_pass 写的是域名（比如 http://localhost:8123），DNS 解析可能优先拿到 ::1，而后端只监听 IPv4，链路就乱了。这种坑在新机型 + Win11 23H2/24H2 上遇到得尤其多。

三、分步解决方案

第一步：确认后端真实监听状态

PowerShell（管理员）里执行：

netstat -ano | findstr :8123
Get-NetTCPConnection -LocalPort 8123 -ErrorAction SilentlyContinue | Format-Table LocalAddress, OwningProcess

如果只看到 [::]:8123，说明只监听了 IPv6。在后端服务配置里强制改成监听 0.0.0.0 或 127.0.0.1，重启服务后再确认出现 127.0.0.1:8123 这一行。Home Assistant 的 configuration.yaml 里可以加：

http:
  server_host: 0.0.0.0
  server_port: 8123
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1
    - 192.168.1.0/24

其中 trusted_proxies 不加的话，HA 会把你所有请求识别为 127.0.0.1，登录态会出问题；很多人反过来以为 502 没解决，其实登录页进不去是另一个问题，但根因可能都是代理头没配好。

第二步：防火墙精准放行

控制面板 → Windows Defender 防火墙 → 高级设置 → 入站规则，新建两条规则放行 8123、3000 端口的 TCP 入站连接。范围只勾「本地子网」，避免公网直接暴露。如果装了第三方杀软，先关掉它的「流量防护」或「WEB 防护」功能再试一次，我自己实测这一步是有效的。

更彻底的方案是用 PowerShell 一键放行：

New-NetFirewallRule -DisplayName "Home Assistant 8123" -Direction Inbound -LocalPort 8123 -Protocol TCP -Action Allow -Profile Private -RemoteAddress LocalSubnet
New-NetFirewallRule -DisplayName "Node API 3000" -Direction Inbound -LocalPort 3000 -Protocol TCP -Action Allow -Profile Private -RemoteAddress LocalSubnet

第三步：精简并规范化 proxy 配置

最干净的反向代理配置示例，去掉多余的 upstream 块，路径统一使用正斜杠：

worker_processes  1;
events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile      on;
    keepalive_timeout  65;

    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }

    server {
        listen       8443 ssl;
        server_name  home.lan.local;

        ssl_certificate      C:/nginx/conf/cert/home.lan.local.crt;
        ssl_certificate_key  C:/nginx/conf/cert/home.lan.local.key;
        ssl_protocols        TLSv1.2 TLSv1.3;
        ssl_ciphers          HIGH:!aNULL:!MD5;

        access_log  logs/home.access.log;
        error_log   logs/home.error.log;

        location / {
            proxy_pass         http://127.0.0.1:8123;
            proxy_http_version 1.1;
            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 $scheme;
            proxy_set_header   Upgrade           $http_upgrade;
            proxy_set_header   Connection        $connection_upgrade;
            proxy_read_timeout  300s;
            proxy_send_timeout  300s;
        }
    }
}

几个关键细节解释：

• proxy_http_version 1.1 加 Upgrade/Connection 这两行一定要带上，否则 WebSocket 走不通，HA 前端会一直转圈。map 块是为了在没有 Upgrade 头时优雅降级为 close，不算花哨配置但能省掉一类隐蔽 bug。
• ssl_certificate 路径用正斜杠 /，Windows 下也建议这么写，反斜杠在 include 子文件里偶尔会被解析成转义字符，这种坑谁踩谁知道。
• 如果是自签证书，访问前先把 crt 装进「受信任的根证书颁发机构」（certmgr.msc），否则浏览器会拦一次，并在 HA 后端看到大量 Login attempt failed 日志。
• proxy_read_timeout 默认 60 秒，HA 初次加载会拉很多实体，容易超时，从外部看也是 502，建议拉到 300 秒以上比较稳。

第四步：测试与回滚

改完配置别上来就 nginx -s reload，先做语法检查：

cd C:\nginx
.\nginx.exe -t

看到 syntax is ok 和 test is successful 再 reload。日志里如果还报 502，多半就是防火墙或监听地址的问题，回到第一步继续排查。

另外建议在 conf 目录下放一个 nginx.conf.bak 备份，每次改之前复制一份。万一哪天系统重装 conf 跟着一块没了，又得从头踩一遍坑，相当浪费时间。

四、常见进阶坑位（附案例）

案例 1：HA 重启后端口被残留进程占用

某次 HA 异常退出后，8123 端口仍被一个僵尸 Python 进程占着，新进程启动失败但控制台没报错。netstat 看到的 PID 用任务管理器定位后 taskkill /F /PID xxx 即可。

案例 2：拯救者 R9000P 性能模式影响网络栈

Legion Zone 切到「安静模式」时，部分笔记本会调整网卡省电策略（RSS / 节能选项），导致 nginx 长连接偶发断开，从外部看可能是 502 或超时。解决方法要么切到「均衡模式」，要么在电源选项里把 PCI Express 链接状态节能关掉，这个是我自己翻车之后才意识到的。

案例 3：Clash / sing-box 代理软件导致回环异常

拯救者这类机器很多人同时跑代理工具，本地 127.0.0.1:7890 的代理会劫持 DNS 和 TCP 请求，nginx 的回环连接莫名其妙走代理再回来。可以在 nginx 配置里加：

proxy_bind 127.0.0.1;

强制绑定回环网卡出口，避开 TUN 模式劫持，这招基本能解决。

案例 4：老版本 nginx 与新版 Win11 偶发不兼容

升级到 Win11 较新大版本（比如 24H2）之后，部分早期版本的 nginx（比如 1.22 之前的某些版本）在某些机器上可能会触发兼容性告警或异常退出。稳妥起见用 1.24 及以上的主线版本，这类问题基本就不会出现了。

五、Win11 vs Linux 排查思路对比

维度	Linux 排查重点	Win11 排查重点
权限	SELinux / AppArmor	UAC / 管理员身份
监听	ss -tlnp	netstat -ano + 任务管理器
防火墙	iptables / nftables	Defender + 第三方杀软
用户	nginx 用户能否访问证书	证书路径权限继承
性能	ulimit / cgroup	电源模式 / VBS
日志	/var/log/nginx/	C:\nginx\logs\

说白了，Windows 上跑 nginx 反向代理最容易翻车的就两个点：一是后端服务 IPv4/IPv6 监听不一致，二是 Windows 防火墙「静默拦截」。Linux 上常见的 SELinux、权限问题在 Win 上基本不存在，排查重心别放错位置，否则就是白白浪费大半天时间。

六、配置层面硬性 Checklist

为了减少下次再翻车，我把这次能跑通的配置整理成一份 Checklist，建议收藏：

• nginx proxy_pass 写死 IPv4 地址，不要用域名
• 后端服务显式 listen 0.0.0.0:port
• proxy_http_version 1.1 + WebSocket 三件套齐全
• proxy_bind 127.0.0.1; 避免被代理软件劫持
• proxy_read_timeout ≥ 300s
• trusted_proxies 在 HA 中显式声明 127.0.0.1
• 自签证书导入「受信任的根证书颁发机构」
• Defender 防火墙放行入站 TCP 端口
• 关闭第三方杀软的「流量防护」
• nginx -t 通过后再 reload
• 性能模式切到「均衡」或「野兽」

七、小结

---

如果你也遇到过类似的奇葩 502，欢迎评论区贴一下你的 error.log，一起看看还有没有别的隐藏坑。

如需选购适合的笔记本电脑，可参考 Thinkpad深圳报价。