Nginx 1 FastCGI envoyé dans stderr: "Script primaire inconnu"

J'ai trouvé votre question en cherchant le même message d'erreur mais en utilisant apache + php-fpm (pas nginx). Pour moi, le problème était une barre oblique mal placée : de nombreuses suggestions de configuration incluent une ligne de la forme :

SetHandler "proxy:unix:/chemin/vers/fichier.socket|fcgi://localhost/:9000"

En plaçant la dernière barre oblique après le numéro de port comme ceci :

SetHandler "proxy:unix:/chemin/vers/fichier.socket|fcgi://localhost:9000/"

le problème a disparu pour moi. Peut-être pouvez-vous faire quelque chose de similaire

J'ai été piégé par ce message bizarre pendant très longtemps. Je ne suis pas sûr de la cause car tout fonctionnait pendant un certain temps puis tout à coup a cessé de fonctionner.

Je raccourcissais les URL des wikis comme prescrit par MediaWiki, avec Bitnami / Nginx sur Lightsail.

J'ai recherché et lu de nombreux messages, celui-ci semble résumer tous les scénarios possibles, et je les ai tous essayés :

• nginx va bien, le dossier php de la racine fonctionne, le sous-dossier ne fonctionne pas
• une erreur est renvoyée en tant que 404 + une simple chaîne "Fichier non trouvé", pas par nginx
• ajouter root au serveur, n'a pas fonctionné
• vérifier les autorisations des dossiers et de php-fpm / nginx, aucun problème la racine et les sous-dossiers sont les mêmes
• vérifier le manuel de php-fpm pour l'interprétation du code d'erreur, je n'ai pas pu en trouver un
• activer le journal d'accès de php-fpm, j'ai trouvé que l'URI de la requête était correcte, mais le code 404 est renvoyé
• essayer d'activer le mode verbeux / débogage pour php-fpm, n'a pas fonctionné, le fichier de journal d'erreurs supposé est toujours vide

Je devais donc essayer le dernier recours, puisque le dossier php de la racine fonctionnait et les sous-dossiers ne fonctionnaient pas, la seule différence majeure entre eux autre que root est que le dossier root utilisait $request_filename et les emplacements de sous-dossiers utilisaient $document_root et $fastcgi_script_name, j'ai donc modifié les paramètres d'emplacement des sous-dossiers pour correspondre à ceux de la racine.

Alors ça a marché...Je ne suis toujours pas sûr pourquoi ça a marché. Parce que lorsque je vérifie le journal d'accès de php-fpm, je vois la même URI, une était 404 et l'autre était 200.

La seule différence était dans la configuration. Étant donné qu'ils produisent la même sortie, je ne sais pas pourquoi le résultat était différent.

Quoi qu'il en soit, j'ai décidé de poster mes 2 cents ici, j'espère que cela aidera.

PS : J'espère vraiment que PHP fournira de meilleurs messages d'erreur et un mode verbeux, car il est vraiment frustrant de ne pas pouvoir isoler le problème et de ne pas pouvoir voir la sortie verbeuse et les informations de débogage.

Pour ma part, il s'agissait d'extensions.

Mon php-fpm.www.access.log indiquait :

"GET /index.php5" 404

Pourtant, le fichier index du site (MediaWiki) était index.php. Il s'avère que j'avais des extensions mélangées (php vs php5) dans les entrées pertinentes du fichier nginx.conf. Voici une configuration fonctionnelle :

location / {
    index index.php;
    try_files $uri $uri/ = @mediawiki;
}
location = /favicon.ico {
    return 204;
}
location ~ \.php$ {
    fastcgi_pass unix:/var/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME /path/to/viki$fastcgi_script_name;
    fastcgi_param DOCUMENT_ROOT /path/to/viki;
    fastcgi_intercept_errors on;
}

location @mediawiki {
    rewrite ^/([^?]*)(?:\?(.*))? /index.php?title=$1&$args last;
}

Vous pouvez faire en sorte que toutes ces entrées utilisent index.php5 à la place, il suffit d'ajouter un fichier index.php5 à la racine avec ce contenu :

`

(pas de balise de fermeture).

`

Je rencontre la même question, mais aucune autre méthode ne m'a aidé à résoudre le problème!

J'ai trouvé la solution, la clé est que: Le droit d'utilisateur Linux mène à la question: FastCGI envoyé dans stderr: "Script principal inconnu"

Parce que l'utilisateur:groupe par défaut de PHP-FPM est apache:apache, mais votre répertoire de code est quelqu'un:d'autres. Vous devriez donc changer le droit d'utilisateur!

J'ai écrit un blog pour résoudre cette question, vous pouvez consulter ce blog:

[Nginx FastCGI sent in stderr: "Primary script unknown"][1] ` [1]: http://geekhades.blogspot.com/2017/06/nginx-fastcgi-sent-in-stderr-primary.html

J'ai cloné un site distant, et le fichier wp-config.php déjà existant avait les informations de la base de données du serveur distant.

J'ai résolu ce problème en configurant mon fichier de configuration wordpress local, avec les informations de ma base de données locale.