标签: nginx

我正在考虑使用 mod_wsgi 部署 Nginx。但是我读了这篇博客：

http://blogg.ingspree.net/blog/2007/11/24/nginx-mod-wsgi-vs-fastcgi/

这里nginx的mod_wsgi的作者说，极少数的工作线程会被阻塞相当长的时间，等待你的脚本返回，这会降低服务器的速度。

这有多真实？我应该坚持使用 fastcgi 还是有更好的方法？

如何检查我的 nginx 服务器上的当前负载？

我在 nginx 后面运行 Magento（电子商务 PHP 应用程序）作为运行 PHP 应用程序的 Apache 的反向代理。静态内容由 nginx 直接提供。Magento 有一个“维护模式”，它使用 503 HTTP 响应。使用我的配置，当启用维护模式时，nginx 返回一个带有 500 响应的空白页面，而不是带有 503 响应的 Magento 良好的维护模式页面。如何让nginx让503页面传递给客户端？

这是我的 nginx 配置：

上游 examplecluster { 服务器 1.2.3.4:80; }
服务器 {
  听 1.2.3.5:80;
  server_name www.example.com;
  根/var/www/example.com/www；

  ＃ 安全
  位置 ~ (/(app/|includes/|lib/|pkginfo/|var/|report/config.xml|downloader/(pearlib|template|Maged)/)|/\.svn/|/\.ht.+ ){
    返回404；
  }

  位置 ~ \.php$ {
    proxy_pass http://examplecluster;
    proxy_redirect 默认；
  }

  # 静态内容
  地点 / {
    try_files $uri @apache;
    7d 到期；
  }

  #阿帕奇
  位置@apache {
    proxy_pass http://examplecluster;
    proxy_redirect 默认；
  }
}

我一直在努力让 PHP 通过 PHP-FPM 工作。我们的一台服务器被slowloris 攻击是apache 无法处理它。

我让 NGINX 运行正常并将数据传回 apache，但现在我试图至少对大多数东西使用纯 NGINX。我从源代码安装了 PHP-5.2.14 并用 PHP-FPM 修补了 5.14 并配置了 ff：

'./configure' '-enable-fastcgi' '--enable-fpm' '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib64' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--with-pear=/usr/share/pear' '--with-bz2' '--with-curl' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-expat-dir=/usr' '--with-zlib' '--with-zlib-dir=/usr/include' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--with-kerberos' '--enable-ucd-snmp-hack' '--with-unixODBC=shared,/usr' '--enable-memory-limit' …

我要进行的设置如下：我希望 nginx 在 /test 子目录中查找文件，如果不存在，则从正常的 uri 提供该文件。我认为使用 try_files 这会相当简单。这是我想出的设置：

server {
    listen       80;
    server_name  test-server;

    location / {
        root   /opt/www;
        index  index.php;
        try_files /test$uri $uri;
    }
}

这事半功倍。如果我访问http://test-server/something，并且有一个 /test/something 文件，它将提供 /test/something 文件。但是，如果没有 /test/something 文件，但有 /something 文件，则会返回 500 Internal Server 错误。我最好的猜测是存在某种递归循环，但我不知道替代方案是什么。

我刚刚安装了一个在后端运行 NGINX 的新 LAMP 服务器。虽然并非每次都会发生 - 某些 HTTPS 请求正在 URL 中寻找端口 7081。例如：

• http://www.nacdbenefits.com看起来不错
• 单击“联系我们”会重定向到 https 就好了
• 单击页面右下角的链接（我的管理）会显示端口 7081，一旦登录该页面就会导致错误。

这是 NGINX 的预期行为吗？我相信它几乎肯定与 NGINX 有关，因为禁用它（并且仅运行 apache）不会产生此错误。

NGINX 配置

#user  nginx;
worker_processes  1;

#error_log  /var/log/nginx/error.log;
#error_log  /var/log/nginx/error.log  notice;
#error_log  /var/log/nginx/error.log  info;

#pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;
    #tcp_nodelay …

upstream当代理服务器在同一端口上绑定多个主机名时，此功能不起作用。

http {
    upstream w {
        server test1:80;
        server test2:80;
        server localhost:7778;
    }

    server {
        listen       8001;
        server_name  localhost;

        location / {
            proxy_pass http://w;
        }
    }
}

http {
    upstream w {
        server test1:80;
        server test2:80;
        # server localhost:7778;
    }

    server {
        listen       8001;
        server_name  localhost;

        location / {
            proxy_pass http://w;
        }
    } …