“竞争”nginxconfiguration文件

我有一台服务器使用nginx成功托pipe了一些域。 每个域都有一个单独的nginxconfiguration文件。

一个域，我们称之为example.com是默认的服务器

它有一个像这样的configuration文件：

# config file for example.com # #redirects all www to NON-www # server { listen 80; server_name www.example.com; return 301 $scheme://example.com$request_uri; } server { listen 80 default_server; server_name example.com; charset utf-8; root /blah/example.com/public/www; 

这很好 – 直到我为同一个域的文件夹和子域的各种“pipe理redirect”添加第二个configuration文件。

• nginx上游的错误回应
• nginx将子域redirect到父域
• 使用nginx-proxy容器（如前端服务器）访问同一主机上的多个容器时出现错误503
• 将nginx速率限制应用于某些IP地址，并对其他速率进行限制
• 设置侦听/和任何子path的位置

我这样做是因为这个域名相当古老，并且在为这些域名购买域名之前，在子目录中有一大堆应用程序和网站。 在一些用户有旧书签的机会，我们要确保那些仍然工作。

我想维护这些redirect到一个单独的nginxconfiguration文件中，以便于监督。

所以这里是第二个configuration文件（为了讨论目的而简化）：

 # config file for Administrative_Redirects.example.com #redirects Webmin and/or Panel request to proper port and https # server { listen 80; server_name webmin.example.com; return https://webmin.example.com:10000; } server { listen 80; server_name panel.example.com; return https://webmin.example.com:10000; } #------------------------------------------------------------------------ # #redirects all Webmail and related cPanel requests to XYZ account # server { listen 80; server_name webmail.example.com; return https://3rdPartyMail.com:port; } server { listen 80; server_name www.webmail.example.com; return https://3rdPartyMail.com:port; } server { listen 80; server_name cpanel.example.com; return https://AnotherDomain.com:port; } #------------------------------------------------------------------------ # #redirects subdirs to proper domains and/or subdomains # # ~*/(regex_case-INSensitive) server { listen 80; server_name example.com; # some_app location ~*/(some_folder) { return 301 $scheme://SomeOtherDomain.com; } # another_app location ~*/(another_folder) { return 301 $scheme://AnotherDomain.com; } # Some_Name location ~*/(some_name) { return 301 $scheme://some_name.example.com; } } # strip www subdomain server { listen 80; server_name www.example.com; # some_app location ~*/(some_folder) { return 301 $scheme://SomeOtherDomain.com; } # another_app location ~*/(another_folder) { return 301 $scheme://AnotherDomain.com; } # Some_Name location ~*/(some_name) { return 301 $scheme://some_name.example.com; } } # ----------- 

我的两个问题：

1. 如果“Administrative_Redirects.example.com”这个configuration文件处于活动状态，则其中的所有内容都可以正常parsing，但浏览到example.com或www.example.com会导致404错误。

2. 浏览到any_made-up_subdomain.example.com（即没有在“Administrative_Redirects.example.com”configuration文件中指定的任何内容）为文档根目录（即root /blah/example.com/public/www;）提供服务。 。 。 但应该可能导致404

该问题似乎来自“Administrative_Redirects.example.com”的configuration文件中的以下部分

 #------- server { listen 80; server_name example.com; #------- and #------- server { listen 80; server_name www.example.com; #------- 

这些似乎“抢先”default_serverconfiguration文件，该文件稍后在活动的nginx站点列表中进行字母sorting。

我怎样才能保持“Administrative_Redirects.example.com”践踏default_server nginxconfiguration文件？

有没有更好的方法来做到这一点，同时保持redirect在一个单独的文件？

例如，我可以将这些“pipe理redirect”包含在default_serverconfiguration文件中吗，这样我就不会有这么大的麻烦了吗？

提前感谢任何见解！

 ... server { listen 80 default_server; server_name example.com; charset utf-8; root /blah/example.com/public/www; # add this line include redirects.conf; } 

 # some_app location ~*/(some_folder) { return 301 $scheme://SomeOtherDomain.com; } # another_app location ~*/(another_folder) { return 301 $scheme://AnotherDomain.com; } # Some_Name location ~*/(some_name) { return 301 $scheme://some_name.example.com; }