Stellt Nginx den Antwortdaten den Post-Request-Body-Inhalt aus seinem Puffer voran? ⇐ Php

[Anonymous]

Seit ein paar Tagen kämpfe ich mit einem seltsamen Problem in einer Laravel-Anwendung, die in einem Docker-Container auf einem Ubuntu-System läuft und Laravel/ rebing-graphql-Anbieter zur Bereitstellung von graphql-Abfrageantworten.
Also verwende ich die GraphiQL-Schnittstelle, um graphql zu senden Anfragen an meine Backend.
Das Ergebnis, das ich für meine Anfrage erhalte, umfasst nicht nur die gültige Antwort, sondern auch die Parameter, die ich zusammen mit der Post-Anfrage sende;
"{\"query\":\"query Users {\\n users(pagination: {offset: 0, limit: 1}) {\\n items {\\n id\\n }\\n }\\n}\",\"variables\":null,\"operationName\":\"Users\"}{\"data\":{\"users\":{\"items\":[{\"id\":53}]}}}"

Diese Antwort kommt nicht mit einem Inhaltstyp: application/json, sondern als text/html.
Es scheint wie der Hauptteil der Post-Anfrage wird den Antwortdaten meiner API vorangestellt. Dies führt zu einem JSON-Analysefehler auf meinem Client. Der API-Datenteil hier selbst scheint gültig zu sein.
Das Seltsamste an diesem Problem ist, dass es bei jeder zweiten(!) Anfrage auftritt.
So erhalten etwa 50 % meiner Anfragen eine gültige Antwort, die im JSON-Format und ohne vorangestellten Post-Anfragetext vorliegt.
Ich habe versucht, die Grundursache dieses Problems zu analysieren, und das ist mir auch gelungen Keine Stelle im Code gefunden, an der sich die Parameter befinden wird als zusätzliche Ausgabe wiedergegeben.
Führt eine Nginx-Konfiguration dazu, dass der Inhalt des Post-Request-Bodys vorangestellt wird?
Während meiner Nach weiteren Nachforschungen begann ich, die Datei index.php im öffentlichen Verzeichnis von Laravels zu ersetzen und erstellte eine benutzerdefinierte index.php, die nichts als einen Exit(„Test“) enthält. ; Ausführung.
Das Ergebnis war unerwartet. Ich habe immer noch bei jeder zweiten Anfrage meine Post-Parameter der Ausgabe vorangestellt:
"{\"query\":\"query Users {\\n users(pagination: {offset: 0, limit: 1}) {\\n items {\\n id\\n }\\n }\\n}\",\"variables\":null,\"operationName\":\"Users\"}test"

Ich verwende ein Docker-Image von nginx:alpine und php:7.4-fpm-alpine.
Der Docker-Container öffnet einen Port, der einen Proxy von einem Apache2-Server erhält, der läuft auf meinem Root-System.
Dies ist meine Nginx-Standardkonfiguration:
server {
listen 80;

server_name my-domain.com;
error_log /var/log/nginx/error.log;
access_log /var/log/nginx/access.log;

root /var/www/html/public;

index index.php index.html;

location / {
client_max_body_size 100M;

if ($request_method = 'OPTIONS') {
add_header Access-Control-Max-Age 1728000;
add_header Access-Control-Allow-Credentials true;
add_header Access-Control-Allow-Origin $http_origin;
add_header Access-Control-Allow-Methods "GET, POST, OPTIONS, PUT, DELETE, HEAD";
add_header Content-Length 0;
add_header Content-Type "text/plain; charset=UTF-8";
add_header Access-Control-Allow-Headers "Origin,X-Requested-With,Content-Type,Accept,X-CSRF-Token,X-XSRF-TOKEN,Authorization";
return 204;
}

try_files $uri $uri/ /index.php?$query_string;
gzip_static on;
}

location ~ \.php$ {
client_max_body_size 100M;

if ($http_origin ~* "^(blob:)?http(s)?://www.my-domain.com(:[0-9]{2,4})?$") {
add_header Access-Control-Allow-Credentials true;
add_header Access-Control-Allow-Origin $http_origin;
add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
add_header Access-Control-Allow-Headers "Origin,X-Requested-With,Content-Type,Accept,X-CSRF-Token,X-XSRF-TOKEN,Authorization";
}

try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass epapistagephp:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
}
}

Gibt es jemanden, der ein solches Verhalten bereits erlebt hat, oder haben Sie einen Hinweis, wo Sie mit einer weiteren Analyse beginnen können?
Vielen Dank Viel im Voraus!!
Grüße Jules