Я пытаюсь настроить удаленную отладку Xdebug на сайт, сидящий за лаком, в качестве слоя кеширования с использованием PHPStorm.
Лак сидит в качестве интерфейса на порту 80, когда Apache разговаривает с ним как бэкэнд на порту 8080.
Если я обойду Ларнинг и поговорю непосредственно с сайтом на порту 8080, то Xdebug и Phpstorm работают должным образом, но тогда я не очень правильно тестирую систему – мне действительно нужно выполнить сеанс отладки, даже когда запрос проксируется через Лак.
Очевидно, я не ожидаю, что кешированный контент вызовет сеанс отладки, но нераскрытый контент все равно должен.
Мои настройки Xdebug следующие:
; xdebug xdebug.remote_enable = 1 xdebug.remote_connect_back = 1 xdebug.remote_port = 9000 xdebug.scream=0 xdebug.cli_color=1 xdebug.show_local_vars=1 У Xdebug есть поддержка, чтобы попытаться подключиться к IP-адресу, предоставленному в X_HTTP_FORWARDED_FOR, с версии 2.2.0 (исправлена ошибка в 2.2.2), см. Ошибки # 598 и # 660 . В зависимости от версии вашего лака вам может потребоваться добавить заголовок, или он может быть установлен для вас лаком.
Если вы установите заголовок, то ваша исходная конфигурация должна работать.
Добавить в vcl_recv :
if (req.http.x-forwarded-for) { set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip; } else { set req.http.X-Forwarded-For = client.ip; }
Как обычно, задавая вопрос, разоблачил ответ …
Похоже, что из-за окна IP-адрес запроса не сопоставляется через лак с php как $_SERVER[REMOTE_ADDR] , поэтому при включенном remote_connect_back Xdebug пытается подключиться обратно не к PHPStorm, а вместо этого для самого лака.
Изменение настроек xdebug для явного задания remote_host решило проблему следующим образом:
; xdebug xdebug.remote_enable = 1 xdebug.remote_connect_back = 0 xdebug.remote_host = 192.168.150.1 xdebug.remote_port = 9000 xdebug.scream=0 xdebug.cli_color=1 xdebug.show_local_vars=1
В этом случае он отлично подходит для меня, поскольку я всегда запрашиваю у 192.168.150.1 (это хост-машина для моих виртуальных машин)
Более общее решение, я думаю, переназначить поле REMOTE_ADDR на исходный IP-адрес, а не на IP-адрес Warnish.