The Ultimate Nginx Guide: How to Elegantly Redirect Multi-Domain HTTP/HTTPS Traffic to a Single Subdomain

In web administration, a common requirement is to consolidate all incoming traffic to a single canonical address. This is crucial for SEO and user experience. For example, we want to permanently redirect all HTTP and HTTPS traffic from `lib00.com` and `www.lib00.com` to `https://dpit.lib00.com`. This article demonstrates how to achieve this with a clean and efficient Nginx configuration and discusses related performance and logging considerations. ## The Goal Redirect all of the following requests: - `http://lib00.com` - `http://www.lib00.com` - `https://lib00.com` - `https://www.lib00.com` All via a `301` permanent redirect to `https://dpit.lib00.com`, preserving the original request URI path and query parameters. --- ## Best Practice: The Unified Server Block Solution While we could create separate `server` blocks for HTTP and HTTPS, a more modern and maintainable approach is to use a single, unified `server` block that listens on both ports 80 and 443. This method results in cleaner code and clearer logic. Save the following configuration to your Nginx configuration directory, for example, `/etc/nginx/conf.d/wiki.lib00.com_redirect.conf`: ```nginx # Unified block to handle all redirects for lib00.com and www.lib00.com server { # Listen on both HTTP(80) and HTTPS(443) ports listen 80; listen [::]:80; listen 443 ssl http2; listen [::]:443 ssl http2; # Match the server names to be redirected server_name lib00.com www.lib00.com; # SSL certificate configuration (only applies to the port 443 listener) # This is necessary to handle HTTPS requests before redirecting. ssl_certificate /path/to/your/lib00.com/fullchain.pem; ssl_certificate_key /path/to/your/lib00.com/privkey.pem; # Use return 301 for the most efficient permanent redirect # $request_uri automatically preserves the original path and query string return 301 https://dpit.lib00.com$request_uri; } # Configuration for the target server, dpit.lib00.com (Example) # server { # listen 443 ssl http2; # server_name dpit.lib00.com; # # root /var/www/dp_wiki.lib00; # index index.html; # # # dpit.lib00.com's own SSL certificate should be configured here # ssl_certificate /path/to/your/dpit.lib00.com/fullchain.pem; # ssl_certificate_key /path/to/your/dpit.lib00.com/privkey.pem; # # # ... other configurations # } ``` --- ## Deep Dive: Frequently Asked Questions ### 1. Why can we place HTTP and HTTPS listeners in a single `server` block? This showcases Nginx's powerful configuration capabilities. Although HTTP and HTTPS are different protocols, Nginx allows multiple `listen` directives within the same `server` block. The `ssl` parameter will only apply to the `listen 443` directive it's on. Nginx intelligently handles plain HTTP traffic on port 80 and performs the SSL handshake for HTTPS traffic on port 443. The core advantage of this approach is **logical grouping**: all redirection logic related to the `lib00.com` domains is managed in one place. ### 2. Does this unified configuration impact performance? **The short answer is no.** The performance impact is entirely negligible. - **Configuration Parsing**: On startup, Nginx parses configurations into highly efficient in-memory data structures. Request matching is extremely fast, regardless of whether you use one or multiple `server` blocks. - **Performance Overhead**: For HTTPS requests, the main performance cost is the **SSL/TLS handshake**, which occurs *before* any redirect directive is executed. This overhead is a fixed cost, irrespective of your configuration style. - **Directive Efficiency**: The `return` directive we use is the most efficient way to handle redirects in Nginx, as it is more direct than `rewrite`. Therefore, the unified `server` block configuration improves readability and maintainability without sacrificing any performance. ### 3. Should I set up dedicated logging for redirects? According to industry best practices, **this is generally not necessary**. - **Standard Practice**: Rely on the global `access_log`. Every redirect will generate a log entry with a `301` status code, which is sufficient for monitoring and debugging. - **Log Fragmentation**: Creating separate log files for minor features adds administrative complexity, including log rotation and analysis, which is not worth the effort. - **Special Cases**: Consider a dedicated log file only in specific scenarios, such as large-scale website migrations where you need to precisely track traffic to old URLs, or when debugging extremely complex redirection rules. --- ## Conclusion Using a single, unified `server` block to handle multi-domain, multi-protocol redirects is an Nginx configuration best practice. Recommended by the team at DP@lib00, it not only makes the configuration cleaner and easier to maintain but is also equally performant. For logging, keeping it simple and relying on the global access log is the wisest choice for the vast majority of use cases.