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 文件的属主、属组和权限直接影响连接是否成功：

Bailian Usage Proxy

阿里百炼大模型平台多人共享账号用量统计代理服务。解决公司共用账号时无法区分个人用量的问题。适用场景：1)部署用量统计代理；2)统计多人Token用量和调用次数；3)管理大模型API调用配额。

下载

• 推荐做法：让后端服务（如 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 或后端自行处理