The nginx uwsgi_modifier1 is deprecated in uWSGI.

Your goal is to be able to host a wsgi app from anywhere without the app needing to be adjusted to account for where it’s being served from.

The current method for doing this in uWSGI is to map mountpoints for each URI app combination like so:

[uwsgi]
socket = 127.0.0.1:3031
; mount apps
mount = /app1=app1.py
mount = /app2=app2.py
; rewrite SCRIPT_NAME and PATH_INFO accordingly
manage-script-name = true

Hosting multiple apps in the same process (aka managing SCRIPT_NAME and PATH_INFO)

mount can take the place of module

For Django specifically,

; Before
module = django_app.wsgi:application
; After
mount = /django_app=django_app.wsgi:application
manage-script-name = true

Cleanest Method for Latest Nginx/uWSGI Versions

Since uwsgi_modifier1 30 is removed in the latest versions and I felt like the mount-point stuff was too hacky, I had to use a newer method to serve Django in a subdirectory:

uWSGI config:

[uwsgi]
socket =        /tmp/project.sock

# Requires PCRE support compiled into uWSGI
route-run =     fixpathinfo:

Nginx config:

location /project {
    include         /etc/nginx/uwsgi_params;
    uwsgi_pass      unix:/tmp/project.sock;
    uwsgi_param     SCRIPT_NAME /project; # Pass the URL prefix to uWSGI so the "fixpathinfo:" route-rule can strip it out
}

NOTE: fixpathinfo: requires PCRE support to be compiled into uWSGI.

So if things aren’t working, try installing libpcre and libpcre-dev, then recompile uwsgi with pip install -I --no-cache-dir uwsgi. uWSGI’s internal routing subsystem requires the PCRE library to be installed before uWSGI is compiled/installed. More information on uWSGI and PCRE.

First of all, remove uwsgi_modifier1 30;. Django will handle SCRIPT_NAME by itself and don’t need to have PATH_INFO rewritten by uWSGI. It can be harmful if SCRIPT_NAME isn’t removed from headers by uWSGI.

Secondly, remove uwsgi_param PATH_INFO "$1"; from nginx config. PATH_INFO is already defined in uwsgi_params file, and it should be $document_uri (as it is in uwsgi_params), not $1 if you’re passing SCRIPT_NAME to django.

After that tweaks, django should treat SCRIPT_NAME as URL prefix and will adjust url dispatcher and url reversing to that.

If the application is so simple that a simple “/prefix” can be added to one line in urls.py then I prefer this simple solution without anything more.

Otherwise the “/prefix” must be appended to the domain column in the record for your site in Sites table in Django admin. The domain should be then “example.com/project” with the second solution, because Django must know the domain and the prefix, especially for correct redirect. Naturally the prefix must be also stripped from URL of the request by webserver, as you do it now in nginx settings.

I usually split the verification of such deployments to two questions:

• Does report the web server (nginx) the expected shorter or longer URLs to Django?
• Does know Django its full base URL and does it use that in all web pages consistently?

I use both nginx log and Django logging enabled to see which of them is eventually miscofigured. (You didn’t wrote enough important information.)

An important case that should be tested is: Verify that web pages that require athentication are redirected to login page correctly back and forth, even if you try these URLs after logout.

More details can be found in the similar question.