Nginx и Apache не могут заставить файлы try_files работать с постоянными ссылками


1

Я работал над этим последние две недели, и по какой-то причине я не могу заставить файлы try_files nginx работать с моими постоянными ссылками на wordpress. Я надеюсь, что кто-то сможет сказать мне, где я иду не так, а также, надеюсь, сказать мне, если я сделал какие-либо серьезные ошибки с моими конфигурациями (я новичок nginx ... но учусь :)).

Вот мои файлы конфигурации

nginx.conf

user www-data;
worker_processes 4;
pid /var/run/nginx.pid;

events {
    worker_connections 768;
    # multi_accept on;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # Logging Settings
    ##

    # Defines the cache log format, cache log location
    # and the main access log location.
    log_format cache '***$time_local '
            '$upstream_cache_status '
            'Cache-Control: $upstream_http_cache_control '
            'Expires: $upstream_http_expires '
            '$host '
            '"$request" ($status) '
            '"$http_user_agent" '
            ;

    access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;

}

mydomain.com.conf

server {
    listen 123.456.78.901:80; # IP goes here.
    server_name www.mydomain.com mydomain.com;
    #root /var/www/mydomain.com/prod;
    index   index.php;

## mydomain.com -> www.mydomain.com (301 - Permanent)
    if ($host !~* ^(www|dev))
    {
            rewrite ^/(.*)$ $scheme://www.$host/$1 permanent;
    }

# Add trailing slash to */wp-admin requests.
    rewrite /wp-admin$ $scheme://$host$uri/ permanent;

# All media (including uploaded) is under wp-content/ so
    # instead of caching the response from apache, we're just
    # going to use nginx to serve directly from there.
    location ~* ^/(wp-content|wp-includes)/(.*)\.(jpg|png|gif|jpeg|css|js|m$
            root    /var/www/mydomain.com/prod;
    }

# Don't cache these pages.
    location ~* ^/(wp-admin|wp-login.php)
            {
        proxy_pass http://backend;
    }

location / {
    if ($http_cookie ~* "wordpress_logged_in_[^=]*=([^%]+)%7C") {
            set $do_not_cache 1;
    }
    proxy_cache_key "$scheme://$host$request_uri $do_not_cache";
    proxy_cache main;
    proxy_pass http://backend;
    proxy_cache_valid 30m; # 200, 301 and 302 will be cached.
    # Fallback to stale cache on certain errors.
    # 503 is deliberately missing, if we're down for maintenance
    # we want the page to display.
    #try_files $uri $uri/ /index.php?q=$uri$args;
    #try_files $uri =404;
    proxy_cache_use_stale error
            timeout
            invalid_header
            http_500
            http_502
            http_504
            http_404;
    }

# Cache purge URL - works in tandem with WP plugin.
#        location ~ /purge(/.*) {
#           proxy_cache_purge main "$scheme://$host$1";
#        }

# No access to .htaccess files.
    location ~ /\.ht {
            deny  all;
    }

} # End server

gzip.conf

    # Gzip Configuration.
    gzip on;
    gzip_disable msie6;
    gzip_static on;
    gzip_comp_level 4;
    gzip_proxied any;
    gzip_types text/plain
           text/css
           application/x-javascript
           text/xml
           application/xml
           application/xml+rss
           text/javascript;

proxy.conf

# Set proxy headers for the passthrough
    proxy_redirect     off;

    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-IP        $remote_addr;
    proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    proxy_max_temp_file_size 0;

    client_max_body_size       10m;
    client_body_buffer_size    128k;

    proxy_connect_timeout      90;
    proxy_send_timeout         90;
    proxy_read_timeout         90;

    proxy_buffer_size          4k;
    proxy_buffers              4 32k;
    proxy_busy_buffers_size    64k;
    proxy_temp_file_write_size 64k;
    add_header X-Cache-Status $upstream_cache_status;

backend.conf

upstream backend {
        # Defines backends.
        # Extracting here makes it easier to load balance
        # in the future. Needs to be specific IP as Plesk
        # doesn't have Apache listening on localhost.
        ip_hash;
        server 127.0.0.1:8001; # IP goes here.
}

cache.conf

# Proxy cache and temp configuration.
proxy_cache_path /var/www/nginx_cache levels=1:2
                 keys_zone=main:10m
                 max_size=1g inactive=30m;
proxy_temp_path /var/www/nginx_temp;

    proxy_cache_key "$scheme://$host$request_uri";
proxy_redirect off;

    # Cache different return codes for different lengths of time
# We cached normal pages for 10 minutes
proxy_cache_valid 200 302  10m;
proxy_cache_valid 404      1m;

Два закомментированных файла try_files в папке \ конфигурационных файлов mydomain - это те, которые я пробовал. Эту ошибку, которую я нашел в журнале ошибок, можно найти ниже.

 ...rewrite or internal redirection cycle while internally redirecting to "/index.php"

заранее спасибо

Ответы:


1

Это выглядит как ужасно сложная установка.

Моя первая мысль - посоветовать вам полностью избавиться от Apache; nginx + php-fpm вполне может обслуживать ваш блог WordPress, и большинство правил WordPress nginx, которые вы обнаружите, предполагают, что nginx будет использоваться в качестве исходного сервера, а не обратного прокси-сервера для Apache.

Теперь, с шоу ...

Вы не можете использовать try_filesв том же locationблоке, где вы передаете запрос в восходящем направлении. Это будет просто проигнорировано, так как все идет к прокси в любом случае. Если вы хотите сделать эту работу, я предлагаю использовать именованное местоположение. Как то так (с макушки головы):

root /var/www/whatever;

location @apache {
    # proxy directives here
}

location / {
    try_files $uri $uri/ @apache;
}

Идея здесь в том, что вы позволяете nginx обрабатывать вещи, которые nginx может обрабатывать в первую очередь, а затем передавать все остальное вверх по течению.

Конечно, добавьте любые дополнительные директивы, которые вам нужны, но идея состоит в том, чтобы начать с простого, убедиться, что основные вещи работают, и только затем добавлять вещи для перезаписи статических запросов страниц, файлов cookie и т. Д.


Сейчас есть успех, домашняя страница загружается и больше не генерирует ошибку 500, но переписанные страницы теперь дают ошибку 404.
Чероки

1

Как говорит Майкл Хэмптон, у вас там довольно сложная настройка, и, может быть, лучше будет не усложнять ситуацию и работать в первую очередь. Вот моя основная настройка WordPress для nginx (которая работает с довольно постоянными ссылками):

root /var/www/mydomain.com/prod;
index index.php;

location / {
    # This is cool because no PHP is called for static content
    # The key thing here is passing the $args to index.php
    try_files $uri $uri/ /index.php?$args;
}

location ~ \.php$ {
    # Zero-day exploit defense
    # http://forum.nginx.org/read.php?2,88845,page=3
    # Won't work properly (404 error) if the file is not stored on this
    #server, which is entirely possible with php-fpm/php-fcgi.
    # Comment the 'try_files' line out if you set up php-fpm/php-fcgi on
    #another machine.  And then cross your fingers that you won't get hacked.
    try_files $uri =404;

    # For caching advice, see Mark Jaquith's superb post here:
    # http://markjaquith.wordpress.com/2012/05/15/how-i-built-have-baby-need-stuff/

    # To do some super-fancy rate limiting for the backend PHP requests, 
    # declare the following limit_req_zone in the http {} block of your nginx.conf e.g.
    # limit_req_zone $binary_remote_addr zone=appserver:1m rate=2r/s;
    # Then uncomment the below limit_req_zone line
    ## Set the request zone to limit backend DoSsing
    # limit_req zone=appserver burst=6;

    include /etc/nginx/proxy.conf;
    proxy_pass http://backend;
}

Вот и все - красиво и просто. Вам больше не нужно выполнять ничего из вашей старой конфигурации: (try_files получит nginx, чтобы попытаться обработать его напрямую, затем попробует следующий параметр, затем следующий и т. Д.)

# # Add trailing slash to */wp-admin requests.
# rewrite /wp-admin$ $scheme://$host$uri/ permanent;

# # All media (including uploaded) is under wp-content/ so
# # instead of caching the response from apache, we're just
# # going to use nginx to serve directly from there.
# location ~* ^/(wp-content|wp-includes)/(.*)\.(jpg|png|gif|jpeg|css|js|m$
#         root    /var/www/mydomain.com/prod;
# }

# # Don't cache these pages.
# location ~* ^/(wp-admin|wp-login.php)
#         {
#     proxy_pass http://backend;
# }

Чтобы облегчить тестирование, откройте терминал, SSH на своем сервере и запустите tail -f /var/log/nginx/*.log(или там, где хранятся ваши журналы), затем следите за ошибками. Не забудьте перезагрузить или перезагрузить сервер после внесения изменений в конфигурацию!

Кроме того, в зависимости от того, какую версию nginx вы используете и на какой ОС (я полагаю, Debian или Ubuntu из вашего / var / www / path), вы можете запустить, /etc/init.d/nginx configtestчто проверит ваш конфигурационный файл и сообщит полезную информацию. сообщения об ошибках о любых ошибках - это сделает жизнь намного легче.

После того как все вышеперечисленное работает и протестировано, вот несколько интересных советов, таких как добавление истечения срока действия и кэширование заголовков к загруженным изображениям; Ограничения IP, ограничение скорости и дополнительное ведение журнала для доступа администратора и попыток входа в систему; и т.д.:

location ~ ^/wp-content/uploads/.+\.(jpe?g|gif|png|ico|bmp)$ {
    # set a expires to max as per http://developer.yahoo.com/performance/rules.html/#expires
    expires max;
    add_header Cache-Control public;
}

# Make sure you avoid the static cache when logging in or doing admin
location /wp-admin {    
    #  Restrict by IP for extra security (I'd also highly recommend the Login Lockdown plugin or the Duo Two-Factor Authentication plugin)
    #  allow 81.128.0.0/11; # BT Central Plus
    #  allow 86.128.0.0/10; # BT Central Plus
    #  deny all;
    access_log   /var/log/nginx/wp-admin.log;
    error_log   /var/log/nginx/wp-admin.error.log error;
    include /etc/nginx/proxy.conf;
    proxy_pass http://backend;
}

# Make sure you avoid the static cache when logging in or doing admin   
location = /wp-login.php { 
    #  Restrict by IP for extra security
    #  allow 81.128.0.0/11; # BT Central Plus
    #  allow 86.128.0.0/10; # BT Central Plus
    #  deny all; 
    # Declare the zone in the http {} block of your nginx.conf  e.g.
    #   limit_req_zone $binary_remote_addr zone=appserver:1m rate=2r/s;
    # Then uncomment the below line to limit hits to wp-login to 2 per second  (plus a burst of 2 using the leaky bucket model)
    # limit_req zone=appserver burst=2 nodelay;
    access_log  /var/log/nginx/login-attempts.log;
    include /etc/nginx/proxy.conf;
    proxy_pass http://backend;
}

0

Я работаю на многих сайтах WordPress, используя Nginx и PHP-FPM. Мне кажется, что эта конфигурация работает нормально для каждого сайта в каталоге conf.d ... (для безопасности удалены подробности).

server {
    listen       123.123.123.123:80;
    server_name  example.com;

    client_max_body_size 128m;

    root   /app/<user>/www;
    index  index.html index.htm index.php;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        fastcgi_pass   unix:/tmp/php-fpm.example.com.sock;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
}
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.