nginx 中 proxy_pass 支持带端口的后端地址，但需规避路径拼接错误、变量拼接失效和协议不匹配三类问题；直接写死如 http://192.168.1.100:3000/ 最稳妥；变量必须为完整 uri（如 set $backend "http://svc-a:8080"; proxy_pass $backend/），禁止拼接 $host:$port；https 后端须显式写 :443，dns 动态解析需 resolver 与 set 同 location 块且端口写在 proxy_pass 中。
在 Nginx 中，proxy_pass 直接支持带端口号的后端地址，只要格式合法、网络可达，就能正常工作。关键不是“能不能加端口”，而是**怎么加才不踩坑**——尤其要避开路径拼接错误、变量失效、协议不匹配这三类高频问题。
直接写死端口：最简单也最常用
适用于后端地址固定、无动态切换需求的场景。语法清晰，无运行时开销。
-
HTTP 后端（含端口）：
proxy_pass http://192.168.1.100:3000/; -
HTTPS 后端（显式写 https + 端口）：
proxy_pass https://api.example.com:8443/; -
注意结尾 / 的作用：加
/会剥离 location 匹配前缀；不加则原样透传。例如：location /v1/ { proxy_pass http://backend:8080/; }将/v1/users转发为http://backend:8080/users
用变量带端口：必须保证变量是完整 URI
Nginx 不允许在 proxy_pass 中拼接字符串（如 http://$host:$port 会报错）。若需动态端口，变量本身必须是合法 URI。
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- ✅ 正确写法（变量值含协议+主机+端口+可选路径）：
set $backend "http://svc-a:8080";<br>proxy_pass $backend/;
- ❌ 错误写法（运行时报 “invalid URL prefix”）：
set $host "svc-a"; set $port "8080";<br>proxy_pass http://$host:$port/;
（Nginx 不解析这种拼接） - 推荐替代方案：用
map预定义组合好的 URI 字符串，更安全可控
DNS 动态解析 + 端口：适合云环境或服务发现
当后端域名对应多个 IP 或 IP 经常变化（如 Kubernetes Service、ECS 实例），需配合 resolver 和 set 使用，端口必须显式写出。
location /api/ {<br> resolver 114.114.114.114 valid=5s;<br> set $upstream "api-prod.internal";<br> proxy_pass https://$upstream:443/;<br>}-
必须注意：
resolver和set必须与proxy_pass在同一 location 块内；$upstream只能是纯域名，不能带协议或路径；端口写在proxy_pass的 URI 中，不可省略
常见端口相关陷阱与规避方式
很多 502/504 或路径错乱问题，其实源于端口配置的细节疏忽。
-
HTTPS 后端没写端口却走默认 80：如果写
proxy_pass https://backend;，Nginx 默认尝试连 80 端口（不是 443！），导致连接拒绝。务必显式写https://backend:443/ -
后端监听 localhost 导致代理失败：如后端只绑
127.0.0.1:3000，而 Nginx 在容器或另一台机器上，就会连不上。应改用0.0.0.0:3000或实际可路由的 IP - 防火墙或 SELinux 拦截非标准端口：比如用了 8081、9000 等端口，确认系统防火墙放行，且容器网络策略允许跨端口通信
