nginx php-fpm xdebug netbeans can start only one debug session

Thank you, everyone who tried to think in the direction of my problem.I've solve it successfully.

1. First problem (with 504 error) could be solved by nginx option fastcgi_read_timeout, for example, it could be fastcgi_read_timeout 600; for tell nginx that it should wait for 600 seconds. It should be placed to host's config file, or to /etc/nginx/fastcgi_params (in Debian)
2. Second problem was caused by option in my xdebug.conf: xdebug.remote_autostart=1;, it should be xdebug.remote_autostart=0;. I doesn't understand the real meaning of this option, but it does following: Any php script automatically trying to connect to debugger (netbeans in my case). So, in some case, netbeans loses a connection, and when I press "Start debugging", it doesn't know, that new connection should be opened, and waiting for xdebug client forever. Now, with the mentioned option, I can start and stop debugging any time when I need it.
3. Third problem had the same source, as the second one. All others scripts, running on my server have tried to connect to netbeans, but with lost connection it was senseless.

Anyway, I hope this would help someone, who want to solve similar problems. StackOverflow helped me by forcing me to definitely describe my problem, and in this process I've gained new ideas on what to try.

When updating fastcgi_read_timeout you can increase the time limit for all sites on the server (vagrant homestead VM in my case) you can do the following once you've SSH'd into your VM:

sudo pico /etc/nginx/nginx.conf

and add

fastcgi_read_timeout 300;

to the http section.

For everyone having the same problem where the accepted answer did not work, in my case, it was a recently installed application that was blocking xdebug.

My company has remote access to install security software on my laptop so they installed ESET Endpoint Security.app and ESET Remote Administrator Agent.app which apparently also filters localhost connections. It took me two days until I finally noticed that there was an ESET daemon running and blocking connections on 127.0.0.1:9000.

The solution was to move to trash both applications since I don't have the necessary admin privileges to disable filtering in the application settings.