I am trying to setup Xdebug with PhpStorm. When I try and validate my script, I get the following error:
Specified URL is not reachable, caused by: 'Request failed with status code 400'
The error used to display a 404 status code, but I applied the fix on this page: https://www.jetbrains.com/help/phpstorm/validating-the-configuration-of-the-debugging-engine.html#troubleshooting-validation-results
I haven't seen anything online for fixing a 400 status code.
I have the site setup on a local environment using nginx and an upstream using php-fpm.sock.
upstream site_backend {
server unix:/var/run/php/php7.4-fpm.sock;
}
And here is my xdebug.ini:
GNU nano 4.8 /etc/php/7.4/fpm/conf.d/20-xdebug.ini
zend_extension=xdebug.so
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.var_display_max_depth = -1
xdebug.var_display_max_children = -1
xdebug.var_display_max_data = -1
xdebug.idekey = "PHPSTORM"
The site works, only Xdebug isn't working. PhpStorm is not registering anything from Xdebug.
Not sure what else is needed, let me know if you need anything else.
UPDATE:
Xdebug is version 3.0.4.
In the nginx error log, I saw something that might be helpful:
2021/04/19 10:26:08 [error] 736434#736434: *72 access forbidden by rule, client: 127.0.0.1, server: mysite.localhost, request: "GET /_intellij_phpdebug_validator.php HTTP/1.1", host: "mysite.localhost"
UPDATE 2:
I made the changes at https://xdebug.org/docs/upgrade_guide, still isn't working. Here is the update xdebug.ini:
zend_extension=xdebug.so
xdebug.mode=debug
xdebug.session=PHPSTORM
xdebug.start_with_request=yes
Not sure if it's correct configuration. I also double checked to make sure PHPStorm is listening on port 9003, which it is. I also restarted php-fpm as well.
I got the same issue and I was able to resolve this buy just replacing the default URL assigned (http://127.0.0.1) with my virtual host URL in PHPStorm > Run > Web Server Debug Validation > URL to validation script.
OS: Ubuntu 20.04.3 LTS
PHP version: 7.4.3
XDebug version: 2.9.2
/etc/php/7.4/mods-available/xdebug.ini:
zend_extension=xdebug.so
xdebug.remote_autostart = 1
xdebug.remote_enable = 1
xdebug.remote_handler = dbgp
xdebug.remote_host = 127.0.0.1
xdebug.remote_log = /tmp/xdebug_remote.log
xdebug.remote_mode = req
xdebug.remote_port = 9000 #if you want to change the port you can change
xdebug.mode=debug
xdebug.start_with_request = yes
I got the same problem and I resolved this buy just
changing the value in the php.ini file of the xdebug.start_upon_error from the default "default" to "yes" due too https://www.jetbrains.com/help/phpstorm/configuring-xdebug.html#configuring-xdebug-docker
I got the same issue by using ddev ( = a docker wrapper).
The absolute path to my project is /var/www/html in ddev.
I had to write /var/www/html as the absolute path to my project in the phpstorm settings at php>servers.
Related
While testing in PhpStorm, I get the following error in the logs:
Xdebug: [Step Debug] Time-out connecting to debugging client, waited: 200 ms. Tried: localhost:9000 (fallback through xdebug.client_host/xdebug.client_port)
Here is my Xdebug config in php.ini:
[XDebug]
zend_extension = c:\localserver\php8.0.2\ext\php_xdebug-3.0.3-8.0-vs16-x86_64.dll
xdebug.client_host=localhost
xdebug.client_port=9000
xdebug.discover_client_host=1
xdebug.profiler_append=0
xdebug.mode=debug
xdebug.start_upon_error=yes
xdebug.output_dir="c:\localserver\php8.0.2\temp"
xdebug.profiler_output_name="cachegrind.out.%t-%s"
xdebug.remote_handler="dbgp"
xdebug.idekey="netbeans-xdebug"
Windows брандмауэр выключен.
This error disappears when I configure XDebug to port 80
But still, I want to properly configure XDebug, for this I need to open port 9000. Please tell me how to do this?
After reinstalling the project, everything worked by itself, but I still don't know what was the cause of the error. I believe that the reason was that I created the project before I installed PHPUnit globally and configured XDebug. Although of course I could be wrong.
Using MacOS Sierra, PhpStorm and Xdebug, web application configured on port 80 (not running from PhpStorm).
When browsing to localhost:80/index.php, PhpStorm won't stop on breakpoint, when accessing the external IP 192.168.1.2/index.php, PhpStorm hits the breakpoint.
I would like to use localhost for debugging instead of the external IP.
Is there a way to make PhpStorm to work with localhost?
P.S. Visual Studio Code works in both scenarios (therefore I believe Xdebug and PhpStorm are working good).
[xdebug]
zend_extension = /usr/local/Cellar/php56/5.6.29_5/lib/php/extensions/debug-non-zts-20131226/xdebug.so
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_port=9000
xdebug.remote_autostart=1
xdebug.remote_connect_back=1
xdebug.idekey=vagrant
xdebug.remote_host=0.0.0.0
Tried to set xdebug.remote_host to 127.0.0.1 and localhost, same behavior.
When debugging localhost:80, xdebug log show:
Log opened at 2017-01-03 14:06:36
I: Checking remote connect back address.
I: Checking header 'HTTP_X_FORWARDED_FOR'.
I: Checking header 'REMOTE_ADDR'.
I: Remote address found, connecting to ::1:9000.
W: Creating socket for '::1:9000', poll success, but error: Operation now in progress (19).
E: Could not connect to client. :-(
Log closed at 2017-01-03 14:06:36
When using VS Code, there is no error and xdebug shows instead I: Connected to client. :-)
Setting xdebug.remote_connect_back to 0 (the default value) solved the issue.
Xdebug documentation:
If enabled, the xdebug.remote_host setting is ignored and Xdebug will
try to connect to the client that made the HTTP request. It checks the
$_SERVER['HTTP_X_FORWARDED_FOR'] and $_SERVER['REMOTE_ADDR'] variables
to find out which IP address to use.
When Xdebug tried to connect to localhost, it used TCPv6, which PhpStorm doesn't support.
Changing remote_connect_backto 0 caused Xdebug to use the remote_host value, using TCPv4, which PhpStorm supports.
I've followed all the suggestions I've found, but I can't get PhpStorm working with PHP 7 and xDebug. I did have it working with PHP 5.6.
Xdebug is being loaded by PHP. I verified in the phpinfo() output. I've switched PhpStorm to use the PHP 7 version and it also lists the correct debugger as xdebug 2.4.0RC3
My xdebug settings are:
zend_extension = "/usr/local/opt/php70-xdebug/xdebug.so"
xdebug.remote_enable = 1
xdebug.remote_connect_back = 1
xdebug.remote_port = 9000
xdebug.remote_host = 127.0.0.1
xdebug.scream = 0
xdebug.cli_color = 1
xdebug.show_local_vars = 1
xdebug.idekey = PHPSTORM
I have the xdebug chrome extension installed, and it's correctly adding the Cookie:XDEBUG_SESSION=PHPSTORM;. I also enabled the debugging listener in PhpStorm.
Can anyone suggest what else I can do to try get my breakpoints to trigger?
So, in my case, I found that by moving the port from 9000 to 9001 fixed. I guess something else was already using the default port. Problem solved!
In case someone else lands here. For me the solution was that the path to the binary wasn't using "quotes".
[xdebug]
zend_extension = "C:\wamp\bin\php\php7.0.16\ext\php_xdebug-2.5.1-7.0-vc14-x86_64.dll"
OS: Ubuntu 12.04 64-bit
PHP version: 5.4.6-2~precise+1
When I test an https page I am writing through the built-in webserver (php5 -S localhost:8000), Firefox (16.0.1) says "Problem loading: The connection was interrupted", while the terminal tells me "::1:37026 Invalid request (Unsupported SSL request)".
phpinfo() tells me:
Registered Stream Socket Transports: tcp, udp, unix, udg, ssl, sslv3,
tls
[curl] SSL: Yes
SSL Version: OpenSSL/1.0.1
openssl:
OpenSSL support: enabled
OpenSSL Library Version OpenSSL 1.0.1 14 Mar 2012
OpenSSL Header Version OpenSSL 1.0.1 14 Mar 2012
Yes, http pages work just fine.
Any ideas?
See the manual section on the built-in webserver shim:
http://php.net/manual/en/features.commandline.webserver.php
It doesn't support SSL encryption. It's for plain HTTP requests. The openssl extension and function support is unrelated. It does not accept requests or send responses over the stream wrappers.
If you want SSL to run over it, try a stunnel wrapper:
php -S localhost:8000 &
stunnel3 -d 443 -r 8080
It's just for toying anyway.
It's been three years since the last update; here's how I got it working in 2021 on macOS (as an extension to mario's answer):
# Install stunnel
brew install stunnel
# Find the configuration directory
cd /usr/local/etc/stunnel
# Copy the sample conf file to actual conf file
cp stunnel.conf-sample stunnel.conf
# Edit conf
vim stunnel.conf
Modify stunnel.conf so it looks like this:
(all other options can be deleted)
; **************************************************************************
; * Global options *
; **************************************************************************
; Debugging stuff (may be useful for troubleshooting)
; Enable foreground = yes to make stunnel work with Homebrew services
foreground = yes
debug = info
output = /usr/local/var/log/stunnel.log
; **************************************************************************
; * Service definitions (remove all services for inetd mode) *
; **************************************************************************
; ***************************************** Example TLS server mode services
; TLS front-end to a web server
[https]
accept = 443
connect = 8000
cert = /usr/local/etc/stunnel/stunnel.pem
; "TIMEOUTclose = 0" is a workaround for a design flaw in Microsoft SChannel
; Microsoft implementations do not use TLS close-notify alert and thus they
; are vulnerable to truncation attacks
;TIMEOUTclose = 0
This accepts HTTPS / SSL at port 443 and connects to a local webserver running at port 8000, using stunnel's default bogus cert at /usr/local/etc/stunnel/stunnel.pem. Log level is info and log outputs are written to /usr/local/var/log/stunnel.log.
Start stunnel:
brew services start stunnel # Different for Linux
Start the webserver:
php -S localhost:8000
Now you can visit https://localhost:443 to visit your webserver: screenshot
There should be a cert error and you'll have to click through a browser warning but that gets you to the point where you can hit your localhost with HTTPS requests, for development.
I've been learning nginx and Laravel recently, and this error has came up many times. It's hard to diagnose because you need to align nginx with Laravel and also the SSL settings in your operating system at the same time (assuming you are making a self-signed cert).
If you are on Windows, it is even more difficult because you have to fight unix carriage returns when dealing with SSL certs. Sometimes you can go through the steps correctly, but you get ruined by cert validation issues. I find the trick is to make the certs in Ubuntu or Mac and email them to yourself, or use the linux subsystem.
In my case, I kept running into an issue where I declare HTTPS somewhere but php artisan serve only works on HTTP.
I just caused this Invalid request (Unsupported SSL request) error again after SSL was hooked up fine. It turned out to be that I was using Axios to make a POST request to https://. Changing it to POST http:// fixed it.
My recommendation to anyone would be to take a look at where and how HTTP/HTTPS is being used.
The textbook definition is probably something like php artisan serve only works over HTTP but requires underlying SSL layer.
Use Ngrok
Expose your server's port like so:
ngrok http <server port>
Browse with the ngrok's secure public address (the one with https).
Note: Though it works like a charm, it seems an overkill since it requires internet and would appreciate better recommendations.
I have a strange problem that recently popped on my Debian Squeeze server.
I've had Exim4 configured to use SMTP-AUTH with encryption setup and running on this box for a long time, but now it doesn't work.
At first I thought it was maybe my certificates expired, but that wasn't the case, they're good for several more years.
It appears that the server isn't listening on port 25 any longer.
If I try to telnet to port 25 it times out.
If I run netstat -tulpen on the server nothing is listening on port 25.
I'm using the splitconf for Exim4.
In conf.d/main I'm enabling MAIN_TLS_ENABLE=true
In conf.d/auth/30_exim4-config_examples I have the following
# Authenticate against local passwords using sasl2-bin
# Requires exim_uid to be a member of sasl group, see README.Debian.gz
plain_saslauthd_server:
driver = plaintext
public_name = PLAIN
server_condition = ${if saslauthd{{$auth2}{$auth3}}{1}{0}}
server_set_id = $auth2
server_prompts = :
.ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS
server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}
.endif
#
login_saslauthd_server:
driver = plaintext
public_name = LOGIN
server_prompts = "Username:: : Password::"
# don't send system passwords over unencrypted connections
server_condition = ${if saslauthd{{$auth1}{$auth2}}{1}{0}}
server_set_id = $auth1
.ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS
server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}
.endif
On the server if I run this command:
swaks -a -tls -q HELO -s localhost -au A_USER_NAME -ap '<>'
I get this ...
=== Trying localhost:25...
* Error connecting 0.0.0.0 to localhost:25:
* IO::Socket::INET: connect: Connection refused
Can someone point me to some more advanced debugging techniques?
OK. I figured it out.
Comcast blocks port 25. I don't know why this is coming up now, unless they've recently started blocking it.
I had to change a line in /etc/default/exim4
From this
SMTPLISTENEROPTIONS='-oX 25 -oP /var/run/exim4/exim.pid'
To this
SMTPLISTENEROPTIONS='-oX 465:25 -oP /var/run/exim4/exim.pid'
I also added this to /etc/exim4/conf.d/main/03_exim4-config_tlsoptions
tls_on_connect_ports=465
It's odd that this just popped up, unless a Debian package updated the /etc/default/exim4 file. It's confusing, but it's working. Hopefully this will be helpful to someone in the future.
Cheers.