基于Django与Apache部署多站点问题：无法同时运行两个站点

Let’s walk through what’s going on here and get these issues sorted out—this is a common gotcha with shared project names and mod_wsgi!

First: Why Did Both Sites Crash When Running Together? #

Your two sites share the same Django project name, which creates a module name collision risk. Even with daemon processes, if you have global WSGIPythonPath or WSGIPythonHome settings (like you did initially), both daemon groups inherit those paths. That means Python might try to load the wrong project’s modules when switching between sites, leading to crashes.

Fixing the "Both Domains Point to Site 2" Issue #

This is almost always a VirtualHost matching problem or insufficient isolation between your daemon processes. Let’s tackle it step by step:

1. Validate Apache’s VirtualHost Mapping
   Apache uses ServerName to match requests to the right VirtualHost. If no exact match is found, it falls back to the first VirtualHost it loaded. Run this command to see how Apache is mapping your sites:

   apachectl -S
   

   You’ll get output like this:

   *:80                   is a NameVirtualHost
     default server site2.co.uk (/etc/httpd/conf.d/site2.conf:1)
     port 80 namevhost site2.co.uk (/etc/httpd/conf.d/site2.conf:1)
     port 80 namevhost site1.co.uk (/etc/httpd/conf.d/site1.conf:1)
   

   If Site 2 is listed as the default, and Site 1’s requests aren’t hitting its ServerName (maybe a typo in the config?), Apache will serve Site 2’s content instead. Double-check the ServerName and ServerAlias lines in both configs for typos.

2. Isolate Daemon Processes Completely
   Your original config had global WSGIPythonHome/WSGIPythonPath settings that were shared between sites. Instead, define all isolation settings per VirtualHost so each site uses its own venv and project path without overlap. Here’s a cleaned-up config template for each site:

   Site 1 Config:

   <VirtualHost *:80>
       ServerName site1.co.uk
       ServerAlias www.site1.co.uk
   
       # Unique daemon process with isolated venv and project path
       WSGIDaemonProcess site1.co.uk python-home=/var/www/vhosts/site1.co.uk/venv python-path=/var/www/vhosts/site1.co.uk/website/{djangoProject}
       WSGIProcessGroup site1.co.uk
       WSGIScriptAlias / /var/www/vhosts/site1.co.uk/website/{djangoProject}/{djangoProject}/wsgi.py
   
       # Restrict access to the WSGI script
       <Directory /var/www/vhosts/site1.co.uk/website/{djangoProject}/{djangoProject}>
           <Files wsgi.py>
               Require all granted
           </Files>
       </Directory>
   
       # Logging
       CustomLog /var/log/httpd/site1.co.uk-access.log combined
       ErrorLog /var/log/httpd/site1.co.uk-error.log
       LogLevel warn
   </VirtualHost>
   

   Site 2 Config:

   <VirtualHost *:80>
       ServerName site2.co.uk
       ServerAlias www.site2.co.uk
   
       WSGIDaemonProcess site2.co.uk python-home=/var/www/vhosts/site2.co.uk/venv python-path=/var/www/vhosts/site2.co.uk/website/{djangoProject}
       WSGIProcessGroup site2.co.uk
       WSGIScriptAlias / /var/www/vhosts/site2.co.uk/website/{djangoProject}/{djangoProject}/wsgi.py
   
       <Directory /var/www/vhosts/site2.co.uk/website/{djangoProject}/{djangoProject}>
           <Files wsgi.py>
               Require all granted
           </Files>
       </Directory>
   
       CustomLog /var/log/httpd/site2.co.uk-access.log combined
       ErrorLog /var/log/httpd/site2.co.uk-error.log
       LogLevel warn
   </VirtualHost>
   

   Key fixes here:

   • Moved WSGIDaemonProcess inside each VirtualHost (ensures unique, isolated groups)
   • Removed global WSGIPythonHome/WSGIPythonPath—the daemon process parameters handle this now, so no shared paths
   • Each site has its own clear ServerName/ServerAlias to avoid matching confusion

3. Double-Check WSGI Script Paths
   It’s easy to copy-paste configs and mix up site paths. Verify that the WSGIScriptAlias line for each site points to the correct wsgi.py file (site1’s path should reference site1.co.uk, not site2.co.uk).

4. Clear Python Module Caches
   Python caches imported modules in __pycache__ directories, which can cause cross-site contamination. Delete these caches and do a full Apache restart (not just a reload):

   # Clear Site 1 caches
   find /var/www/vhosts/site1.co.uk/website/{djangoProject} -name "__pycache__" -exec rm -rf {} \;
   # Clear Site 2 caches
   find /var/www/vhosts/site2.co.uk/website/{djangoProject} -name "__pycache__" -exec rm -rf {} \;
   # Restart Apache
   systemctl restart httpd
   

Quick Permissions Check #

Even though you fixed the log issue, avoid using 777 permissions (it’s a security risk). Instead, set proper ownership for the Apache user (usually apache or www-data):

chown -R apache:apache /var/www/vhosts/site1.co.uk/
chown -R apache:apache /var/www/vhosts/site2.co.uk/
chmod -R 755 /var/www/vhosts/site1.co.uk/
chmod -R 755 /var/www/vhosts/site2.co.uk/

Final Debug Step #

Tail both error logs while accessing each site to catch any remaining issues:

tail -f /var/log/httpd/site1.co.uk-error.log /var/log/httpd/site2.co.uk-error.log

This will show you if there are still module loading errors or path issues.

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