curl 在nginx 下报ssl connect error错，是什么原因_百度知道
curl 在nginx 下报ssl connect error错，是什么原因
服务器无返回内容，原因，您可以先在下面找找对应的号的错误提示，就是找到服务器商或者查看服务器，服务器无任何应答。如图那么对应的就找状态码为52的，找ISS看一下，该情况在此处被认为是一个错误。解决办法，服务器是否内容有返回设置如果在系统操作中 有提示 curl_error 错误号的
其他类似问题
为您推荐：
nginx的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁nginx和Tomcat集成后发生的重定向问题
前端nginx使用10443端口，Tomcat使用8080端口，具体配置如下
& & & listen
& & & access_log
& & &error_log
/var/log/nginx/error.
ssl_certificate /etc/nginx/ssl.
ssl_certificate_key /etc/nginx/ssl.
ssl_protocols &SSLv2 SSLv3 TLSv1;
ssl_ciphers & &
&ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
ssl_prefer_server_ciphers &
& & &location ~
^/(attached)/ {
& root /var/
& & & location /
& proxy_pass & &
& http://127.0.0.1:8080;
& proxy_set_header Host &
& proxy_set_header X-Real-IP
& proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_
​在这个配置下出现的问题就是当访问https://:10443/app/login.do的时候，登录成功需要跳转到中心页面，然后跳转的地址本应该是https://:10443/app/index.do，但是浏览器实际出现的地址http:///app/index.do。这里面的问题就是10443端口没了,https变成了http，跑80端口去了就404了。
－i&https://:10443/app/login.do发现的基本就是请求login.do是没问题的，但是login.do之后发生的301重定向是错误的，一个重要的线索就是Login.do的请求中response中的Location的值是/，这里丢掉了端口号​
分析下问题的原因：既然response的Locaiton不对，那么首先想到的就是这个Location是谁构造出来的，了解HTTP协议的人应该都知道，request中的header都是client（浏览器等）构造好发送给服务器的，服务器收到请求以后构造response信息返回给client。那么这样Location这个值肯定就是nginx或者Tomcat给搞出的问题了，这个地方nginx只是一个proxy
server，那么response肯定是Tomcat发给nginx的，也就是说我们应该从Tomcat下手来分析这个问题。
首先我就看了下Tomcat的官方文档&Proxy Support
，这里面对这个介绍如下：
The proxyName and proxyPort attributes can be
used when Tomcat is run behind a proxy server. These attributes
modify the values returned to web applications that call the
request.getServerName() and request.getServerPort() methods, which
are often used to construct absolute URLs for redirects. Without
configuring these attributes, the values returned would reflect the
server name and port on which the connection from the proxy server
was received, rather than the server name and port to whom the
client directed the original request.
意思就是proxyPort的属性就是用来我这种nginx做前端代理服务器Tomcat在后端处理动态请求的情况的。修改属性的值可以作用于应用的两个方法，主要用于绝对路径和重定向之用。如果不配置的话，可能会不对头。那么既然是这里不对头，我就先把server.xml中我这个http的connector的配置加入了proxyPort="10443"&scheme="https"&,重启Tomcat，然后把nginx上步骤的修改注释掉，重启测试完全正常跳转了。
下载了Tomcat的source来看了以后用通俗的语言来表述的话就是这样：如果默认不配置proxyPort默认为0，然后在构造response的时候判断如果proxyPort为0那么就不添加端口，不添加端口当然就默认走了80端口
String&proxyName&=&connector.getProxyName();
int&proxyPort&=&connector.getProxyPort();
if(proxyPort&!=0){&
&req.setServerPort(proxyPort);
if(proxyName&!=null){&
req.serverName().setString(proxyName);
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。限制 已用 剩余&php fpm安装curl后，nginx出现connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied)的错误
发布时间: 11:10:31
这里选择直接apt-get安装，因为比起自己编译简单多了，不需要自己配置什么
#sudo apt-get install curl libcurl3 libcurl3-dev php5-curl
安装后重启nginx
#nginx -s reload
岂知出现错误，php全部不能访问，查看错误日志如下：
23:59:46 [crit] 40455#0: *229072 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 171.9
处理方式是：编辑/etc/php5/fpm/pool.d/www.conf文件，将以下的注释去掉:
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
然后重启php5-fpm
sudo service php5-fpm restart
即可。参考文章：
After doing an upgrade on my Debian virtual server, which upgraded PHP and Nginx, I got a "502 Bad Gateway" error when browsing websites on that server. This post shows how to fix this problem, and the configuration option to prevent it occurring again on reboot.&
Edit /etc/php5/fpm/pool.d/www.conf and uncomment the following:
& & listen.owner = www-data
& & listen.group = www-data
& & listen.mode = 0660
& & sudo service php5-fpm restart
Longer answer
As well as the error in the browser, I was getting this error in the Nginx error log:&
[crit] 2686#0: *1 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.50.1, server: [...], request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "[...]"
The problem is caused by the permissions and ownership of the /var/run/php5-fpm.sock file, which after I'd done the upgrade change to something like root:root and 0660, so it couldn't be accessed by the www-data user which Nginx was running as.
The immediate solution is to change the permissions and/or ownership of the file like so:
chmod 0666 /var/run/php5-fpm.sock
chmod 0660 /var/run/php5-fpm.sock
chown www-data:www-data /var/run/php5-fpm.sock
The only catch is this won't persist after the server is restarted. To prevent the issue from occurring again, edit the&/etc/php5/fpm/pool.d/www.conf file:
sudo nano /etc/php5/fpm/pool.d/www.conf
Locate the following lines and uncomment them:
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
If you already changed the ownership/permissions of the socket file as shown above, then you don't need to do anything else now. If you didn't, then run this:&
sudo service php5-fpm restart
This re-creates the socket file with the ownership and permissions as configured in the file.
来源:/zl0372/p/nginx_140725.html