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:
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
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:
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
9 Réponses :
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)
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
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.
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
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!
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
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:
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.
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.
docker-compose exec dev74 bash -c 'XDEBUG_SESSION=1 XDEBUG_CONFIG=1 php index.php'
XDEBUG_SESSION=1 XDEBUG_CONFIG=1 php script.php
Fichiers déplacés dans Repo: Correction
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.
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.
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.
Remote_host
est pour XDebug 2, et client_host
est pour XDebug 3.
J'ai eu le même problème (Ubuntu 20.4 - Docker 20.10 - xdebug 3)
Ma solution était:
xdebug.discover_client_host = 1
sudo ufw désactiver
La désactivation du pare-feu ne peut jamais être une solution
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
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 avecxdebug 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 3xdebug.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 cela 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, etsudo 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!