Unable to get PHPStorm to connect to xdebug running in WSL 2
I am having trouble getting PHPStorm 2020.2 to work with xdebug with the following setup:
WSL2 running Ubuntu 20, with php and php-xdebug installed. Whenever I run my tests with debugging enabled it says "Connection was not established.".
This is what the xdebug log shows:
[5877] Log opened at 2020-08-14 17:20:45
[5877] I: Connecting to configured address/port: 172.18.48.1:9006.
[5877] E: Time-out connecting to client (Waited: 200 ms). :-(
[5877] Log closed at 2020-08-14 17:20:46
This is for CLI only, I'm not trying to connect via php-fpm (so no apache, nginx, ...).
So far I have tried:
- Changing the port to something other than 9000 (portscans also reveal that none of them are in use).
- Adding a firewall rule to allow incoming requests as described in https://github.com/microsoft/WSL/issues/4585#issuecomment-610061194 (as well as restarting a couple times after adding the rule)
New-NetFirewallRule -DisplayName "WSL" -Direction Inbound -InterfaceAlias "vEthernet (WSL)" -Action Allow
- Adding options like `xdebug.remote_enable=1` to the config, but this is being done by PHPStorm anyways when it runs the remote php instance (`remote_connect_back` also did not do the trick):
[wsl://UBUNTU2004]:php -dxdebug.remote_enable=1 -dxdebug.remote_mode=req -dxdebug.remote_port=9006 -dxdebug.remote_host=172.18.48.1 /home/spaceemotion/code/xxxxxx/backend/vendor/phpunit/phpunit/phpunit [rest ommitted]
Any help would be much appreciated!
Please sign in to leave a comment.
I know that it may sound like overkill but have you tried to completely disable Windows Firewall on _all_ profiles just to totally isolate any possible firewall intervention?
I asked the same question on stack overflow and was able to fix it via the firewall settings (https://stackoverflow.com/a/63420260/1397894):
For some weird reason though I had quite a few phpstorm entries there, each one probably an older Jetbrains Toolbox installation (I guess they don't get cleaned up properly?). I fear I will have to do this every time there's a new PhpStorm coming out :/
Thanks for sharing the link to the SO question, Windows firewall could be tricky sometimes.
As for the different PhpStorm entries, this is a somewhat normal scenario as each version has a different installation path.
I had a similar issue, but for me the solution was very different, but maybe this will help someone searching for a solution like me (for hours).
My problem was that absolutely nothing was happening after I configured xdebug. It ownly showed up in phpinfo, but not even logs were generated. For my solution, also Docker Desktop plays a role:
xdebug.client_host=host.docker.internal
Because the docker integration will leave this host entry in the WSL2 which also works without docker even running there!
I know this was a completely different setup, but if anyone else is as desperate as I was, this may hopefully help :-)
Thanks for sharing what worked Nina.
Does the debugging work even when the internet is turned off? And also how does it work when VPN is turned on?
Hi Nikhil,
sad thing is, this was just a one-trick-pony and...
... and after it didn't work a second time, it now works again, but the funny thing is that I had to set BOTH remote_host and client_host to host.docker.internal and BOTH remote_port and client_port to 9000 to get it working!
That's somewhat confusing, because I always thought those had to be different.
@Nina
But they ARE the same thing.
remote_xxx is used by Xdebug v2 while Xdebug v3 uses client_xxx param name. BTW: v2-only param does nothing in v3.
Xdebug: Upgrading from Xdebug 2 to 3
Ah good to know! That's often also my problem: instead of actually reading more into the documentation, I just want to "get it running, NOW" and go through all the stackoverflow articles where you often find "mixed" configurations. From people who also are in my situation and just want to get it running ASAP. Also looking at the XDEBUG info in phpinfo, there was "_client" with port 9003 and "_remote" with port 9000 and if you don't really get deep into the topic, you might think something like (and yes, I admit this, fully ashamed) "one is for the one side, one is for the other side" or "one is if the debugging IDE is on the same machine, the other one is if the IDE is on an external (remote) machine". So you find all kinds of explanations why there should be two configurations for an IP and a port.
...finally many thanks for pointing this out! :-)
Had came across the deprecation of the property earlier. The names are certainly confusing Nina. Thanks for the sharing the link here Andriy Bazanov.
Had been using the settings as discussed here in this thread. However, when VPN is turned on, or, internet is disconnected the debugging no longer works. Hopefully using xdebug.client_host=host.docker.internal supports debugging in all the above scenarios.
Despite the popularity and wide adoption of WSL2, strangely, haven't come across a detailed article by @Jetbrains on how to set up debugging using WSL2.
Did any of you come across an article by PHPStorm that details the process of setting up debugging with WSL2?
Guys Im having the same problem. I am very new to phpstorm and I am battling how to setup xdebug.
I have spent whole day - more than 12 hours trying to figure out what is what.
This is my `xdebug.ini`:
It should run on port 9000.
I can ping the WSL machine from within the container:
But if I try to do the same from WSL machine to the docker container it does not work. I have also tried to turn off the firewall completely.
Docker container was instantiated using docker compose file:
I think the issue is mainly that i do not understand well:
Im not sure If I used the correct configuration choice?
Guys any ideas / tips / tricks would be more than welcome!
Thank you!
Andrej Rehak, given that you specify
xdebug.remote_host
, you don't needxdebug.remote_connect_back
to be enabled.In general, the configuration looks correct, so it makes sense to check what you have in
xdebug.log
after you initiate a debugging session.Why are you pinging the WSL machine, though? A better test would be pinging
host.docker.internal
, although it won't necessarily tell you the entire truth.A perfectly valid test would be checking the 9000 port availability on
host.docker.internal
from the container while enabling/disabling Listening for PHP Debug connections in PhpStorm.