xdebug not receiving connections

I've debugged on this machine before, but for some reason it's no longer receiving connections.

I'm running Ubuntu 13.10 and PhpStorm 7.

My server is PHP5.5/NginX/FastCGI. Xdebug is running on port 9009.

xdebug.log always outputs a version of this:

I: Connecting to configured address/port: localhost:9009.
E: Could not connect to client. :-(

Xdebug is listening on port 9009, Can accept external connections is set.

I've clicked listen for debugger connections.

I've tried changing my xdebug remote_host to my IP address, to no effect.

I'm also accessing the site with ?XDEBUG_SESSION_START=PHPSTORM

What else could I be missing? phpinfo() below.
xdebug support enabled
Version 2.2.3

Supported protocols Revision
DBGp - Common DeBuGger Protocol $Revision: 1.145 $

Directive Local Value Master Value
xdebug.auto_trace Off Off
xdebug.cli_color 0 0
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.coverage_enable On On
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 no value no value
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 Off Off
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 /tmp/xdebug.log /tmp/xdebug.log
xdebug.remote_mode req req
xdebug.remote_port 9009 9009
xdebug.scream Off Off
xdebug.show_exception_trace Off Off
xdebug.show_local_vars Off Off
xdebug.show_mem_delta Off Off
xdebug.trace_enable_trigger 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
Comment actions Permalink

Hi there,

1) Once you clicked on that "phone handle" icon, go into your console and ensure that PhpStorm is the one who listens on that xdebug port and on correct network interface (netstat, I guess -- sorry, not a linux user). Maybe some another app occupies it.

2) Try to connect to xdebug port via telnet -- see if connection will be successfull this way

3) Try actual IP address ( instead of domain name (P.S. You may need to restart your web server after making changes in php.ini). Alternatively try "xdebug.remote_connect_back = 1" -- will ignore what you have in your xdebug.remote_host

Comment actions Permalink

1. when i run netstat -an | grep ':9009' with PhpStorm listening, i get this:
tcp        0      0  *               LISTEN
when i run it without PhpStorm listening, i get nothing. so it looks like that's the only app using it.

2. from my server when i run telnet <workstation IP> 9009 i get this:
telnet: Unable to connect to remote host: Connection refused

3. restarted both my web server and php5 fastcgi process manager with xdebug.remote_connect_back=1 once and with xdebug.remote_host= - no change.     
Comment actions Permalink


from my server when i run telnet

As I understand it's either virtual server (local or remote) or real server somewhere on network, right?

Is it somewhere on internet or local? Behind router?

2) When PhpStorm is listening on 9009 port -- try connecting from your workstation and not from server (ip =

3) If above produces results -- then it has to be firewall, be it on local workstation or on server (or even router)

Comment actions Permalink

OK, i figured it out. what i had to do:

on my local machine, i ran the following:

ssh -v -R 9003:localhost:9003 joe@{hostname}.com

then i ran the listener and refreshed the page. success.


Please sign in to leave a comment.