Nginx 烧瓶+；ngix&x2B；uwsgi未从路由Ubuntu20剥离脚本根

我希望有人能帮助我

我试图将一组flask应用程序从Ubuntu18机器重新部署到Ubuntu20机器上，但它们的行为与以前的部署不同

他们已经成功地部署在Ubuntu14、16和18上，包括在Ubuntu18部署时从Python2到3的转换，但最新的部署在Ubuntu20上让我完全难堪

它们使用下面描述的配置运行（在Ubuntu 18上成功运行）。在新的Ubuntu20机器上部署时，flask将路由视为脚本根（以及脚本根），这将导致404

目前在U18上工作的设置如下（nginx简化为在非TLS连接上测试）

运行在：9999上的应用程序不在自己的位置，并且工作正常

NGINX:

server {
 underscores_in_headers on;
 listen 80 default_server;
 server_name _;

 location /.well-known {
  root /var/www/html/;
 }

 location / {
  include uwsgi_params;
  uwsgi_pass 127.0.0.1:9999;
 }
 
 location /a {
  uwsgi_param SCRIPT_NAME /a;
  uwsgi_modifier1 30;
  include uwsgi_params;
  uwsgi_pass 127.0.0.1:10017;
 }
}

UWSGI：

    [uwsgi]
    socket = :10017
    plugin = python3
    wsgi-file = /home/webmaster/app/run
    callable = app
    master = true
    enable-threads = true
    processes = 1
    chdir= /home/webmaster/app
    uid =  www-data
    gid = www-data

我将404处理程序设置为返回一些URL信息，而不是获取应用程序的登录页，而是获取带有以下内容的404（即nginx正在传递给uwsgi，并且应用程序正在运行）

网址：

输出：

url root http://192.168.0.250/a/
script root /a
request url http://192.168.0.250/a/a
request path /a
request full_path /a?

所以url\u root和script\u root是您所期望的，我们希望看到的，但是request\u url（）和request\u path（/a）不是。为了让所有东西都有自己的位置，请求路径应该是“/”

我尝试过的

我提到了以前的问题，特别是这个问题： 还有这个：

我在这些帖子中尝试过这些建议，包括以下nginx配置：

超级简单，要求uwsgi做更多：

location /c {
  include uwsgi_params;
  uwsgi_pass 127.0.0.1:10017;
 }

使用UWSGI：

[uwsgi]
socket = :10017
plugin = python3
wsgi-file = /home/webmaster/app/run
callable = app
master = true
enable-threads = true
processes = 1
chdir= /home/webmaster/app
uid =  www-data
gid = www-data
mount = /a=run
manage-script-name = true

这并没有解决问题

接下来，我尝试了重写（try）并欺骗uwsgi，使其认为它在没有脚本根的情况下运行

 location /b {
  rewrite  ^/b/(.*) /$1 break;
  include uwsgi_params;
  uwsgi_pass 127.0.0.1:10017;
 }

这也是不成功的

我也已经阅读了上述问题讨论部分中的建议，虽然大多数人都在修改脚本根目录，但没有人从路径中删除脚本根目录，从而使“/start”路径能够服务于由

我也知道uwsgi_修改器130；虽然这是这些flask应用程序的第一次部署，但这一直是一个问题

根据这个问题，我还尝试在烧瓶侧使用参数

script\u name=None

：

但到目前为止，一切都不管用，我完全被难倒了。这可能很简单，但我不知道从这里看哪里

最后，这些应用程序运行在皇帝模式下，从命令行运行uwsgi，无论是作为单独的.ini文件还是皇帝文件，都没有区别

uwsgi是作为一项通过apt安装的服务运行的，而不是pip（但在plugin=python3中运行良好），以防有人对此有过问题

如果可能的话，我想坚持apt安装

提前向任何能提供帮助的人表示感谢

[编辑时]

这是我的wsgi文件，我试图让flask处理静态路由。应该早点把它包括进去，但这是一个疏忽

谢谢

#!/usr/bin/python3
from application import app
app.config['SECRET_KEY'] = 'XXXXXXXXXX'
app.config["SESSION_COOKIE_SECURE"] = True
app.config["REMEMBER_COOKIE_SECURE"] = True
app.config["SESSION_COOKIE_HTTPONLY"] = True
app.config["REMEMBER_COOKIE_HTTPONLY"] = True
app.config['APPLICATION_ROOT'] = '/a'
app.static_url_path = '/a'
if __name__ == "__main__":
    app.run(debug = True, host= '0.0.0.0', port= 5000)

---

对于偶然发现这一点的其他人：

按照其他问题的建议使用重写，只需注意你使用的表达是否正确

这将失败：

 location /foo {
  rewrite  ^/foo/(.*) /$1 break;
  uwsgi_param SCRIPT_NAME /foo;
  include uwsgi_params;
  uwsgi_pass 127.0.0.1:10017;
 }

因为它只适用于脚本名“foo”，所以在URL“/foo/bar”处路由“/bar”。/foo的根目录将失败

这将有助于： 重写^/foo（.*）/$1中断

e、 g

它将传递脚本名，并将其从使其工作的请求路径中移除

问题是重写中的额外“/”

这是一个简单的错误，花了我很多时间才发现，因为我看不见森林，看不见树木。。。所以我希望这能帮助其他人

 location /foo {
  rewrite  ^/foo/(.*) /$1 break;
  uwsgi_param SCRIPT_NAME /foo;
  include uwsgi_params;
  uwsgi_pass 127.0.0.1:10017;
 }

location /foo {
  rewrite  ^/foo(.*) /$1 break;
  uwsgi_param SCRIPT_NAME /foo;
  include uwsgi_params;
  uwsgi_pass 127.0.0.1:10017;
 }