35
votes

Xdebug: [Step Debug] n'a pas pu se connecter au client de débogage

Je voudrais essayer XDEBUG 3.0.0RC1 pour explorer ce qui a changé et les nouvelles fonctionnalités qui l'accompagnent. J'utilise également le dernier PHPStorm 2020.3 EAP qui prend en charge XDebug 3 sans configuration majeure nécessaire. Vous trouverez ci-dessous ma configuration phpstorm pour le débogueur:

 Entrez la description de l'image ici

Et voici la configuration que j'ai essayée pour xdebug3:

zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20170718/xdebug.so
xdebug.remote_autostart=0
xdebug.remote_enable=1
xdebug.remote_host=host.docker.internal
xdebug.remote_port=9000
  • Fedora 33
  • Docker version 19.03.13, construire 4484c46d9d
  • PHPSTORM 2020.3 EAP BUILD # PS-203.5784.36

Il est curieux (car apparemment host.docker.internal n'est "pas" pris en charge par la version docker que j'utilise et pourtant cela fonctionne) et bizarre en même temps que le La configuration suivante fonctionne avec XDebug 2, même avoir le débogueur à écouter les connexions entrantes tout le temps:

 Entrez la description de l'image ici

zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20170718/xdebug.so
xdebug.mode=debug
xdebug.start_with_request=yes
xdebug.client_host=host.docker.internal # here I tried several combinations like: "localhost", "127.0.0.1", "172.17.0.1"
xdebug.client_port=9001 # here I tried several ports 9003 included with no success


22 commentaires

Quel est votre système d'exploitation?


@Lazyone c'est Fedora 33 J'ai ajouté de telles informations à l'OP


host.docker.internal n'est pas pris en charge sur Linux - uniquement Windows et Mac - github.com/docker/for-inux/issues/264 . Il sera pris en charge depuis Docker v20 - github.com/docker/for -Linux / Issues / 264 # issuecomment-71425341‌ 4 . Si vous souhaitez utiliser ce nom d'hôte, vous auriez besoin de détecter dynamiquement l'adresse IP (le lien susmentionné a de nombreuses options sur la façon d'y parvenir).


Pour l'instant, je suggère de remplacer "host.docker.internal" par l'adresse IP de la machine où phpstorm est en cours d'exécution, qui est accessible à partir du conteneur Docker


Essayez xdebug.discover_client_host = true option xdebug 3 - peut fonctionner.


@Lazyone host.docker.internal a fonctionné pour moi avec xdebug 2 jusqu'à ce que j'aie décidé d'essayer à Xdebug 3, bizarre


@ReynierPM Vous pouvez avoir cette autre option en place (par exemple xdebug.remote_connect_back = 1 - xdebug 2 équivalent de XDebug's 3 xdebug.discover_client_host = true ). Utilisez une adresse IP explicite (Code Hard) .. ou détectez-le dynamiquement.


@LazyOne cela n'a pas fonctionné non plus :( xdebug: [Step Debug] n'a pas pu se connecter au client de débogage. Trouvé: 10.211.55.12:9001


@Reynierpm stackoverflow.com/questions/22944631/… - Exécutez ces recettes et confirmez quelle adresse IP de l'hôte est réellement dans votre conteneur en cours d'exécution. Essayez ensuite d'utiliser cette adresse IP dans php.ini.


@ReynierPM Une autre option: revenez temporairement à XDebug 2 (dans le même conteneur) et voyez quelle adresse IP utilise - la même / similaire (comme elle peut changer) ou complètement différente? Si le journal XDebug affiche uniquement le nom d'hôte - essayez de le résoudre à l'adresse IP (à l'intérieur du conteneur, bien sûr).


En ce moment, la mauvaise adresse IP est le principal suspect (en supposant que tout le reste est le même. Il est donc peu probable qu'il s'agisse d'un problème de pare-feu ou de pareil). P.S. Mais vous pouvez également vérifier si c'est un phpstorm qui écoute le port 9001 sur votre système d'exploitation hôte (en utilisant netstat ou similaire) tandis que l'icône "Handle du téléphone" dans PHPStorm est verte (IDE écoute les demandes XDebug entrantes) .


@Lazyone github.com/docker/for-inux/issues/264# émetteur-71425341‌ 4 est vraiment ancien et selon aujourd'hui host.docker.internal est pris en charge, ce problème est vraiment ancien, mais de toute façon j'ai toujours ce la poignée du téléphone vert. La désactivation, j'ai pu obtenir la pile et en exécuter mais je vois cette erreur maintenant dans docker journaux : [17-nov-2020 16:32:42 utc] xdebug: [étape Debug] ne pouvait pas se connecter au client de débogage. Essayé: 127.0.0.1:7777 (à partir de Remote_addr Http En-tête), 10.211.55.1:7777 (secours via xdebug.client_host / xdebug.client_port): - (


Le commentaire de 26 jours est vraiment vieux? Le commentaire indique "host.docker.internal est déjà pris en charge dans docker 20.10-beta1: " - Votre docker est v19 ... peut-être qu'ils ont déjà été recouverts - je ne sais pas. Quoi qu'il en soit - il indique que le port 7777 est utilisé. Est-ce le bon port?


Oui, ce port est correct, j'ai changé xdebug.client_port = 7777 à autre chose au cas où :(


XDebug 2 fonctionne-t-il? Le débogage local fonctionne-t-il (lors de l'exécution de PHP sur le système d'exploitation hôte et non à l'intérieur du conteneur)?


@Lazyone Je n'ai pas de php ni de xdebug en dehors du conteneur, donc je ne sais pas s'ils fonctionnent ou non: | Et oui xdebug 2 fonctionne. J'ajouterai quelques informations sur Xdebug 2 dans l'OP


Quelle IP host.docker.internal résout (à l'intérieur du conteneur)? Nous pouvons essayer TeamViewer Session? Je peux apercevoir quelque chose avec mes yeux dans le processus / vous regarder / ide paramètres.


Je suis ouvert pour essayer TeamViewer, écrivez-moi sur PM pour vous envoyer une photo de ma configuration pour cela


Laissez-nous Continuez cette discussion dans le chat .


Je viens de passer toute la nuit à y travailler. Il s'avère que UFW a été activé et il bloquait le port. UFW Autoriser 9003 Cire ceci, mais devrait probablement le verrouiller par IP / Device


@Farkie merci beaucoup, a eu le même problème, votre commentaire m'a sauvé. sudo ufw status verbose , sudo ufw désactiver pour vérifier qu'il bloquait le port UFW, et sudo ufw activer + sudo ufw autoriser 9003 Pour résoudre certainement le PB. Je ne savais même pas que j'avais installé UFW!


@Scandel bon travail je suis revenu pour répondre!


9 Réponses :


4
votes

Je vais commencer à dire grand merci à @lazyone qui a passé un peu de temps à m'aider sur celui-ci jusqu'à ce que nous le fassions. Voici à quoi ressemble la configuration pour moi actuellement et cela fonctionne bien:

xdebug.start_with_request=yes

Vous devez également mettre à jour le port xdebug au Fichier | Paramètres | Langues et frameworks | PHP | Serveurs pour refléter le nouveau mais permettent également à l'option d'écouter sur les connexions entrantes xdebug3. (Je crois qu'il est activé par défaut dans Phpstorm 2020.3)

Entrez la description de l'image ici

C'est la configuration d'un projet backend où aucun navigateur n'est Au milieu, je n'ai pas essayé, mais pour ceux-ci, vous pourriez avoir besoin:

zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20170718/xdebug.so
xdebug.mode=debug
xdebug.client_port=9005

et aussi fichier | Paramètres | Langues et frameworks | PHP | Serveurs bien configurés.

Remarque: nous avons constaté que l'hôte avait activé IPv6 et je l'ai désactivé et en plus, ajouté le paramètre suivant à l'IDE via Help> Modifier les options VM personnalisées : -djava.net. PreferIPv4Stack = true . Après avoir ajouté le paramètre IP4 à l'IDE, je n'ai pas essayé de réactiver IPv6 et de voir si Xdebug 3 fonctionne toujours


2 commentaires

Alors, quel était le problème? (en dehors du port différent)? Je veux dire qu'il a la même apparence qu'en question et plus tôt dans la journée, le suppression de l'hôte n'a pas fonctionné non plus iIRC


@Faizanakramdar Je suppose que le problème était en effet l'hôte. Tout ce que j'ai essayé aujourd'hui était de l'utiliser, mais la dernière tentative était sans elle et cela a fonctionné. Je pourrais retourner l'IPv6 et voir si cela causait également des problèmes.



43
votes

php 7,4
Docker
Phpstorm 2020.1
Xdebug 3.1.0

Installez xdebug dans votre conteneur docker à l'aide de dockerfile

[xdebug]
xdebug.mode = debug
xdebug.discover_client_host = 1

Configurer php.ini avec:

[xdebug]
xdebug.mode = debug
xdebug.start_with_request = yes
xdebug.discover_client_host = 1


2 commentaires

J'ai essayé cette configuration exacte, mais je n'obtiens toujours pas ne pas me connecter au client de débogage. Essayé: 172.19.0.1:9003 (à partir de Remote_addr Http En-tête)


Ajouter xdebug.discover_client_host = 1 et la double vérification de mes ports était la solution, merci!



0
votes

J'ai eu le même problème. Je l'ai toujours lors de la demande d'un navigateur, mais de la ligne de commande, comme dans votre cas, cela fonctionne maintenant. Ce qui me manquait, c'était une configuration de serveur avec un mappage de chemin. Une fois qu'il a configuré cela, ainsi que les paramètres que vous avez déjà, cela a fonctionné. Je suis sur Mac OS Big Sur, en utilisant Phpstorm 2020.3


0 commentaires

3
votes

php 7.3
Docker (pour mac)
Phpstorm 2021.1


Vous n'aurez peut-être pas besoin de l'installer via PECL (ce qui a pris beaucoup de temps à construire et n'a pas fonctionné pour moi).

Tout ce que j'ai fait, c'est l'ajout de PHP7 .3-xdebug à ma commande apt-get install et configurez correctement le mappage de port comme suit:

dans dockerfile add: Exécuter apt-get install -y php7.3-xdebug

dans docker-compose.yml J'ai mappé un extra_host (c'était la sauce secrète pour moi):

[xdebug]
xdebug.mode=debug
xdebug.client_host=host.docker.internal

;optionals: (uncomment if you need them)
;xdebug.start_with_request=yes
;xdebug.discover_client_host=1

dans php.ini:

services:
  web:
    extra_hosts:
      - "host.docker.internal:host-gateway"

Dans phpstorm, je viens de commencer à écouter le port 9003 et j'ai configuré le mappage du serveur à mes besoins.

Références:


3 commentaires

Je ne pense pas que le extra_hosts soit nécessaire ici. Ce mappage peut avoir été nécessaire à la fois (avec un hôte Linux). Pourquoi l'avez-vous ajouté? Quel est votre système d'exploitation hôte?


@Marcguyer J'utilise macOS.


Le host.docker.internal DNS est automatiquement défini sur macOS, donc pas besoin de cette ligne.



7
votes

J'ai créé une configuration très simple qui me permet d'utiliser xdebug avec n'importe quelle version PHP avec un effort minimal (v2: 5.6-7.1, v3: 7.2 +) . Tout ce que je dois faire est de configurer phpstorm et docker-compose.yml à trois endroits et je peux déboguer.

Configuration:

Gander / dev @ xdebug2.ini :

docker-compose exec dev74 bash -c 'XDEBUG_SESSION=1 XDEBUG_CONFIG=1 php index.php'

Gander / dev @ xdebug3.ini :

XDEBUG_SESSION=1 XDEBUG_CONFIG=1 php script.php


1 commentaires

Fichiers déplacés dans Repo: Correction



10
votes

Ce qui a fonctionné pour moi, c'est de changer start_with_request de oui à déclenchent .

Cela a fonctionné pour moi:

< pre> xxx

edit: Comme indiqué dans les commentaires, les Trigger / 9003 sont les paramètres par défaut. Si cette réponse fonctionne pour vous, cela signifie que quelque chose remplace les paramètres par défaut, et en utilisant explicitement Trigger / 9003 , vous forcez aux paramètres par défaut.


3 commentaires

Notez que xdebug.start_with_request est automatiquement défini sur déclencheur lorsque xdebug.mode = debug , il n'est donc pas nécessaire de définir. Le xdebug.client_port = 9003 est également la valeur par défaut pour XDebug 3, donc ce n'est pas nécessaire non plus. Refs: xdebug.org/docs/all_settings#start_with_request xdebug.org/docs/all_settings#client_port


Pourquoi ça marche?


@Khayleng Il semble que quelque chose ait remplacé les paramètres par défaut, et en définissant Trigger / 9003 , vous forcez les paramètres aux défaillances. Je viens de modifier ma réponse pour ajouter ces informations.



0
votes

Je voudrais signaler l'attention sur l'option de configuration suivante dans le fichier INI, car c'est ce qui a résolu le même problème pour moi.

xdebug.client_host=host.docker.internal

Dans la documentation de PhpStorm ici dit que xdebug.remote_host = host.docker .internal doit être configuré quelles coutures similaires, mais ne l'est pas.

Une légère différence est que j'utilise Intellij.


1 commentaires

Remote_host est pour XDebug 2, et client_host est pour XDebug 3.



-1
votes

J'ai eu le même problème (Ubuntu 20.4 - Docker 20.10 - xdebug 3)

Ma solution était:

  • xdebug.discover_client_host = 1
  • Désactiver le pare-feu sudo ufw désactiver

  • 1 commentaires

    La désactivation du pare-feu ne peut jamais être une solution



    0
    votes

    Si vous avez essayé toutes les réponses ci-dessus et que vous ne pouvez toujours pas vous connecter au serveur XDebug, essayez de désactiver votre pare-feu local ou d'ajouter la règle Autoriser pour votre port xdebug ( 9003 par défaut).

    L'interface du pare-feu Ubuntu est ufw et vous pouvez autoriser le port 9003 en émettant la commande suivante:

    sudo ufw Autoriser 9003

    Vérifiez les modifications avec:

    Sudo UFW Status


    0 commentaires