Unix sockets for fastcgi_pass

[mike]

On 9/1/08, Chris Savery <chrissavery at gmail.com> wrote:
> Hello,
>
> I just tested out using unix sockets for fastcgi_pass instead of the often
> seen 127.0.0.1:9000.
> It worked fine as far as I could tell.
>
> Is there some reason no one seems to do this? I've read that sockets are
> faster (don't know how much though) and probably more secure since they
> aren't potentially exposed to the net. So that sounds better to me but I see
> everyone seems to configure php using 127.0.0.1:9000.
>
> Unix sockets only work on the same machine, right? So that would knock it
> out for many situations. But for my use right now this would work. Is there
> another reason not to do it?
>
> Chris :)
>

I've heard of people having problems with sockets in the past, and
switching to TCP resolved it. (disclaimer: this information may be
old, and newer kernels/whatever could have removed that from being an
issue)

I've been using connections over localhost forever and never have had
any issues - so if it isn't broke, why fix it? It seems plenty fast
too :)

You won't be exposing your FastCGI engines to the network if you bind
it to localhost - it will only be accessable via the localhost
interface then.

Sockets can provide more security as you can use filesystem
permissions to control them (you can't easily allow/deny specific
users to specific ports), they could (for all I know) be faster, I
believe you can use them over NFS exports (but you probably wouldn't
want to, might as well just start FastCGI over TCP and bind it to a
network-accessable IP)