Django (uwsgi) + nginx bleibt bei Curl-Anfragen hängen

Question

Ich versuche, ein Problem zu debuggen, bei dem eine mit Curl ausgeführte Anfrage hängen bleibt. Die Website wird einwandfrei gerendert, wenn ich sie über einen beliebigen Webbrowser öffne. Auch in den Protokolldateien kann ich nichts Verdächtiges finden.

Ich habe die Protokollierung aktiviert error_log info;, sehe aber nichts in den Nginx-Protokolldateien.

Hier ist eine Beispielanforderung:

$ curl -v -o test.txt https://www.happyworld.bg
* Rebuilt URL to: https://www.happyworld.bg/
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 172.104.135.164...
* Connected to www.happyworld.bg (172.104.135.164) port 443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 604 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384

.... Zertifikatsinformationen ... * ALPN, Server akzeptiert Verwendung von http/1.1

GET / HTTP/1.1 Host: www.happyworld.bg User-Agent: curl/7.47.0 Akzeptieren:/

  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0< HTTP/1.1 200 OK
< Server: nginx/1.13.6
< Date: Thu, 30 Aug 2018 14:18:56 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 32484
< Connection: keep-alive
< Vary: Cookie
< X-Frame-Options: SAMEORIGIN
< Cache-Control: max-age=600
< Expires: Thu, 30 Aug 2018 14:28:56 GMT
< Strict-Transport-Security: max-age=63072000; includeSubdomains
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff
< 
{ [15988 bytes data]
 74 32484   74 24037    0     0   2563      0  0:00:12  0:00:09  0:00:03 

und nach einiger Zeit bekomme ich:

* Closing connection 0
curl: (18) transfer closed with 8447 bytes remaining to read

In der Anwendungsprotokolldatei kann ich nur Folgendes sehen:

[pid: 12406|app: 0|req: 1/1] ........... () {42 vars in 486 bytes} [Thu Aug 30 14:15:03 2018] GET / => generated 24037 bytes in 85 msecs (HTTP/1.1 200) 6 headers in 193 bytes (1 switches on core 0)

Hier ist ein Beispiel für die virtuelle Blockkonfiguration:

upstream wagtail { server 127.0.0.1:3002; }

location @CMS {
  include /etc/nginx/uwsgi_params;
  uwsgi_pass wagtail;
  uwsgi_param Host $host;
  uwsgi_param X-Real-IP $remote_addr;
  uwsgi_param X-Forwarded-For $proxy_add_x_forwarded_for;
  uwsgi_param X-Forwarded-Proto $http_x_forwarded_proto;
}

Irgendeine Ahnung, was die Ursache sein könnte oder ob ich etwas übersehe?