我知道，关于此问题有很多问题，主要是因为关注了官方uWSGI guide。我也有权限方面的麻烦，但其他答案已涵盖了它们。我想更好地了解如何以及何时创建Unix套接字/套接字文件。仅供参考，这是在运行Amazon Linux 2 AMI的AWS ec2实例上。
uWSGI指南指导您安装nginx，Django和uwsgi。然后分别测试Django开发服务器和nginx。然后在this section处测试uWSGI和nginx是否与tcp / ip套接字一起工作以进行通信。之后，他们仍然完全不涉及Django项目，他们描述了如何使用Unix套接字而不是tcp / ip套接字进行nginx和uWSGI之间的通信。完成所有nginx / uWSGI配置后，您可以从主目录运行命令（至少对于我的特定文件结构和Django项目~/test_project）：
uwsgi --socket test_project/test_project.sock --wsgi-file test.py
一旦处理了一些权限问题，此方法就可以正常工作。我的问题是：test_project.sock是什么，什么时候创建的，以及哪个进程创建的。我目前的最佳理解是uWSGI创建了它，但是为什么我们要完全合并Django项目（在这里test_project）呢？为什么不只在Django项目文件夹之外创建套接字？我们是否使用python语法，并且它是某些test_project对象或模块的成员？
我知道test_project.sock与Unix套接字相关联。我认为这将是一个真实的文件，但事实并非如此。即使当我在后台运行uWSGI并在适当的目录中查找时，它也不存在。是否只是短暂的，以至仅在将请求从Nginx实际传递到uWSGI时才存在？
此外，在无法实际看到文件（test_project.sock）的情况下，我怎么知道访问该文件需要哪些权限？我进行了一些测试，现在怀疑它与~/test_project/test_project/wsgi.py文件的权限有关，但是我没有任何直接证据。
答案 0 :(得分：1)
您可以在Django项目之外创建套接字*.sock文件。当您这样做时，该文件将在uWSGI进程结束后继续存在。然后，您可以查看文件并确定权限。
我很困惑，因为很多教程，包括[官方uWSGI] 1教程，都要求用户将*.sock文件放入Django项目。我仍然不确定为什么这是必要的，以及在这种情况下为什么文件不持久。