': The requested URL returned error: 500"

When I clone (haven't tested push or pull yet) a repo with HTTPS git fails with the following message:

$ git clone https://git.***.nl/omkelderman/testproject.git
Cloning into 'testproject'...
fatal: unable to access 'https://git.***.nl/omkelderman/testproject.git/': The requested URL returned error: 500

(I removed my domain ^^, cause why not)

I should tell that with my setup currently unicorn only listens on a domain socket and not on a TCP port (I like to use as few TCP-ports as possible) For this to work I had to edit the gitlab-shell-config to set gitlab_url to my external domain, since thats the only TCP-endpoint there is. This works completely fine and always has been. So when this gitlab-git-http-server thing got added to gitlab, I thought, lets do the same for this (cause obviously it didnt work since it tried to connect to localhost:8080 on which something else is doing something). I changed /etc/default/gitlab and set the -authBackend to the external domain as well, just as I did with gitlab-shell.

So the https-requests from the git-client are reaching the gitlab-git-http-server, since my gitlab-git-http-server.log file is full with lines like

2015/10/01 21:40:16 GET "/omkelderman/testproject.git/info/refs?service=git-upload-pack"

Same goes for my access.log of nginx, it also lists the same GET-requests of above (obviously, since nginx has to handle these requests as well since there is no direct connection possible to the unicorn-server)

But than I opened my error.log of nginx and it contained the following line:

2015/10/01 21:34:25 [alert] 9846#9846: *83494 socket() failed (24: Too many open files) while connecting to upstream, client: 127.0.0.1, server: git.***.nl, request: "GET /omkelderman/testproject.git/info/refs?service=git-upload-pak HTTP/1.1", upstream: "http://unix:/home/git/gitlab/tmp/sockets/gitlab-git-http-server.socket:/omkelderman/testproject.git/info/refs?service=git-upload-pack", host: "git.***.nl"

So nginx is cutting of the connection due to, what? To many simultaneously open connections? (It says files, but yeah, on linux everything is a file right?)

I guess the most obvious solution here would be to configure unicorn to listen on a TCP-port again (yay for direct connections without having nginx in between them for both this and gitlab-shell). But like I said before, I don't like to use TCP-ports for things that are basically just internal connections.

An other solution would be to allow the -authBackend to be a unix-domain-socket. Not sure if that is already possible...

And maybe I could tweak some nginx-settings to allow more.. uhm, yeah more what? :P I have googled a bit on that error and found some config-changes, but I'm not sure if that would have a negative effect. I can imagine that that limit is there to prevent flood-attacks on the webserver..?? Idk, I'm a bit of a noob on that matter...