时间戳

首页 > 解决方案 > 为什么 XDebug 在不同的网络上无法连接？

windows - 为什么 XDebug 在不同的网络上无法连接？

问题描述

我知道互联网上有很多关于这个主题的帖子，但我已经调试了两天多，我似乎没有进一步了解。

设置
我的工作笔记本电脑上有一个（相当旧的）Vagrant 盒子，它主要是由一位前大学的学生设置的。一切似乎仍然对我和我的同事有用，所以我们没有任何理由设置一个全新的。

Vagrant box 包含我们开发网站的 Centos 安装。

主机是 Windows 10。

问题
在办公室时，连接到物理网络（通过电缆），我可以毫无问题地使用 XDebug。我从我的 Firefox 浏览器插件启用 XDebug，并在 Centos 上启用 XDebug，然后连接到 Windows 上的 PHPStorm，这样我就可以逐步执行代码。

但是，在家时，在 WIFI 上（我没有电缆）XDebug 将无法正常工作。

Vagrant 机器上的 XDebug 日志当前状态如下：

I: Checking remote connect back address.
I: Checking header 'HTTP_X_FORWARDED_FOR'.
I: Checking header 'REMOTE_ADDR'.
I: Remote address found, connecting to 10.10.10.1:9000.
E: Time-out connecting to client. :-(

研究
在许多帖子中，我读到 Vagrant 主机地址应该类似于 10.0.2.2。在我们的案例中，就我的信息而言，它一直是 10.10.10.1。

我还从 Vagrant 框中读到，您应该使用 netstat 检查主机 IP。主机 IP 将是默认网关。

在家里（在WIFI上）我测试了这个，输出是：

netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.220.2   0.0.0.0         UG        0 0          0 ens32
10.10.10.0      0.0.0.0         255.255.255.0   U         0 0          0 ens33
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 ens33
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 ens34
192.168.56.0    0.0.0.0         255.255.255.0   U         0 0          0 ens34
192.168.220.0   0.0.0.0         255.255.255.0   U         0 0          0 ens32

这里默认网关是“192.168.220.2”。因此，我尝试通过手动将 XDebug 设置remote_host为 192.168.220.2 并禁用来为 xdebug 设置该 IPremote_connect_back

现在日志说：

I: Connecting to configured address/port: 192.168.220.2:9000.
W: Creating socket for '192.168.220.2:9000', poll success, but error: Operation now in progress (29).
E: Could not connect to client. :-(
Log closed at 2020-01-26 08:19:34

从其他帖子中，我了解到这实际上更糟，IP 地址是错误的，因为它应该是一个内部 IP 地址，如 10.10.10.1

编辑 1：我今天在办公室测试了这个，连接到物理网络。XDebug 按预期工作，但 netstat 的输出对于网关是相同的，所以这可能与它无关：

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.220.2   0.0.0.0         UG        0 0          0 ens32
10.10.10.0      0.0.0.0         255.255.255.0   U         0 0          0 ens33
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 ens33
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 ens34
172.24.1.0      0.0.0.0         255.255.255.0   U         0 0          0 ens34
192.168.220.0   0.0.0.0         255.255.255.0   U         0 0          0 ens32

编辑 2：在办公室时，我现在还在 WIFI 上测试了 XDebug（通过断开物理网络电缆），然后 XDebug 不再工作。所以问题似乎不是特定于我的家庭网络，而是物理网络VS WIFI。

PHPStorm 说我很好
PHPStorm 在设置中有这个 xdebug 验证屏幕。尝试通过绿色检查通过所有内容。显然验证不够验证？

有趣的是，
同时我还尝试将 Samba 共享从 Windows 挂载到我的 Vagrant 盒子中。我想尝试该设置，但就像 XDebug 一样，mount 命令无法访问主机。

编辑：我今天在办公室的物理网络上测试了这个，然后这也不起作用。所以我们现在可能会忘记这一点，因为这似乎是一个完全不同的问题。

编辑 27-01：我以为我解决了问题，但这仅在办公室使用 WIFI 时有效。在家里，它仍然不起作用。办公室的修复是摆弄 Centos 服务器中的 IP 路由。

编辑 29-01：
我仍然没有这个工作，但经过几次测试后，我认为我可以声明 VM 可以到达主机： -ping 10.10.10.1工作 -nmap -p 9000 10.10.10.1似乎告诉我它可以到达端口

除此之外，今天我发现当 PHPStorm 没有在端口 9000 上侦听时，XDebug 日志文件显示：
“为 '192.168.220.2:9000' 创建套接字，轮询成功，但错误：操作正在进行中（29）。” 但是当 PHPStorm 监听连接时，XDebug 日志显示：
“找到远程地址，连接到 10.10.10.1:9000”

当主机状态发生变化时，虚拟机端的错误消息会发生变化，这一事实让我相信连接正在通过。

这意味着——出于某种原因——PHPStorm 根本无法处理传入的连接。我能想到的唯一原因是 PHPStorm 可能无法与 VM 对话？这听起来合理吗？如果是这样，如何进一步调查？

标签： windowsvagrantvirtualboxxdebug

解决方案

以下短语似乎表明已建立连接。

W: Creating socket for '192.168.220.2:9000', poll success, but error: Operation now in progress (29).

您确定是PhpStorm在本地侦听端口 9000 吗？你的 Vagrant 盒子可以和它说话吗？

让我们找出第一个：在主机上的 shell 中（我想在这两种情况下都运行 Windows），运行：

C:\> netstat -a -b

并确保正在侦听端口的是PhpStorm进程。如果是其他东西，请将 PhpStorm 配置中的端口更改为其他内容（例如），并将相同的端口设置为. 在 PhpStorm 中关闭“侦听调试连接”，然后重新打开。90009003xdebug.remote_portphp.ini

其次，测试 Vagrant 盒子是否可以与该端口通信

推荐阅读