Combine Short-URL-Service with Existing CMS on Nginx

You want to prioritize the short URL service by checking its route first and, if no match is found, then proceeding to handle the request with the CMS as usual.

               +-----> Django Short URL Service -----> 301 Redirect
              |
Request ----> |                                  
              |                                  
              +-----> CMS (via Nginx) -----------> Content/404

You would need to modify the Nginx configuration by adding a new location block specifically for handling the paths that might match your short URLs. The Django application must be set up to serve on a specific endpoint or port, which can then be proxied by Nginx.

As Dmitry notes in the comments, a try_files directive in Nginx does not support specifying more than one named location as a fallback.
The last parameter of the try_files directive can indeed point to a named location or a URI, but only one such fallback is permitted.

You can instead try to first attempt to serve the request as a static file, or via the short URL service, and use a single named location as the final fallback, which will then decide whether to serve the content from the CMS or return a 404.
You would route the request internally within Nginx based on the presence or absence of the requested resource in the short URL service.

• A primary location block will check for static files or redirect to the short URL service directly.
• As the final fallback in try_files, decide if the request should be served by the CMS or if a 404 should be returned.

http {
    # Other HTTP settings

    upstream django_short_url {
        server localhost:8000; # Django short URL service
    }

    server {
        # Other server settings

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

        location @check_short_url {
            # Attempt to proxy the request to the Django short URL service.
            # Django should return a specific status code or header if the URL is not found,
            # which Nginx can then use to decide whether to continue to the CMS.
            proxy_pass http://django_short_url;
            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_set_header X-Forwarded-Proto $scheme;

            # If the Django app determines that the URL does not match a short URL,
            # it could return a custom header or specific status that Nginx checks
            # to then forward the request to @cms using error_page or another mechanism.
        }

        location @cms {
            rewrite ^/(.*)/$ /$1 permanent;
            rewrite ^(.*)$ /VirtualHostBase/$scheme/$host:$server_port/cms/VirtualHostRoot$1 break;
            proxy_pass http://example_cms;

            include /etc/nginx/cfg/proxy.conf;
            include /etc/nginx/cfg/security.conf;
            gzip_static on; # to serve pre-gzipped version
        }
    }
}

The @check_short_url location is a named location which attempts to proxy every request to the Django short URL service. Depending on your Django app’s behavior, if a short URL does not exist, the app should either redirect (for valid short URLs) or signal back to Nginx (e.g., via a custom header or specific status code) that the request should be passed to the CMS.
You might need to employ additional Nginx features like error_page directives within the @check_short_url location to internally redirect requests to @cms based on the response from the Django app.

The "Using NGINX and NGINX Plus as an Application Gateway with uWSGI and Django" guide focuses on Nginx’s ability to serve as an application gateway in front of a Django application running via uWSGI, which is not your case.