Xdebug not triggering

I've read a whole bunch of threads related to this problem but none have helped me out.

I have xdebug setup properly on my server:



phpinfo says:


xdebug support    enabled

Version     2.1.0

Supported protocols    Revision

DBGp - Common DeBuGger Protocol     $Revision: 1.145 $

Directive    Local Value    Master Value

xdebug.auto_trace    Off    Off

xdebug.collect_assignments    Off    Off

xdebug.collect_includes    On    On

xdebug.collect_params    0    0

xdebug.collect_return    Off    Off

xdebug.collect_vars    Off    Off

xdebug.default_enable    On    On

xdebug.dump.COOKIE    no value    no value

xdebug.dump.ENV    no value    no value

xdebug.dump.FILES    no value    no value

xdebug.dump.GET    no value    no value

xdebug.dump.POST    no value    no value

xdebug.dump.REQUEST    no value    no value

xdebug.dump.SERVER    no value    no value

xdebug.dump.SESSION    no value    no value

xdebug.dump_globals    On    On

xdebug.dump_once    On    On

xdebug.dump_undefined    Off    Off

xdebug.extended_info    On    On

xdebug.file_link_format    no value    no value

xdebug.idekey    netbeans-xdebug    netbeans-xdebug

xdebug.manual_url    http://www.php.net    http://www.php.net

xdebug.max_nesting_level    100    100

xdebug.overload_var_dump    On    On

xdebug.profiler_aggregate    Off    Off

xdebug.profiler_append    Off    Off

xdebug.profiler_enable    Off    Off

xdebug.profiler_enable_trigger    Off    Off

xdebug.profiler_output_dir    /tmp    /tmp

xdebug.profiler_output_name    cachegrind.out.%p    cachegrind.out.%p

xdebug.remote_autostart    On    On

xdebug.remote_connect_back    Off    Off

xdebug.remote_cookie_expire_time    3600    3600

xdebug.remote_enable    On    On

xdebug.remote_handler    dbgp    dbgp

xdebug.remote_host    localhost    localhost

xdebug.remote_log    no value    no value

xdebug.remote_mode    req    req

xdebug.remote_port    9000    9000

xdebug.scream    Off    Off

xdebug.show_exception_trace    Off    Off

xdebug.show_local_vars    Off    Off

xdebug.show_mem_delta    Off    Off

xdebug.trace_format    0    0

xdebug.trace_options    0    0

xdebug.trace_output_dir    /tmp    /tmp

xdebug.trace_output_name    trace.%c    trace.%c

xdebug.var_display_max_children    128    128

xdebug.var_display_max_data    512    512

xdebug.var_display_max_depth    3    3

I start listening on port 9000 in PHPstorm. Have installed the easy xdebug add-on for firefox. Everything seems good to go. Set a breakpoint in PHPstorm. Navigate to the file in firefox and nothing happens. The breakpoint is on the first line and the file loads properly in Firefox.

Please help!


FYI this is the first time I'm ever using Xdebug so I might be missing something really obvious! I keep seeing some talk about "path mapping".

In run/debug configurations, I go to configure the server and there I see a checkbox for "use path mappings". It's de-selected right now, but even if I select it, nothing changes. The local directory path corresponds to the / path on my remote server.

Log file attached


Hello Areeb,

Your Xdebug configuration looks OK. PhpStorm will force break at the first line if there are any problems with path mappings. The current problem is that xdebug doesn't connect to PhpStorm.
Please describe your server/project configuration. Does the server and IDE work on the same machine?

Thank you for feedback!



No it's a remote linux server.

I've set up the "remote debugging" configuration in PHPStorm (I think properly).



No it's a remote linux server.

So you have a mistake in your xdebug configuration.
Please pay attention to xdebug.remote_host settings in you php.ini.
from http://xdebug.org/docs/remote:

Type: string, Default value: localhost
Selects the host where the debug client is running, you can either use a host name or an IP address. This setting is ignored if xdebug.remote_connect_back is enabled.

Your current value is 'localhost' but should be an ip adress of machine on which PhpStorm is running.

Please try to change you xdebug configuration and report here about results.


If I change that line to my IP address all the pages on my site take a really long time to load. Same problem if I change xdebug.remote_connect_back to 1

And even with the slow load times, the breakpoint isn't being hit.



If I change that line to my IP address all the pages on my site take a really long time to load. Same problem if I change xdebug.remote_connect_back to 1

Please set xdebug.remote_host to your client ip, select "Use path mappings" checkbox(it is even better to remove any servers from PHP -> Servers and use zero-configuration), enable listen debug button and try to debug again.

If debugging will not work again, attach your idea.log here(pay attention that you should use "#com.jetbrains.php.debug" as cetegory_name).


FYI, XDebug does make pages load very slow....at least it has always done that for me.

And as was stated, the zero-config works great. I just set these settings in my php.ini:


And then click the Listen button!



FYI, XDebug does make pages load very slow....at least it has always done that for me.

It should work a bit faster when 'Listen' button is enabled.

Thanks for sharing!


I'm ok with the pages loading slow for me, but they also load slow for all my site visitors. Can I avoid that somehow?


Yes. Turn it off. Seriously, I wrote a script that turns it on and off...wait...are you running XDebug on your production server?



Use xdebug.remote_host setting instead of xdebug.remote_connect_back setting.
Using of xdebug.remote_connect_back is unsafe on production server.

from http://xdebug.org/docs/remote:

Type: boolean, Default value: 0, Introduced in Xdebug 2.1
If enabled, the xdebug.remote_host setting is ignored and Xdebug will try to connect to the client that made the HTTP request. It checks the $_SERVER['REMOTE_ADDR'] variable to find out which IP address to use. Please note that there is no filter available, and anybody who can connect to the webserver will then be able to start a debugging session, even if their address does not match xdebug.remote_host.

So any user can debug your webserver.

Also all speed of connection related problems caused by usage of xdebug.remote_connect_back setting.


I used the remote_host option with my IP and it was still loading incredibly slow on computers that didn't have that IP.

I also used the remote_connect_back and that was no better.



Does debugging with Xdebug start work for you? I mean original topic of the thread.

I used the remote_host option with my IP and it was still loading incredibly slow on computers that didn't have that IP.

I also used the remote_connect_back and that was no better.
Disable xdebug.remote_connect_back and enable xdebug.remote_host. Do you still have an issue?

No it still didn't work even with the slow load times. And I have tried disabling remote_connect_back and only having the "remote_host" enabled but it's still horribly slow. But I mean I don't care if it works if the load times are that slow, it's a very busy web server and I can't afford any speed decreases. I guess it's back to echo statements for me :(



Do you have development server?


Yea I guess I could do it on a separate development server, but this one has all the MySQL database entries I wanted to test with. Ok will figure out a solution. Thanks for the help though, will get in touch with you guys if I can't get it working on the development server.


XDebug, in my experience slows down pages loads terribly, once it's loaded, no matter what you do (I'd love for someone to show me a way to make it not the case.)

Like I said, I wrote a script that turns it on and off, but we don't debug on our production server.

Just as a suggestion, what we do is run IIS locally and attach to the database (we have a dev schema for major changes and testing), but that way we are not developing on the live server, but still have access to the real data for testing (you could also create a MySQL slave locally and use that for testing, assuming your MySQL server is on-site...well, even if it isn't, but that's tricky.)

Anyway, that allows us to turn XDebug on and off as we need it.


Please sign in to leave a comment.