La taille du tampon est évidemment toujours la valeur par défaut (4096), assurez-vous que vous travaillez sur la bonne instance. Vous pouvez également écrire "-b 32k". Assurez-vous également que cette option (taille du tampon) n'est pas déjà définie dans certains fichiers de configuration.
zakinster
Il n'y a pas de fichier de configuration. Ne fonctionne toujours pas :(
Kartik Rokde
8
uwsgi-docs.readthedocs.org/en/latest/ThingsToKnow.html vous essayez de vous connecter à une socket uwsgi en utilisant le protocole http, en plus de cela les options spécifiées à l'empereur ne sont pas héritées, c'est seulement un gestionnaire de processus
roberto
@zakinster Pour une raison quelconque, le format de valeur avec kne fonctionnait pas pour moi. J'ai dû fournir le nombre complet. Vous ne trouvez aucun pointeur sur les formats que vous pouvez utiliser ici.
famousgarkin
Réponses:
207
J'ai également rencontré le même problème en suivant un tutoriel. Le problème était que je définissais l'option socket = 0.0.0.0:8000au lieu de http = 0.0.0.0:8000.
socketoption destinée à être utilisée avec un routeur tiers (nginx par exemple), tandis que lorsque l' httpoption est définie, uwsgi peut accepter les requêtes HTTP entrantes et les acheminer par lui-même.
Je voudrais juste commenter ceci: uwsgi a les options "http", "http-socket" et "socket". Je voulais appeler des scripts python cgi; "socket" était la réponse.
NuclearPeon
Dans le fichier de configuration Nginx, nous souhaitons peut-être utiliser ceci: include / etc / nginx / uwsgi_params; uwsgi_pass django_upstream;
mennanov le
3
Ce n'est pas la bonne solution. Et si nous voulons unix des sockets?
Farsheed
2
@Farsheed, je viens de décrire pourquoi OP voit cette erreur. Comment résoudre ce problème dépend entièrement de vous. Cela peut être socket = /tmp/myapp.sockou http = 0.0.0.0:8000ou quoi que ce soit selon vos besoins.
Palasaty
1
Bien que cette réponse puisse résoudre le problème dans certaines situations, je pense que la bonne réponse dans le cas général est celle fournie par @Farsheed ci-dessous.
Augusto Destrero
142
La bonne solution est de ne pas passer au protocole HTTP. Il vous suffit d'augmenter la taille de la mémoire tampon dans les paramètres uWSGI.
buffer-size=32768
ou en mode ligne de commande:
-b 32768
Citation de la documentation officielle:
Par défaut, uWSGI alloue un très petit tampon (4096 octets) pour les en-têtes de chaque requête. Si vous commencez à recevoir une «taille de bloc de demande non valide» dans vos journaux, cela peut signifier que vous avez besoin d'un tampon plus grand. Augmentez-le (jusqu'à 65535) avec l'option de taille de tampon.
Si vous recevez «21573» comme taille de bloc de requête dans vos journaux, cela peut signifier que vous utilisez le protocole HTTP pour parler avec une instance parlant le protocole uwsgi. Ne fais pas ça.
Parfois, vous devez utiliser le protocole http, car les sockets unix ne sont disponibles que sur la machine locale. Considérez une situation où vous avez un certain nombre de machines et un équilibreur séparé dessus - vous devez utiliser http-socketici.
Palasaty
@Palasaty ou une socket IP et un uwsgiprotocole, vous pouvez également obtenir la même erreur que OP
Andrei
2
@Palasaty, quelle qu'en soit la cause, la correction de la taille du tampon résoudra le problème!
Farsheed
Lors de l'utilisation de nginx comme proxy inverse, j'ai dû utiliser http-socket. Tout le reste a donné "502 Bad Gateway", même lorsque la taille de la mémoire tampon a été augmentée.
Hubro
Quant à la documentation citée "Si vous recevez '21573' comme taille de bloc de requête dans vos journaux, cela peut signifier que vous utilisez le protocole HTTP pour parler avec une instance parlant le protocole uwsgi. Ne faites pas cela." Il est donc clair que la suggestion est fausse .... De plus, l'utilisateur @Kartic a déjà essayé d'utiliser l'option "-b" ...
LittleEaster
14
J'ai rencontré le même problème en essayant de l'exécuter sous nginx et je suivais les documents ici . Il est important de noter qu'une fois que vous passez à nginx, vous devez vous assurer que vous n'essayez pas d'accéder à l'application sur le port spécifié par le paramètre --socket mais plutôt sur le port "listen" dans nginx.conf. Bien que votre problème soit décrit différemment, le titre correspond exactement au problème que j'ai eu.
oui je suis tombé sur la même chose. en d'autres termes, j'ai eu une erreur lorsque j'ai bouclé le port localement, alors que je pouvais naviguer avec succès vers le 'emplacement' de mon proxy inverse wsgi comme spécifié dans mon `nginx.conf ', car le protocole du serveur wsgi sur mon socket choisi était wsgi et non http
danyamachine
14
Je pourrais le réparer en ajoutant --protocol = http à l'uwsgi
Comment puis-je configurer cela dans le fichier ini des paramètres uWSGI? Ma configuration fonctionne avec votre suggestion mais uniquement dans la ligne de commande.
Cette erreur s'affiche lorsque le serveur uWSGI utilise le uwsgiprotocole et que l'on essaie d'y accéder via le httpprotocole curlou le navigateur Web directement. Si vous le pouvez, essayez de configurer votre serveur uWSGI pour utiliser le httpprotocole, afin de pouvoir y accéder via un navigateur Web ou curl.
Il existe également un simple serveur proxy inverse uwsgi_proxysi vous devez accéder à vos applications via un navigateur Web, etc. Voir la réponse plus étendue https://stackoverflow.com/a/32893520/179581
Comme indiqué dans un autre commentaire de la documentation:
Si vous recevez «21573» comme taille de bloc de requête dans vos journaux, cela peut signifier que vous utilisez le protocole HTTP pour parler avec une instance parlant le protocole uwsgi. Ne fais pas ça.
Si vous utilisez Nginx, cela se produira si vous avez cette configuration (ou quelque chose de similaire étrange):
proxy_pass http://unix:/path/to/socket.sock
c'est parler HTTP à uWSGI (ce qui le rend grincheux). À la place, utilisez:
k
ne fonctionnait pas pour moi. J'ai dû fournir le nombre complet. Vous ne trouvez aucun pointeur sur les formats que vous pouvez utiliser ici.Réponses:
J'ai également rencontré le même problème en suivant un tutoriel. Le problème était que je définissais l'option
socket = 0.0.0.0:8000
au lieu dehttp = 0.0.0.0:8000
.socket
option destinée à être utilisée avec un routeur tiers (nginx par exemple), tandis que lorsque l'http
option est définie, uwsgi peut accepter les requêtes HTTP entrantes et les acheminer par lui-même.la source
socket = /tmp/myapp.sock
ouhttp = 0.0.0.0:8000
ou quoi que ce soit selon vos besoins.La bonne solution est de ne pas passer au protocole HTTP. Il vous suffit d'augmenter la taille de la mémoire tampon dans les paramètres uWSGI.
ou en mode ligne de commande:
Citation de la documentation officielle:
De là: https://uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html
la source
http-socket
ici.uwsgi
protocole, vous pouvez également obtenir la même erreur que OPhttp-socket
. Tout le reste a donné "502 Bad Gateway", même lorsque la taille de la mémoire tampon a été augmentée.J'ai rencontré le même problème en essayant de l'exécuter sous nginx et je suivais les documents ici . Il est important de noter qu'une fois que vous passez à nginx, vous devez vous assurer que vous n'essayez pas d'accéder à l'application sur le port spécifié par le paramètre --socket mais plutôt sur le port "listen" dans nginx.conf. Bien que votre problème soit décrit différemment, le titre correspond exactement au problème que j'ai eu.
la source
Je pourrais le réparer en ajoutant --protocol = http à l'uwsgi
la source
protocol=http
à votre.ini
fichierCette erreur s'affiche lorsque le serveur uWSGI utilise le
uwsgi
protocole et que l'on essaie d'y accéder via lehttp
protocolecurl
ou le navigateur Web directement. Si vous le pouvez, essayez de configurer votre serveur uWSGI pour utiliser lehttp
protocole, afin de pouvoir y accéder via un navigateur Web ou curl.Si vous ne pouvez pas (ou ne voulez pas) le changer, vous pouvez utiliser un proxy inverse (par exemple
nginx
) devant le serveur uWSGI local ou distant, voir https://uwsgi-docs.readthedocs.org/en/latest/Nginx .htmlSi cela vous semble trop de travail, essayez le
uwsgi-tools
package python:Il existe également un simple serveur proxy inverse
uwsgi_proxy
si vous devez accéder à vos applications via un navigateur Web, etc. Voir la réponse plus étendue https://stackoverflow.com/a/32893520/179581la source
Comme indiqué dans un autre commentaire de la documentation:
Si vous utilisez Nginx, cela se produira si vous avez cette configuration (ou quelque chose de similaire étrange):
c'est parler HTTP à uWSGI (ce qui le rend grincheux). À la place, utilisez:
la source
l'homme im havin même problème; alors je l'ai fait ... regardez en utilisant UWSGI + DJANGO + NGINX + REACT +
1 - nano /etc/uwsgi/sites/app_plataform.ini [uwsgi]
2 - effectuez une mise à niveau sérieuse des performances sur nginx ... utilisateur www-data;
3 - puis ... redémarrez les services ou le serveur reebot ...
la source