Я разрабатываю приложение Django с обратным прокси-сервером nginx и сервером приложений Gunicorn. Поскольку я начинающий веб-разработчик, мне нужна помощь с перенаправлением www трафик в no www на уровне веб-сервера. В настоящее время я делаю то же самое на уровне промежуточного программного обеспечения внутри приложения, но мне нужно повысить производительность.
В настоящее время мой файл виртуального хоста nginx выглядит следующим образом:
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=100m inactive=6m;
upstream my_server {
server unix:/home/myuser/myproject/myfolder/myproject.sock fail_timeout=0;
}
server {
listen 80;
server_name example.com www.example.com;
# a bunch of 'location' blocks e.g. 'location /' or 'location @http_proxy_to_app', etc.
}
server {
listen 443 ssl;
server_name example.com www.example.com;
# SSL related stuff
# a bunch of 'location' blocks e.g. 'location /' or 'location @http_proxy_to_app', etc.
}
Как бы мне перенаправить www в no-www в этом сценарии? Большинство примеров, которые я видел, объясняют, что мне нужно добавить еще один специальный server блок наверху вот так:
server {
server_name www.example.com;
return 301 $scheme://example.com$request_uri;
}
Другие предложения состояли в том, чтобы включить что-то вроде следующего в мои серверные блоки (внутри location /). Я не уверен, будет ли это совместимо с кодом, связанным с обратным прокси:
if ($host ~* ^www\.(.*)$) {
rewrite / $scheme://$1 permanent;
}
Будучи новичком, я хотел подтвердить, какую практику использовать (и почему), учитывая то, как сейчас оформлен мой файл nginx, отсюда и этот вопрос.
Вот как выглядит моя настоящая конфигурация:
server {
server_name example.com;
listen 443 ssl;
#ssl_certificate /etc/ssl/certs/ssl-bundle.crt;
ssl_certificate /etc/nginx/ssl/cert_chain.crt;
#ssl_certificate_key /etc/ssl/myserver.key;
ssl_certificate_key /etc/nginx/ssl/server.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
#ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
#ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;
ssl_session_cache shared:SSL:1250m;
ssl_session_timeout 180m;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_stapling on;
ssl_stapling_verify on;
#ssl_trusted_certificate /etc/ssl/COMODO_DV_SHA-2_under_SHA-2root.crt;
ssl_trusted_certificate /etc/nginx/ssl/example_com.ca-bundle;
# write error log file for https errors:
error_log /var/log/nginx/https-error_log warn;
location ~* \.(?:ico|css|js|gif|jpe?g|png)$ { root /home/myuser/myproj/myapp; expires 24h; add_header Vary Accept-Encoding; access_log off; }
.... more config to follow ...
}
Предпочтительная установка для обработки веб-сервера http://example.com, https://example.com, http://www.example.com и https://www.example.com следующее, когда example.com домен и https предпочтительны:
server {
server_name example.com www.example.com;
listen 80;
return 301 https://example.com$request_uri;
}
server {
server_name www.example.com;
listen 443 ssl;
return 301 https://example.com$request_uri;
}
server {
server_name example.com;
listen 443 ssl;
... actual server configuration ...
}
В этой настройке есть только один фактический URL https://example.com для доступа к содержанию сайта, что хорошо для индексации. В вашей текущей настройке один и тот же контент сайта доступен со всеми URL-адресами, что вызывает повторяющиеся проблемы с Google.
Определение отдельного виртуального хоста для перенаправления является предпочтительным способом, потому что оценка if Оператор вызывает дублирование работы для запросов, уже поступающих в правильный блок виртуального хоста.