自建FCGI连Flup仅TCP可用，为何lighttpd用UDS可正常通信？

• 我自行实现了一套适配自有Web服务器的FCGI协议，原本打算替换当前基于lighttpd的简易部署方案，调试过程中发现了异常：手动拉起Python-Flup服务后，我的实现仅能通过TCP Socket（对应代码位置在async-fcgi项目src/client/con_pool.rs第168行）完成正常对接；而原有Flup结合lighttpd的部署链路，使用*Unix域套接字（UDS）*可以正常运行。
• 我明确知道FCGI的常规运行逻辑：Web服务器会把监听套接字作为*stdin（标准输入）*传递给FCGI服务进程。我对照查阅了Flup的源码（本地安装版本以及Flup Py3开源仓库的flup/server/fcgi_base.py第1025行），发现Flup的服务逻辑看起来仅处理TCP连接，按常理UDS是无法正常工作的，但在lighttpd部署场景下却稳定运行。
• 我当前使用的lighttpd fastcgi配置如下：

fastcgi.server = (
    "/heiz" =>
    (
       "python-fcgi" =>
       (
        "socket" => "/tmp/fastcgi2.python.sock",
        "bin-path" => "/var/www/heiz/flup.fcgi",
        "check-local" => "disable",
        "max-procs" => 1
       )
    )
)

• 部署完成后执行套接字状态查询的输出如下：

sudo ss -lxp | grep /tmp/fastcgi2.python.sock 
u_str LISTEN 0      1024                    /tmp/fastcgi2.python.sock-0 4378053                                          * 0                                     users:(("flup.fcgi",pid=349092,fd=3),("flup.fcgi",pid=349092,fd=0))

• 目前我完全无法定位该现象的成因，也不清楚自己遗漏了哪部分逻辑。我推测问题可能出在lighttpd的gw_backend.c模块第1496行、第574行的代码段，怀疑是不是该模块的特殊文件描述符处理逻辑（也就是开发者提到的“magic”逻辑）导致了这种行为差异，暂时没有明确的排查方向。

内容的提问来源于stack exchange，提问作者U65k