Nginx leitet zur URL ```https://server_name/ ``` statt ```https://server_name/projectname/``` weiter, nachdem die URL von http in https geändert wurde

Nginx leitet zur URL ```https://server_name/ ``` statt ```https://server_name/projectname/``` weiter, nachdem die URL von http in https geändert wurde

Ich habe ein paar URLs wie https://server_name/projectname/, jetzt besteht das Problem darin, dass Django (oder Nginx) mich zu weiterleitet, wenn ich diese URL in den Browser eingebe https://server_name/, was nicht existiert. Eigentlich sollte es mich zu weiterleiten https://server_name/projectname/. Jetzt ist die Frage, wie ich Django (oder Nginx) sagen kann, dies zu tun, ich weiß nicht wirklich, ob das Problem in der Django- oder in der Nginx-Konfiguration liegt. Ich habe FORCE_SCRIPT_NAME= '/projectname' in settings.py ausprobiert, aber es hat zum Beispiel nicht bei allen URLs geholfen https://server_name/projectname/admin. Übrigens hat es sehr gut funktioniert, bevor HTTP in HTTPs geändert wurde.

Nginx-Konfiguration in sites-available/project_name


upstream project_name_app{
  server unix:/home/webapps/project_name/run/gunicorn.sock fail_timeout=0;
}


server {

    listen 127.0.0.1:100;
    server_name servername;
    fastcgi_read_timeout 1600;

    proxy_connect_timeout       1600;
    proxy_send_timeout          1600;
    proxy_read_timeout          1600;
    send_timeout                1600;
    client_max_body_size 4G;

    access_log /home/webapps/projectname/logs/nginx-access.log;
    error_log /home/webapps/projectname/logs/nginx-error.log;

    location /static/ {
        alias   /home/webapps/projectname/project_name/static/;
    }

    location /media/ {
        alias   /home/webapps/projectname/project_name/media/;
    }

    location /{
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        if (!-f $request_filename) {
            proxy_pass http://project_name_app;
            break;

        }
    }

    # Error pages
    error_page 500 502 503 504 /500.html;
    location = /404.html {
        root /home/webapps/projectname/project_name/templates/;
    }
}

Nginx Reverse-Proxy-Konfiguration:

server {
        listen 80;
        server_name servername;

        # https redirect
        return 301 https://$host$request_uri;
}

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;

        ssl on;
        ssl_certificate ...;
        ssl_certificate_key ...;

        root /home/webapps/landing/landing;
        index index.html;

        # Improve HTTPS performance with session resumption
        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 10m;

        # Enable server-side protection against BEAST attacks
        ssl_protocols TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_ciphers "ddfdf";

        # RFC-7919 recommended: https://wiki.mozilla.org/Security/Server_Side_TLS#ffdhe4096
        ssl_dhparam /;
        ssl_ecdh_curve /;

        
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

        # ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
        # add_header X-Frame-Options DENY always;
        add_header X-Frame-Options SAMEORIGIN;

        # ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
        add_header X-Content-Type-Options nosniff always;

        # ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection
        add_header X-Xss-Protection "1; mode=block" always;

        # Reverse Proxy
        include /etc/nginx/sites-available/reverse-proxy.conf;
}




Und in der letzten Zeile ist ein Reverse-Proxy enthalten:


location /projectname/ {
        proxy_set_header X-Real-IP  $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $host;
        proxy_redirect off;
        proxy_set_header Accept-Encoding "";

        proxy_read_timeout 1000;
        proxy_connect_timeout 1000;
        proxy_send_timeout 1000;

        proxy_pass http://localhost:100/;
        sub_filter '="/' '="/projectname/';

        sub_filter_once off;
}


Haupt-URL in Django


urlpatterns = [
    path('', include('pages.urls')),
    path('dashboards/', include('dashboards.urls')),
    path('django_plotly_dash/', include('django_plotly_dash.urls')),
    re_path('admin/', admin.site.urls),
    
]

Seiten-URL

urlpatterns = [
    path('', views.index, name='index-pages'),
    re_path(r'^login/$', views.login_page, name='login'),
    re_path(r'^logout/$', views.logout_user, name='logout'),
]

Dashboard-URL

urlpatterns = [
    path('dashboard/', views.dashboard, name='dashboard'),
 ]

Antwort1

Django unterstützt SCRIPT_NAME problemlos. Egal, ob es in der Konfiguration erzwungen, vom WSGI-Server gesendet oder von einem Reverse-Proxy weitergeleitet wird, es funktioniert von selbst. Das Durchforsten von Reifen, nur um das Pfadpräfix vor einer Anwendung zu verbergen, ist nur bei der Arbeit mit Software erforderlich oder wünschenswert.nichtunterstützt die Verwurzelung in einem Unterordner.

Konfigurieren Sie MEDIA_URL& STATIC_URLund entfernen Sie die sub_filter/ sub_filter_once-Zeilen und den abschließenden Schrägstrich proxy_passaus Ihrer Nginx-Konfiguration. Das wirdsende den Pfadeinschließlichdas Präfixzu Gunicorn, und Django wird damit klarkommen.


Ich würde auch dringend empfehlen, den doppelten Proxy zu eliminieren. Die Konfiguration bezüglich der Anwendung könnte direkt in den location /projectname/ {}Namen im https-Serverblock integriert werden, anstattein andererpotenzielle Quelle für schwer zu diagnostizierende Eigenheiten/Fehler/Schwachstellen beim HTTP-Proxying.

verwandte Informationen