PHPStorm stuck on waiting for incoming connection

If I try to use port 9000 in php.ini, PHPStorm debug server settings, and settings > debug then the page won't even load when I start the debugger.

Hi there,

>xdebug.remote_port=80

>I have Settings > Languages > PHP > Debug > Xdebug set to port 80 and accepting incoming

Why port 80?

Do you run PhpStorm under sudo? You need that on Linux/Mac as using ports under 1024 require root rights.

>This is my xdebug.log:

Based on the log (if that's the log .. since it's truncated a lot) ... it connects to somewhere and that service just tells "go away". Right now it looks like it connects to a web server (which is commonly runs on TCP 80)...

>I have the Run > "Debugger" > Server set to port 80 and using path mapping (the server is remote)

So ... where the actual server is located -- is that the same computer/OS .. or that is a remote server (another computer / VM) ?

If it's remote server .. then why do you configure xdebug to connect to the localhost ..?

https://xdebug.org/docs/remote -- it explains how the debugging process works in details -- please have a read.

I was using port 80 because port 9000 will not load on my website.

My server is a VPS running on Digital Ocean, it is Ubuntu 16.04.3, running Apache 2.4.18, PHP 7.0.24 with Xdebug 2.5.5.

My system is Windows 10, PHPStorm 2017.2.4.

Capturing port traffic did indicate my server is reaching out to PHPStorm:

listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
09:12:02.480276 IP zbee.me.49255 > 23.110.xxx.122.9000: Flags [S], seq 1532331019, win 29200, options [mss 1460,sackOK,TS val
55011815 ecr 0,nop,wscale 8], length 0

And I do see an attempt for my server to contact PHPStorm in my firewall -the port, application, and originating IP address (my server) are all explicitly open- and it is not blocked.

My xdebug php.ini setup is now:

[xdebug]
zend_extension="/usr/lib/php/20151012/xdebug.so"
xdebug.var_display_max_depth=7
xdebug.default_enable=1
xdebug.remote_enable=1
xdebug.profiler_enable=1
xdebug.remote_log=/tmp/xdebug.log
xdebug.remote_connect_back=0
xdebug.remote_host=23.110.xxx.122
xdebug.remote_port=9000
xdebug.remote_autostart=1

My latest xdebug log entries are all:

Log opened at 2017-10-20 15:15:43
I: Connecting to configured address/port: 23.110.xxx.122:9000.
E: Time-out connecting to client. :-(
Log closed at 2017-10-20 15:15:43

>And I do see an attempt for my server to contact PHPStorm in my firewall -the port, application, and originating IP address (my server) are all explicitly open- and it is not blocked.

OK .. so your server does not have any SELinux (or alike) restrictions that would prevent Apache from making outgoing request. Am I right? If so -- great.

>My latest xdebug log entries are all:

Now it must be your firewall (e.g. router or one on your PC) or PhpStorm is not listening the right port (or at all). That's assuming you have provided the correct IP, of course.

How did you initiate debugger in PhpStorm? Is it listening for incoming debugging requests?

Debugger is initiated when you either click "Debug" button (then it initiates debugger listener and launches the actual request (script/page load in browser)) .. or by activating "phone handle" icon (in this case debugger is passively listens in background .. and when debug request comes in it brings debugger tool window).

So .. activate "phone handle" icon and then verify/ensure that it's PhpStorm who actually listens on xdebug TCP 9000 port (for Windows it would be "netstat -a -b -o -n" or something close to it).

You can also try connecting from server to your PC (with debugger listening) using telnet or alike -- it will tell you if connection is reaching your PC or not. If not -- firewall/routing/wrong IP issue.

P.S. Obviously, providing your exact IP address this way in php.ini can be inconvenient if it changes often (ISP gives dynamic IPs every day or after each router reboot). In this case you may use SSH tunnel: establish SSH tunnel to remote server first and on remote server tell xdebug to connect to localhost so SSH can forward it back to your PC. This way you do not have to provide your IP and server does not make any outgoing connections. You may switch to this way later.

https://confluence.jetbrains.com/display/PhpStorm/Debugging+with+PhpStorm

 [svchost.exe]
  TCP    0.0.0.0:9000           0.0.0.0:0              LISTENING       5532
 [phpstorm64.exe]
  TCP    0.0.0.0:9330           0.0.0.0:0              LISTENING       2736

Log opened at 2017-10-20 17:05:30
I: Checking remote connect back address.
I: Checking header 'HTTP_X_FORWARDED_FOR'.
I: Remote address found, connecting to 173.248.xxx.50,66.102.6.xxx:9000.
W: Creating socket for '173.248.xxx.50,66.102.6.xxx:9000', getaddrinfo: Bad message.
E: Could not connect to client. :-(
Log closed at 2017-10-20 17:05:31

I tried having PHP listen for a set ide key, setting that ide key on my server, setting xdebug to send the data to my server (from my server), and having putty forward the traffic back from the tunnel to phpstorm on port 9000, and that didn't even work; PHPStorm did nothing, and I followed that guide completely.

I cannot figure out how to use telnet to check if my server can connect to my computer. Every forum or question post I find telling the poster to use telnet says only that, it does not tell anyone how to do so.

>I cannot figure out how to use telnet to check if my server can connect to my computer. Every forum or question post I find telling the poster to use telnet says only that, it does not tell anyone how to do so.

You connect to your IP:port with telnet and see what response it will give -- if it fails to connect it means firewall/wrong IP:port issue at some place in the chain.

Here is how it looks if I try to connect to my local PhpStorm while it does NOT listen for connections (Windows 10)

But when it connects (when "phone handle" is ON) then I see blank screen.

>I tried having PHP listen for a set ide key, setting that ide key on my server, setting xdebug to send the data to my server (from my server), and having putty forward the traffic back from the tunnel to phpstorm on port 9000, and that didn't even work; PHPStorm did nothing, and I followed that guide completely.

Try with brand new project in PhpStorm (to avoid any already-made misconfiguration that possibly sits in this current project settings) and try with very basic script.

In any case: when IDE is listening for debug connections and it receives correctly formulated request (that XML-like string that xdebug sends or whatever the actual format is) it will respond in some way. You may try to enable extra logging from IDE side and see if it will give any details -- https://intellij-support.jetbrains.com/hc/en-us/articles/207241115-How-to-Collecting-PhpStorm-WebStorm-debug-Logs

The biggest issue is that so far xdebug log says: I'm unable to even connect to debug client; the negotiating stage (sending actual data) does not even kick in. So for me it looks like IP/firewall/router/AntiVirus/InternetSecurity kind of issue (based on the info so far).

I may suggest to triple check IP and stuff in this way -- setup some basic web server (IIS or Apache) on your PC on non-standard port (e.g. NOT 8080 or alike -- try 9001 or other "random" ports) and try to fetch a page from there from your remote server (using curl or text-based browser like lynx etc). If it works -- IP:port is fine and it's something else with PhpStorm (right now, sitting here and not seeing whole actual PhpStorm setup -- no other ideas what it might be).

If you think it's PhpStorm itself (e.g. corrupt install or something -- everything is possible) -- back up your current settings ( Directories used by the IDE to store settings, caches, plugins and logs  ) and delete them; uninstall PhpStorm and install it again without importing any past settings (brand new setup); try to debug very simple code (few very basic instructions). Hell ... even simple PC reboot may help here (helps even on Mac not mentioning Windows).

BTW -- IDE now seems to remember the "phone handle" status between restarts (was introduced somewhere in 2017.2) . If it starts with that already ON -- try disabling/enabling in again (even 2 times) -- maybe it just stuck...

P.P.S. Perhaps Wireshark can be of any help here (if you know how to use it/analyse the data) -- it may give some insights incoming connections. You seem to know the network stuff and are 100% sure that IP is correct and ports are properly allowed .. so it might be an unnecessary step... It's just as per your xdebug logs ... it used different IPs when hardcoded and autodetected is set (connect_back option) ... that's why I still consider wrong IP/network as possibility here.