I know this is an old post, but it seemed like the one I ran into tonight.
Configuring NAT Network is the way to get the least amount of conflict. In the Windows 7 firewall, configure a custom inbound traffic rule to allow inbound traffic to port 9000 for the entire / 24 network that hosts the virtual machine (192.168.202 / 24).
My working XDebug setup in php.ini using 2.2.7 with Netbeans 8.0.2 :
zend_extension=xdebug.so xdebug.remote_enable=1 xdebug.remote_connect_back=1 xdebug.remote_port=9000 xdebug.idekey="netbeans-xdebug" xdebug.show_local_vars=0 ;xdebug.extended_info=1 xdebug.output_buffering=off xdebug.remote_log=/var/log/xdebug.log
Finally, I want to indicate that Netbeans is listening for the remote address setting in the remote file configuration . Running a quick netstat -an showed that Netbeans was listening on port 9000 with the status CLOSE_WAIT at the old address from my initial network setup. Even after changing the project URL and the IP address of the remote connection and closing multiple xdebug connections, this never changed. Only after Netbeans closes does a legacy connection reset. After starting Netbeans, the new remote server URL is used to remotely connect xdebug.
Mentioning Netbeans containing an outdated state has never been discussed, and the ability to stop the xdebug connection from the IDE gives a false sense of socket reset.
If it still does not work, use the provided debugclient in the virtual machine, go to the project page with "? XDEBUG_SESSION_START = netbeans-xdebug" added to the index.php URL and look at the xdebug information to enter. At least you know that it works locally.
Dbrown
source share