Я знаю, что на inte * есть много постов на эту тему rnet, но я отлаживаю это уже два дня и, похоже, больше ничего не получаю.
Настройка
У меня (довольно старый) блок Vagrant на моем рабочем ноутбуке, который был настроен в основном бывшими коллегами. Кажется, все работает для меня и моих коллег, поэтому у нас не было никаких причин устанавливать совершенно новый.
В коробке Vagrant находится установка Centos, на которой мы разрабатываем веб-сайты.
Хост-машина Windows 10.
Проблема
Когда в офисе подключен к физической сети (по кабелю), я могу без проблем использовать XDebug , Я включаю XDebug из моего Firefox плагина для браузера и XDebug на Centos, затем подключаюсь к PHPStorm на Windows, так что я могу пошагово пройти через код.
Однако, когда я дома, на WIFI (у меня нет кабель) XDebug просто не будет работать.
Журнал XDebug на машине Vagrant в настоящее время сообщает следующее:
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 вы должны проверить IP-адрес хоста с помощью netstat. 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". Поэтому я попытался установить этот IP для xdebug, вручную установив для remote_host XDebug значение 192.168.220.2 и отключив remote_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
Edit 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
Edit 2: Находясь в офисе, Теперь я также протестировал XDebug в режиме WIFI (отключив физический сетевой кабель), а затем XDebug больше не работает. Таким образом, проблема, похоже, не в том, чтобы указывать c на мою домашнюю сеть, а скорее на то, чтобы быть в физической сети VS WIFI.
PHPStorm говорит, что я в порядке
PHPStorm имеет этот xdebug проверяет экран в настройках. Попытка пройти все с зелеными проверками. Очевидно, что валидация не подтверждает достаточно?
Интересно отметить
Одновременно я также пытался смонтировать общий ресурс Samba из Windows в мой блок Vagrant. Я хотел поэкспериментировать с этой настройкой, но так же, как XDebug, команда mount не может связаться с хост-машиной.
Редактировать: Я тестировал это сегодня, находясь в офисе в физической сети и тогда это тоже не работает. Таким образом, мы можем, вероятно, забыть об этом на данный момент, поскольку это, кажется, совершенно другая проблема.
Редактировать 27-01: Я думал, что я исправил проблему, но это работало только при использовании WIFI в офисе. Дома это все еще не работает. Исправление в офисе было связано с IP-маршрутами на сервере Centos.
Редактировать 29-01:
У меня все еще не работает, но я думаю, что после нескольких тестов Я могу утверждать, что виртуальная машина может достигать хоста: - 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 может быть не в состоянии общаться с виртуальной машиной ?? Это звучит правдоподобно? И если да, то как это дальше расследовать?