xdebug 一直报错 upstream timed out (110: Connection timed out) while reading response header from upstream

本地主机(Windows环境192.168.66.1)访问虚拟机(192.168.66.139)里面的搭建的php环境(系统centos6.5版本,php版本是5.5.30 ,xdebug 2.4.0),通过命令行pecl install xdebug安装的xdebug,

在php.ini配置xdebug

[Xdebug]
zend_extension=/usr/local/php/lib/php/extensions/no-debug-non-zts-20121212/xdebug.so
xdebug.auto_trace = On
xdebug.idekey = phpstorm
xdebug.remote_connect_back = On
xdebug.auto_trace = On
xdebug.show_exception_trace = On
xdebug.remote_autostart = On
xdebug.remote_enable = On
xdebug.collect_vars = On
xdebug.collect_return = On
xdebug.collect_params = 1
xdebug.remote_handler=dbgp
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9001
xdebug.profiler_enable=On
xdebug.trace_output_dir = "/tmp/xdebug2222/"
xdebug.profiler_output_dir = "/tmp/xdebug/"
xdebug.remote_mode = req

反问页面index.php,页面一直卡死,查看nginx错误日志,发现一直有upstream timed out (110: Connection timed out) while reading response header from upstream

php-fpm一直报超时的错误,应该是php-fpm返回请求超过了设置的时间,但是一直不知道为什么会报错,脚本也没问题,

发现xdebug.remote_connect_back = On把这行注释掉之后,就没问题了,邪门啊。

官网地址:https://xdebug.org/docs/all_settings#remote_connect_back

官网给出的这个这个参数的解释是

xdebug.remote_connect_back
Type: boolean, Default value: 0, Introduced in Xdebug > 2.1
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[‘REMOTE_ADDR‘] variable to find out which IP address to use. Please note that there is no filter available, and anybody who can connect to the webserver will then be able to start a debugging session, even if their address does not match xdebug.remote_host.

大概意思是,设置了这个参数之后,xdebug返回数据时就不会只返回给xdebug.remote_host参数设置的IP了,任何ip请求都会返回数据,这样就可以多人共享这台服务器的php xdebug环境了。

不过还是没知道解决办法,不知道为什么。。

时间: 2024-11-05 02:17:42

xdebug 一直报错 upstream timed out (110: Connection timed out) while reading response header from upstream的相关文章

nginx error_log报错upstream timed out (110: Connection timed out)

最近迁移服务器,在网站搬到新服务器第一天就报504错误,服务器及ip都能ping通,查看错误日志,发现upstream timed out (110: Connection timed out)的错误,上网百度了下,原因应该是nginx配置问题 打开/etc/php5/php-fpm/pool.d/www.conf 将pm.max_children修改为40 request_terminate_time修改为900 再修改php.ini max_execution_time = 30,把它修改得

压测 502 日志报错 upstream timed out (110: Connection timed out)

环境介绍 服务器:centos6.5服务:nginx proxy 问题描述: 压测 开发同事 的开发环境项目没事,但是 线上机器 命中%50 ,大量502 php的某些页面打不开,页面提示gateway timeout,然后查找日志提示如下 2015/09/19 14:00:30 [error] 1811#0: *319 upstream timed out (110: Connection timed out) while reading response header from upstre

nginx 报错 upstream timed out (110: Connection timed out)解决方案

nginx 作PHP的web接口服务器. 在线上发现时不时经常崩溃.504,导致接口访问无响应回复. 查看日志: [error] 11618#0: *324911 upstream timed out (110: Connection timed out) while reading response header from upstream, client:然后百度看到都是修改nginx配置,解决超时问题. large_client_header_buffers 4 16k; client_m

Nginx Upstream timed out (110: Connection timed out)

在Nginx错误日志中,有大量的下列信息: Upstream timed out (110: Connection timed out) while reading response header from upstream 这种情况主要在厦门两种情况下发生: 1. nginx proxy 需要适当的调整proxy_read_timeout值. location / { ... proxy_read_timeout 150; ... } 1 2 3 4 5 location / { ... pr

FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream,

在对nginx添加fastCGI的支持后,然后进行php页面验证,发现页面识别不到,不清楚什么情况,随后google了下,原来是Nginx内置变量问题惹的祸. 1.平台介绍: 1 2 3 4 5 6 OS Version:        CentOS release 6.4 (Final) Nginx Version:     nginx version: nginx/1.4.3 PHP Version:       PHP 5.5.5 (fpm-fcgi) Mysql Version:    

nginx 错误502 upstream sent too big header while reading response header from upstream

查看nginx的错误日志,得到以下错误信息:upstream sent too big header while reading response header from upstream按字面意思理解应该是upstream负载均衡的模块转发的header头超出限制值了,查看配置文件中的相关配置,并搜索相关信息. 网上同类型的错误原因,说是cookie携带的header太多了,让你设置: fastcgi_buffer_size 128k;fastcgi_buffers 8 128k; 优化这些配

nginx error: upstream prematurely closed connection while reading response header from upstream

本篇文章由:http://xinpure.com/nginx-error-upstream-prematurely-closed-connection-while-reading-response-header-from-upstream/ 环境描述 Nginx 版本 1.10.2 PHP 版本 7.0.12 Node 版本 5.9.0 本文是想讲一个 Nginx 的错误,为啥还要提及 PHP 和 Node 的版本呢?容我先还原一下应用场景 首先就是我有一个绑定在 3000 端口的 Node S

recv() failed (104: Connection reset by peer) while reading response header from upstream

场景: 为了得到用户在线等信息,在客户端做了个ajax轮训: 于是问题就来了, 日志文件 [[email protected] web]# tail -f /data/log/nginx_error.log 2017/06/16 19:20:28 [error] 230555#0: *10228041 recv() failed (104: Connection reset by peer) while reading response header from upstream,client:

Nginx" upstream prematurely closed connection while reading response header from upstream"问题排查

问题背景 我们这边是一个基于Nginx的API网关(以下标记为A),最近两天有调用方反馈,偶尔会出现502错误,我们从Nginx的error日志里看,就会发现有" upstream prematurely closed connection while reading response header from upstream"这么一条错误日志,翻译过来其实就是上游服务过早的关闭了连接,意思很清楚,但是为什么会出现这种情况呢.而且是在业务低峰出现这种情况(也只是小概率的出现),在业务高