Using Xdebug when the php application sits behind

问题:

I'm trying to set up Xdebug remote debugging to a site sitting behind Varnish as a caching layer using PHPStorm.

Varnish is sitting as a frontend on port 80 with Apache talking to it as a backend on port 8080.

If I bypass Varnish and talk directly to the site on port 8080 Xdebug and Phpstorm work as expected, however then I'm not really testing the system properly - what I really need to do is trigger a debug session even when the request is proxied through Varnish.

Obviously I'm not expecting cached content to trigger a debug session, but uncached content still should.

My Xdebug settings are as follows:

; xdebug
xdebug.remote_enable = 1
xdebug.remote_connect_back = 1
xdebug.remote_port = 9000
xdebug.scream=0
xdebug.cli_color=1
xdebug.show_local_vars=1

回答1:

Xdebug has support to try to connect back to an IP provided in X_HTTP_FORWARDED_FOR since 2.2.0 (fixed a bug in 2.2.2), see bugs #598 & #660. Depending on your Varnish version you might have to add the header or it might be set for you by varnish.

If you set the header your original configuration should work.

Add in vcl_recv:

if (req.http.x-forwarded-for) {
     set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip;
} else {
     set req.http.X-Forwarded-For = client.ip;
}

回答2:

As usual asking the question exposed the answer...

It seems that out of the box the request IP address doesn't get mapped through varnish to php as $_SERVER[REMOTE_ADDR], so with remote_connect_back enabled Xdebug is attempting to connect back not to PHPStorm but instead to Varnish itself.

Changing the xdebug settings to explicitly set the remote_host solved the problem as follows:

; xdebug
xdebug.remote_enable = 1
xdebug.remote_connect_back = 0
xdebug.remote_host = 192.168.150.1
xdebug.remote_port = 9000
xdebug.scream=0
xdebug.cli_color=1
xdebug.show_local_vars=1

In this case it works fine for me as I'm always requesting from 192.168.150.1 (this is the host machine for my dev VMs)

A more generic solution would I guess remap the REMOTE_ADDR field to the originating IP rather than Varnish's IP.