如何在内部网部署Django应用？服务器选择及部署方式咨询

Great question—this is a super common point of confusion when moving from Django development to production, especially for on-premise Unix servers. Let’s break down why you shouldn’t stick with the terminal-run dev server, and what you should do instead.

绝对不推荐继续使用终端运行Django开发服务器 #

Django’s built-in python manage.py runserver is exclusively for development and testing—it’s not designed to handle real user traffic. Here’s why it’s a bad choice for your on-premise deployment:

• Poor performance & concurrency: It’s single-threaded by default, so it can only handle one request at a time. Multiple users accessing your app will experience lag, timeouts, or crashes.
• Zero reliability: If you close the terminal, lose your SSH connection, or reboot the server, the dev server stops immediately—users lose access entirely.
• Security risks: Dev mode exposes detailed debug information (like full error stacks, database credentials in some cases) to anyone who accesses the app, which is a huge security hole for production use.
• Inefficient static file handling: The dev server serves static files (CSS, JS, images) in a very inefficient way, which will slow down your app for users.

推荐的本地Unix服务器部署方案 #

For a stable, performant, and secure on-premise deployment, the standard approach is combining a web server (like Nginx) with an application server (like Gunicorn or uWSGI), plus a process manager (like systemd) to keep your app running 24/7. Here’s a simplified step-by-step breakdown:

1. Set up an application server (Gunicorn example) #

The application server runs your Django app’s WSGI interface and handles concurrent requests far better than the dev server.

• Install Gunicorn (ideally in your virtual environment): pip install gunicorn
• Test it first: gunicorn --bind 0.0.0.0:8000 your_project_name.wsgi:application (replace your_project_name with your actual Django project name)

2. Use systemd to keep the app running automatically #

Systemd ensures your app starts on server boot and restarts if it crashes. Create a service file at /etc/systemd/system/django-app.service with this content:

[Unit]
Description=Django Production Application
After=network.target

[Service]
User=your_unix_username
Group=www-data
WorkingDirectory=/full/path/to/your/django/project
ExecStart=/path/to/your/virtualenv/bin/gunicorn --workers 3 --bind unix:/run/django-app.sock your_project_name.wsgi:application
Restart=always

[Install]
WantedBy=multi-user.target

Then run these commands to enable and start the service:

• sudo systemctl daemon-reload
• sudo systemctl start django-app.service
• sudo systemctl enable django-app.service

3. Configure Nginx as a reverse proxy #

Nginx handles static files, SSL (if you need it), and forwards user requests to Gunicorn. Create an Nginx config file at /etc/nginx/sites-available/django-app:

server {
    listen 80;
    server_name your_server_internal_ip; # Or your internal domain if you have one

    # Serve static files directly from Nginx (much faster)
    location /static/ {
        root /full/path/to/your/django/project;
        expires 30d; # Cache static files for 30 days
    }

    # Serve media files (user-uploaded content)
    location /media/ {
        root /full/path/to/your/django/project;
    }

    # Forward all other requests to Gunicorn
    location / {
        include proxy_params;
        proxy_pass http://unix:/run/django-app.sock;
    }
}

Enable the config and restart Nginx:

• sudo ln -s /etc/nginx/sites-available/django-app /etc/nginx/sites-enabled/
• sudo nginx -t (check for config errors)
• sudo systemctl restart nginx

Final Takeaway #

Sticking with the terminal-run dev server is only acceptable for quick, temporary testing with 1-2 users. For a production-ready on-premise deployment, the Nginx + Gunicorn + systemd setup is the industry standard—it’s reliable, secure, and can handle all your internal users without issues.

内容的提问来源于stack exchange，提问作者Shahabaz