[solved] How to setup xdebug and phpstorm

I don’t know anything about xdebug but I gather that you’re trying to connect from a container that’s running in Docker for Windows to an app that’s running and listening on a TCP port directly on the Windows 10 host?

That’s not really a supported scenario.

Having said that, there’s no reason it should not work. is probably the IP of your Windows host on the DockerNAT network (it is for me).

If I run a webserver on the Windows 10 host and make sure that it listens for external connections (listening on locahost will probably not cut it) and completely disable Windows Firewall, I can curl the webserver from a linux container running in Docker for Windows:

Hello from ASP.NET Core!

Note that this is not supported and that the networking setup may vary between machines and may change in the future.

Thanks a lot for your answer :slight_smile:

I gather that you’re trying to connect from a container that’s running in Docker for Windows to an app that’s running and listening on a TCP port directly on the Windows 10 host?

That’s it.

That’s not really a supported scenario.

Really ? Why not ?

Anyway, I’ve just tried to telnet Windows from another computer on my local network, and telnet 9000 (which is my Windows IP) connects successfully. So I guess the problem I have is somehow inherent to docker or DockerNAT. Once again, i guess my firewall is completely disabled (at least it’s shown as turned off).
Should I change any setting on this DockerNAT virtual network interface ? I can’t see any way to open any port…

I’ve also tried to change xdebug port to some random other number and it doesn’t change anything…

should i open a bug report or something ?

i think a docker container should really be able to connect to a listening service on windows.
xdebug is a major tool for web developers, who i guess are a big part of docker users. and i guess there are a bunch of other uses where this would be requested.

You can join the fray here: https://github.com/docker/docker/issues/1143


thanks Michael !

though this threads are about using a host name to access host from a container. in this case i don’t want to resolve any IP, i guess i know my host IP and i would not even need it with xdebug.remote_connect_back.
all of these people don’t seem to have any issue to access a service on the host machine, and i had no issue either when i was using docker-machine - i just had to open a port on virtualbox.

i haven’t understood this solution :
i use docker-compose and “docker run --net” option doesn’t seem to exist anyway…

i’ve updated to the latest build, 1.12.0-rc2-beta16 and still no luck.
i’ve also tried to use the option “Expose container ports on localhost” but port 9000 then appears busy if it is bound for the container, and is still not accessible from the container anyway.

ok i finally found this doc about networking : https://docs.docker.com/compose/networking/

and used option
network_mode: “host” in docker-compose

i can telnet 9000 ! i don’t know where this ip comes from (i found it with ifconfig) but it works when xdebug is listening, and not otherwise !

i will post more info soon.

so here is how i got it to work

docker-compose.yml :

version: '2'

        build: php5
            - "80:80"
        #    - db:db
        network_mode: "host"
        image: mysql
            - "3306:3306"
            - MYSQL_ROOT_PASSWORD=root

php.ini :


i selected “Expose container ports on localhost” as well in docker settings.
i can’t use links any more, because of the specified network_mode. so i’ve opened port 3306 and i have to choose as mysql host. i will probably find some workaround about this, but finally it works ! im glad ! thanks Michael for having pointed this --net option.

xdebug needs to connect back to your windows machine (PHPSTORM) on port 9000, so if networking in the container is working (should work if you have http and mysql up and running), you need to find out the windows IP on the docker-windows internal net and use this as xdebug.remote_host.

Or you use xdebug.remote_connect_back without specifying an IP at all - which works fine for me in conjunction with PHPStorm’s “Start Listening for PHP Debug connections”


are you sure you are using docker for windows beta ?
because i’ve been trying to make it work for weeks without success : i could not access port 9000 on windows from the container, even through i had all networking ok, apt-get and all. it was not working with any windows IP i could get, neither with xdebug.remote_connect_back…
until i tried network_mode: “host” for the container, and still, xdebug.remote_connect_back doesnt work i have to use xdebug.remote_host=

yes I am :-). Installed yesterday and imported data from my virtualbox instance.

1.12.0-rc2-beta16 with alpine linux on Hyper-V

this is part of my Dockerfile:
RUN echo “date.timezone= Europe/Paris” >> /etc/php5/fpm/php.ini
RUN touch /etc/php5/fpm/conf.d/40-custom.ini
RUN echo “zend_extension = xdebug.so” >> /etc/php5/fpm/conf.d/40-custom.ini
RUN echo “xdebug.remote_enable = 1” >> /etc/php5/fpm/conf.d/40-custom.ini
RUN echo “xdebug.remote_connect_back = 1” >> /etc/php5/fpm/conf.d/40-custom.ini
RUN echo “xdebug.max_nesting_level = 1000” >> /etc/php5/fpm/conf.d/40-custom.ini
RUN echo “xdebug.profiler_enable_trigger = 1” >> /etc/php5/fpm/conf.d/40-custom.ini
RUN echo “xdebug.profiler_output_dir = “/var/log”” >> /etc/php5/fpm/conf.d/40-custom.ini
RUN echo “memory_limit = 512M” >> /etc/php5/fpm/conf.d/40-custom.ini
RUN echo “upload_max_filesize = 512M” >> /etc/php5/fpm/conf.d/40-custom.ini
RUN echo “post_max_size = 512M” >> /etc/php5/fpm/conf.d/40-custom.ini


I know the pain!!!

Recently got a scaled-down version of Laradock working WITH full debugging!!! Checkout phpdock. The README outlines specific settings.

I decided to repo my docker-compose for two reasons. To share what it took for ME to get PHPStorm to play nice with Docker and to invite and refinements. It is called phpdock because at this point, I need to accommodate a variable number of php projects not necessarily Laravel all connecting to common services.

I am having some problems and you seem to be able to get the remote_connect_back option to work over the remote_host one. Can you help? https://gist.github.com/Toosick/4639f4e33ad52c692876a89df89e2b40

You don’t need 9000:9000 in docker, as it’s the container that will try to access your host - phpstorm acts as the server. Here your firewall might of course drop in, as some external process (the docker container) tries to contact your machine on port 9000.
You only need the following to get XDebug running:

RUN echo “zend_extension = xdebug.so” >> /etc/php5/fpm/conf.d/40-custom.ini
RUN echo “xdebug.remote_enable = 1” >> /etc/php5/fpm/conf.d/40-custom.ini
RUN echo “xdebug.remote_connect_back = 1” >> /etc/php5/fpm/conf.d/40-custom.ini

an of course you need to start XDebug by adding the XDebug Session Cookie manually, or with the Xdebug Helper Chrome extension.


I have fixed my problem since but it’s not ideal like people have said. I am setting remote connect back to 0 and remote host to my host local ip. If I do the same and instead use the gateway IP that the containers have it doesn’t work. That would be ideal as that is what the containers get when you use remote connect back. You think a firewall might be stopping the connection on IP

1 Like

you need to find out the windows IP on the docker-windows internal net

Can you please explain how to do that?

if you look at your logfile (Webserver log) you will see the IP, your requests come from. This should be the right one.


hello, all! I can confirm that using the xdebug.remote_host={{ host ip address }} works for xdebug. after a few hours tryng every possible combination this is what started working :slight_smile:

For what it’s worth, here’s how I finally got my setup working with Docker for Windows (Hyper-V):

  • In a Windows command-line, run “ipconfig” and look for the IP4 address in “DockerNAT” entry. in my case
  • Set “xdebug.remote_host=” in xdebug.ini file
  • Do NOT set “xdebug.remote_connect_back” (or you could explicitly set “xdebug.remote_connect_back=0”)

That last step is what drove me crazy for a few days. I had remote_connect_back=1 set from a previous build. I thought that setting “remote_host=xxxxx” would override connect_back, so I didn’t think to turn it off. It even worked for the Docker Toolbox version.

1 Like


That worked for me as well on Docker 1.13.

I had the ip:


Here are some more general instructions regardless of Docker (Linux, Windows, Mac, Toolbox):