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