Nginx可通过proxy_pass直接代理Unix域套接字，语法为unix:/path/to/socket，要求绝对路径、Nginx工作进程具备读写权限，并需协调后端服务与Nginx用户权限及socket生命周期管理。
在单机部署场景下，用 proxy_pass 指向 Unix Domain Socket（UDS）而非 TCP 地址，能显著降低网络栈开销、减少上下文切换和内存拷贝，实测吞吐可提升 15%–30%，延迟下降约 20%。关键不在“能不能用”，而在于路径权限、Nginx 用户权限、socket 文件生命周期这三点必须对齐。
Unix Domain Socket 路径配置要点
UDS 路径必须是绝对路径，且不能带协议前缀（如 http:// 或 unix://）。Nginx 的 proxy_pass 语法只接受 unix:/path/to/socket 格式：
- ✅ 正确写法：
proxy_pass unix:/var/run/backend.sock; - ❌ 错误写法：
proxy_pass http://unix:/var/run/backend.sock;或proxy_pass /var/run/backend.sock; - socket 文件所在目录（如
/var/run/）需存在，且 Nginx worker 进程有读写权限
Nginx 用户与后端服务的权限协同
UDS 本质是文件，其 socket 文件的属主、属组和权限直接影响连接是否成功：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 推荐做法：让后端服务（如 Gunicorn、uWSGI、Node.js）以与 Nginx 相同的用户启动，例如都用
www-data；或显式设置 socket 属组为www-data，并开启组写权限（chmod 660） - 检查命令：
ls -l /var/run/backend.sock，确认srw-rw----类型且组权限可写 - 若 Nginx 启动用户为
nginx，而后端以app用户运行，又未做组授权，则会报connect() to unix:/var/run/backend.sock failed (13: Permission denied)
避免 socket 文件残留导致启动失败
后端服务异常退出时，UDS 文件可能未被自动清理，而 Nginx reload 或重启时会因文件已存在而报错：
- 后端启动脚本中加入清理逻辑，例如：
rm -f /var/run/backend.sock && exec gunicorn --bind unix:/var/run/backend.sock ... - Nginx 配置中不建议加
proxy_next_upstream error timeout http_502;来“兜底”UDS 连接失败——这无法解决根本权限或文件残留问题，只会掩盖配置缺陷 - 可通过 systemd 的
RuntimeDirectory=或tmpfiles.d提前声明 socket 目录，确保每次启动环境干净
对比 TCP 代理的典型配置差异
同一后端服务，TCP 和 UDS 的 proxy_pass 行为差异明显：
- TCP 模式：
proxy_pass http://127.0.0.1:8000;—— URI 完全透传，location /api/下请求/api/v1/user会转发为http://127.0.0.1:8000/api/v1/user - UDS 模式：
proxy_pass http://unix:/var/run/backend.sock;—— URI 处理逻辑完全一致，但底层走的是本地 IPC，不经过 loopback 网卡和 netfilter - 注意：
proxy_pass后不能跟 URI 路径（如unix:/path.sock:/prefix是非法语法），路径映射需靠location+rewrite或后端自行处理
