przekieruj subdomeny z symbolami wieloznacznymi do https (nginx)

Posiadam certyfikat SSL z symbolami wieloznacznymi i próbuję przekierować cały ruch inny niż ssl na ssl. Obecnie używam następujących do przekierowania nie-poddomenowego adresu URL, który działa poprawnie.

server {
listen      80;
server_name mydomain.com;

#Rewrite all nonssl requests to ssl.
rewrite     ^ https://$server_name$request_uri? permanent;
}

gdy robię to samo dla * .mydomain.com, logicznie przekierowuje do

https://%2A.mydomain.com/

Jak przekierować wszystkie subdomeny do ich odpowiedników https?

nginx https

— co co
źródło

Zamiast $ nazwa_serwera, dlaczego nie $ host?

— cjc

To wszystko...

server {
    listen      80;
    server_name *.mydomain.com;

     #Rewrite all nonssl requests to ssl.
     return 301 https://$host$request_uri;
}

— Cadmi
źródło

Trochę więcej wyjaśnień może sprawić, że będzie to lepsza odpowiedź.

— Dave M

@ dave-m, że trzeba to wyjaśnić? $hostzmienna? $request_uri?

— cadmi

Nie działa, wciąż ma https: //%2A.handy.travel/

— Damon Yuan

Oficjalna dokumentacja NGINX zachęca do korzystania z dyrektywy powrotowej zamiast z dyrektywy przepisywania w celu dokonania przekierowania. Dzieje się tak, ponieważ przepisywane żądanie nie jest przeznaczone dla tego serwera, ale nadal jest przetwarzane w tym bloku serwera. Dlatego przekierowania są poprawnie wykonywane za pomocą dyrektywy zwrotnej, ponieważ całe przetwarzanie jest zatrzymywane, a odpowiedź jest natychmiast wysyłana. NGINX odradza przepisywanie w celu przekierowania tutaj: http://nginx.org/en/docs/http/converting_rewrite_rules.html

Składnia dyrektywy return jest następująca: URL kodu powrotu; Ponieważ pierwotnie robiłeś trwałe przepisywanie, więc możesz użyć 301 jako kodu do odpowiedzi, wskazując, że jest to stałe przekierowanie. Twój adres https zostanie przekazany w sekcji url. Odniesienie: http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return

Więc twoja poprawna konfiguracja byłaby

server {
listen      80;
server_name *.mydomain.com;

#Redirect all nonssl requests to ssl.
return 301 https://$server_name$request_uri;
}

Prawdopodobnie pozwoliłoby to na prawidłowe przekierowanie do domeny ssl za pomocą bloku serwera ze znakiem wieloznacznym. Możesz także wypróbować podkreśloną ogólną nazwę serwera „_” lub $ host, jak sugerowano w powyższym komentarzu. Daj nam znać!

— Apurva Sukant
źródło

Chociaż użycie returnjest ogólnie lepsze, sugerowana konfiguracja jest nieprawidłowa, ponieważ nadal używa $ server_name do przekierowania, którym będzie „* .mydomain.com”. Poprawna poprawka została już opisana przez @cjc w powyższym komentarzu - $hostpowinna być używana zamiast $server_name.

— Maxim Dounin,

Tak zgodził się. Ach, wydaje mi się, że moja uwaga jest bardzo modna!

— Apurva Sukant

Zamiast powyższej szkód, pozwól, że dam ci wskazówkę dotyczącą konfiguracji ssl, która powinna znacznie poprawić wydajność. Najbardziej efektywnym sposobem skonfigurowania SSL, jeśli używasz certyfikatu wieloznacznego, jest ustawienie „zszywania ssl”. Pozwala to na jednorazowe skonfigurowanie SSL na domyślnym serwerze dla wszystkich subdomen i zapisuje osobne uwierzytelnianie ssl dla każdej subdomeny. ssl_stapling on; resolver 8.8.8.8; ssl_stapling_file /ssl_keys/example.com_staple; ssl_stapling_verify on; Refference- calomel.org/nginx.html

— Apurva Sukant

Powinien byćreturn 301 https://$host$request_uri;

— scarver2

Słucham portów 80, 8080 ORAZ 8181, return 301 https://$server_name$request_uri;aby zmusić je do używania protokołu https na porcie 443. Problem polega na tym, że przekierowany adres URL nadal ma oryginalny numer portu. 80 nie jest problemem, ale 8080 pojawia się jakohttps://example.com:8080

— A.Grandt

-1

Wypróbuj coś takiego:

server {
  listen 80;
  server_name ~^(.*)\.mydomain\.com$;
  set $servername $1;
  rewrite ^(.*)$ https://$servername.mydomain.com/$1;
}

Złap polega na zdefiniowaniu serwera wieloznacznego i dokonywaniu przekierowań na podstawie jego nazwy.

— Andriej Michałow
źródło

Zbyt liberalna grupa wyrażeń regularnych.

— Kzqai,