Nginx通过proxy_pass unix:/path/to.sock可实现UDS高性能代理，路径须为绝对路径、无协议前缀或端口，且Nginx worker需对socket文件及父目录具备读写执行权限；/run/目录推荐用于避免磁盘I/O与清理风险。
直接用 proxy_pass 指向 Unix Domain Socket（UDS）能显著降低延迟、减少 CPU 开销，但配置稍有偏差就会报 Connection refused 或 Permission denied——不是所有路径写法都等效，也不是所有权限组合都可行。
proxy_pass unix:/path/to.sock 的写法必须严格匹配
UDS 路径不能加协议前缀，也不能带端口；unix:/run/app.sock 是合法的，http://unix:/run/app.sock 或 unix:/run/app.sock:8000 会直接导致 Nginx 启动失败，错误信息是：invalid URL prefix in "unix:/..."。
- 路径必须是绝对路径，相对路径如
unix:./app.sock不被支持 - 路径中不能包含空格或特殊 shell 字符（如
$、~），Nginx 不做变量展开 - 推荐放在
/run/下（tmpfs 内存文件系统），避免磁盘 I/O 和系统清理干扰，比如unix:/run/myapi.sock - 如果后端监听的是抽象命名空间 socket（Linux 特有），Nginx 不支持，必须用文件系统路径
Permission denied 的根本原因和修复顺序
常见现象是 Nginx 日志里反复出现 connect() to unix:/run/myapi.sock failed (13: Permission denied)，这和「文件是否存在」无关，而是权限链断裂。
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 确认 socket 文件属主/组：例如
root:www-data，且权限至少为660（即srw-rw----） - 确认 Nginx worker 进程运行用户：检查
nginx.conf中的user指令，通常是www-data；若为nobody，需同步调整 socket 所属组 - 检查 socket 父目录权限：Nginx 必须对
/run/及其子目录有执行（x）权限才能进入并访问 socket 文件 - systemd 管理的服务需在
.socket单元中显式设置SocketGroup=www-data和SocketMode=0660
与 TCP loopback 对比时容易忽略的性能边界
UDS 在单机高并发场景下确实更快，但它的优势只在连接建立和短请求中明显；长连接、大包传输、TLS 终止等环节的收益会被稀释。
- 实测显示：QPS 提升约 12%–18%，99% 延迟下降 0.3–0.8ms（基于 16 核机器 + Gunicorn + JSON API）
- 当后端服务本身成为瓶颈（如 Python GIL 限制、数据库慢查询），换 UDS 几乎无感
- UDS 不支持健康检查（
upstream的max_fails、fail_timeout对 UDS 失效），出错时 Nginx 默认静默重试，需靠日志或外部监控捕获 - 调试难度略高：无法用
telnet或curl直连 UDS，得用nc -U /run/app.sock或curl --unix-socket /run/app.sock http://localhost/
真正卡住人的往往不是「能不能配通」，而是「配通之后为什么没变快」——先确认后端是否真在 socket 上响应，再看 Nginx 是否真的用了它（nginx -T 输出里搜 unix:），最后才对比压测数据。UDS 是利器，但不是银弹。
