Passage en https nginx

Résolu
artemis-037 Messages postés 63 Statut Membre -  
artemis-037 Messages postés 63 Statut Membre -

bonjour,

depuis 2 jour je galère avec ma config Nginx voici ma config actuele

server {
    listen 443 ssl http2;
    server_name friday.fridaydev.ovh;

    root /home/container/www;
    index index.php index.html index.htm;

    ssl_certificate /etc/letsencrypt/live/friday.fridaydev.ovh/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/friday.fridaydev.ovh/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    # Fichiers statiques servis directement
    location ~* \.(css|js|jpg|jpeg|gif|png|svg|ico|woff|woff2|ttf|eot)$ {
        try_files $uri =404;
        expires max;
        access_log off;
    }

    # PHP (si tu veux gérer les fichiers PHP directement via nginx + php-fpm)
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/phpX.X-fpm.sock;  # remplace phpX.X par ta version
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    # Proxy vers le backend WordPress dans le container Docker
    location / {
        proxy_pass http://192.168.0.100:10009/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

mais ca me mes non sécurisé et le css et les autre pas ne se charge pas 

https://friday.fridaydev.ovh

merci d'avance a tout ceux qui pourront m'aidez

pour information mon site fonctionnés en http avec : 
 

server {
    listen 80;
    server_name friday.fridaydev.ovh;

    root /home/container/www;  # chemin vers les fichiers WordPress dans ton container Pterodactyl
    index index.php index.html index.htm;

    # Fichiers statiques servis directement
    location ~* .(css|js|jpg|jpeg|gif|png|svg|ico|woff|woff2|ttf|eot)$ {
        try_files $uri =404;
        expires max;
        access_log off;
    }

    # Proxy vers le backend WordPress (ton container sur 192.168.0.100:10009)
    location / {
        proxy_pass http://192.168.0.100:10009/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}



cordialement

Artemis 037

5 réponses

Réponse 1 / 5
Bruno83200_6929 Messages postés 650 Statut Membre 150
 

Bonjour,

Voici une configuration Nginx corrigée et optimisée pour résoudre votre problème :

# Redirection HTTP vers HTTPS
server {
    listen 80;
    server_name friday.fridaydev.ovh;
    return 301 https://$host$request_uri;
}

# Configuration HTTPS
server {
    listen 443 ssl http2;
    server_name friday.fridaydev.ovh;

    root /home/container/www;
    index index.php index.html index.htm;

    # Configuration SSL
    ssl_certificate /etc/letsencrypt/live/friday.fridaydev.ovh/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/friday.fridaydev.ovh/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    # Fichiers statiques servis directement
    location ~* \.(css|js|jpg|jpeg|gif|png|svg|ico|woff|woff2|ttf|eot)$ {
        try_files $uri =404;
        expires max;
        access_log off;
    }

    # PHP-FPM pour les fichiers PHP locaux (si nécessaire)
    location ~ \.php$ {
        try_files $uri =404; # Sécurité pour éviter l'exécution de fichiers inexistants
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/phpX.X-fpm.sock; # Remplace phpX.X par ta version (ex: php7.4-fpm)
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    # Proxy vers le backend WordPress
    location / {
        try_files $uri $uri/ @wordpress;
    }

    location @wordpress {
        proxy_pass 
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # Amélioration de la sécurité
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options DENY;
}
1
Réponse 2 / 5
artemis-037 Messages postés 63 Statut Membre 2
 

merci pour votre réponce j'ai du modifié le script car il ne fonctioné pas 

ca ne me mes plus non sécurisé mais je n'ai toujour pas de css ni accés au autre page
 

server {
    listen 80;
    server_name friday.fridaydev.ovh;
    return 301 https://$host$request_uri;
}


server {
    listen 443 ssl http2;
    server_name friday.fridaydev.ovh;

    root /home/container/www;
    index index.php index.html index.htm;

    # Configuration SSL
    ssl_certificate /etc/letsencrypt/live/friday.fridaydev.ovh/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/friday.fridaydev.ovh/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;


    location ~* \.(css|js|jpg|jpeg|gif|png|svg|ico|woff|woff2|ttf|eot)$ {
        try_files $uri =404;
        expires max;
        access_log off;
    }


    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/phpX.X-fpm.sock; # Remplace phpX.X par ta version (ex: php7.4-fpm)
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }


    location / {
        try_files $uri $uri/ @wordpress;
    }

    location @wordpress {
        proxy_pass 
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }


    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options DENY;
}
0
Bruno83200_6929 Messages postés 650 Statut Membre 150
 

Je reviendrai demain AM vous aider.

0
Réponse 3 / 5
Bruno83200_6929 Messages postés 650 Statut Membre 150
 

Bonjour,

Je vois que vous avez appliqué la plupart des modifications suggérées, et c'est une bonne nouvelle que l'avertissement "non sécurisé" ait disparu, ce qui indique que le certificat SSL fonctionne correctement. Cependant, il reste deux problèmes principaux : le CSS (et autres fichiers statiques) ne se charge pas et l'accès aux autres pages ne fonctionne pas. De plus, j'ai remarqué une erreur critique dans votre configuration actuelle : la directive proxy_pass dans le bloc location @wordpress est incomplète (elle manque l'URL du backend). Voici une analyse et une solution pour résoudre ces problèmes.

Erreur dans proxy_pass :
Dans le bloc location @wordpress, la directive proxy_pass est vide (proxy_pass sans URL). Cela empêche Nginx de rediriger les requêtes vers votre backend WordPress ( ce qui peut expliquer pourquoi les pages dynamiques (comme les pages WordPress autres que la page d'accueil) ne fonctionnent pas.

Fichiers statiques (CSS, JS, etc.) ne se chargent pas :
Le bloc location ~* \.(css|js|jpg|...)$ semble correct, mais il est possible que :
Les fichiers statiques ne soient pas présents dans /home/container/www ou aient des permissions incorrectes.
WordPress génère des URLs incorrectes pour les fichiers statiques (par exemple, en HTTP au lieu de HTTPS, ou avec un mauvais chemin).
Le backend WordPress gère mal les requêtes pour les fichiers statiques, surtout si elles sont redirigées via proxy_pass.

Accès aux autres pages :
Si seules certaines pages (comme la page d'accueil) fonctionnent, cela peut être lié à :
Une mauvaise configuration des permaliens dans WordPress.
Un problème avec le backend WordPress qui ne traite pas correctement les requêtes pour les sous-pages.
Un conflit entre le bloc location / et le bloc location ~ \.php$, surtout si les pages WordPress sont générées dynamiquement via PHP.

PHP-FPM :
Vous avez inclus un bloc pour PHP-FPM, mais si votre backend WordPress (sur 192.168.0.100:10009) gère déjà le traitement PHP, ce bloc peut être inutile et causer des conflits. Il faut clarifier si vous utilisez PHP-FPM localement ou si tout est géré par le backend.

Voici une version corrigée de votre configuration Nginx, avec la directive proxy_pass complétée et quelques ajustements pour résoudre les problèmes de fichiers statiques et d'accès aux pages :

# Redirection HTTP vers HTTPS
server {
    listen 80;
    server_name friday.fridaydev.ovh;
    return 301 https://$host$request_uri;
}

# Configuration HTTPS
server {
    listen 443 ssl http2;
    server_name friday.fridaydev.ovh;

    root /home/container/www;
    index index.php index.html index.htm;

    # Configuration SSL
    ssl_certificate /etc/letsencrypt/live/friday.fridaydev.ovh/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/friday.fridaydev.ovh/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    # Fichiers statiques servis directement
    location ~* \.(css|js|jpg|jpeg|gif|png|svg|ico|woff|woff2|ttf|eot)$ {
        try_files $uri =404;
        expires max;
        access_log off;
    }

    # PHP-FPM (optionnel, à supprimer si WordPress est entièrement géré par le backend)
    location ~ \.php$ {
        try_files $uri =404;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.4-fpm.sock; # Remplace par la version correcte (ex: php7.4-fpm ou php8.1-fpm)
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    # Proxy vers le backend WordPress
    location / {
        try_files $uri $uri/ @wordpress;
    }

    location @wordpress {
        proxy_pass  # URL complète du backend WordPress
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # Amélioration de la sécurité
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options DENY;
}

Vérifiez la présence des fichiers :
Assurez-vous que les fichiers CSS, JS, etc., sont bien présents dans /home/container/www. Par exemple, si WordPress utilise un thème, les fichiers CSS sont généralement dans /home/container/www/wp-content/themes/<votre-thème>/.

Exécutez :

ls -l /home/container/www/wp-content/themes/

Vérifiez les permissions :

sudo chown -R www-data:www-data /home/container/www
sudo chmod -R 755 /home/container/www

Vérifiez les URLs générées par WordPress :
Ouvrez les outils de développement de votre navigateur (F12) et allez à l'onglet "Réseau". Rechargez la page https://friday.fridaydev.ovh et regardez les requêtes pour les fichiers CSS/JS.
Si les URLs sont en HTTP au lieu de HTTPS, ou si elles pointent vers un mauvais chemin, vous devez corriger la configuration de WordPress :
Dans wp-config.php, ajoutez ou vérifiez :

define('WP_HOME', 'https://friday.fridaydev.ovh');
define('WP_SITEURL', 'https://friday.fridaydev.ovh');

Dans le tableau de bord WordPress, allez à Réglages > Général et assurez-vous que les champs "Adresse web de WordPress" et "Adresse web du site" sont définis à https://friday.fridaydev.ovh.

Si cela ne fonctionne toujours pas, il faudra vérifier l'accès aux autres pages !
0
artemis-037 Messages postés 63 Statut Membre 2
 

re-bonjour, merci du temp que vous accordé a mon probleme, je vient de me rendre compte que j'ai oublié de precisé je configure le nginx sur mon serveur pterodactyl et pas celui de la console qui contient le wordpress et ce que le probleme peut venir de la ? de plus le site recupere l'icone du site qui et heberger sur le serveur lui meme (le site de pterodactyl) et toujour pas de css quand je suis sur https://friday.fridaydev.ovh j'ai le site sans le css et sur https://friday.fridaydev.ovh/wp-admin  ca me redirige vers https://friday.fridaydev.ovh:1009/wp-admin et dans la base de donné on voit bient les url de wordpress sont bonne : 


Éditer ÉditerCopier CopierSupprimer Supprimer 2 siteurl https://friday.fridaydev.ovh on
Éditer ÉditerCopier CopierSupprimer Supprimer 3 home https://friday.fridaydev.ovh on

0
Réponse 4 / 5
Bruno83200_6929 Messages postés 650 Statut Membre 150
 

Re Bonjour,

Merci pour ces précisions supplémentaires ! Elles sont très utiles pour mieux comprendre votre configuration et identifier la source des problèmes. Vous avez mentionné que vous configurez Nginx sur votre serveur Pterodactyl, et non sur le serveur qui héberge directement WordPress (sur 192.168.0.100:10009). Cela, combiné aux symptômes que vous décrivez (pas de CSS, redirection incorrecte vers https://friday.fridaydev.ovh:1009/wp-admin, icône du site Pterodactyl), indique plusieurs problèmes liés à la configuration du reverse proxy et à la gestion des URLs par WordPress.

Redirection incorrecte vers https://friday.fridaydev.ovh:1009/wp-admin :
Lorsque vous accédez à https://friday.fridaydev.ovh/wp-admin, vous êtes redirigé vers https://friday.fridaydev.ovh:1009/wp-admin. Cela suggère que WordPress, sur le backend (192.168.0.100:10009), génère des URLs qui incluent le port du backend (:1009) au lieu de rester sur le domaine public (friday.fridaydev.ovh). Cela peut être dû à :
Une mauvaise configuration des en-têtes Host ou X-Forwarded-* dans Nginx, qui ne transmet pas correctement le domaine et le protocole au backend.
Une configuration dans WordPress (ou dans le serveur backend) qui force l'utilisation du port :1009.

Fichiers CSS/JS ne se chargent pas :
Vous indiquez que l'icône du site (probablement le favicon) est chargée depuis le serveur Pterodactyl lui-même, mais que les fichiers CSS/JS ne se chargent pas. Cela peut être dû à :
Les fichiers statiques (CSS, JS, etc.) ne sont pas présents dans /home/container/www sur le serveur Pterodactyl, ou les URLs générées par WordPress pointent vers le backend (192.168.0.100:10009) au lieu du domaine public.
WordPress génère des URLs incorrectes pour les fichiers statiques (par exemple, en utilisant http:// ou :1009 au lieu de https://friday.fridaydev.ovh).
Le bloc location ~* \.(css|js|...)$ ne fonctionne pas comme prévu, car les fichiers statiques sont peut-être demandés au backend et non servis localement.

Icône du site Pterodactyl :
Le fait que l'icône du site soit celle de Pterodactyl suggère que certaines ressources sont servies directement depuis le serveur Pterodactyl (peut-être un fichier favicon.ico dans /home/container/www) plutôt que depuis le backend WordPress. Cela indique que le bloc location ~* \.(ico)$ fonctionne pour certaines ressources statiques, mais pas pour les CSS/JS.

Configuration Nginx sur Pterodactyl :
Votre Nginx agit comme un reverse proxy sur le serveur Pterodactyl, redirigeant les requêtes vers le backend WordPress (192.168.0.100:10009). Cela signifie que le serveur Pterodactyl ne contient probablement pas les fichiers WordPress (PHP, thèmes, etc.), mais uniquement les fichiers statiques (si vous les avez copiés dans /home/container/www). Si les fichiers statiques ne sont pas synchronisés ou si WordPress génère des URLs incorrectes, cela explique pourquoi le CSS ne se charge pas.

URLs dans la base de données WordPress :
Vous avez confirmé que siteurl et home dans la base de données WordPress sont correctement définis à https://friday.fridaydev.ovh. C'est une bonne chose, mais cela ne garantit pas que toutes les URLs générées par WordPress (pour les fichiers statiques ou les sous-pages) respectent ce réglage, surtout si le backend détecte une configuration différente (par exemple, à cause des en-têtes Host ou du protocole).

Voici une version mise à jour de votre configuration Nginx, optimisée pour fonctionner comme reverse proxy sur le serveur Pterodactyl :

# Redirection HTTP vers HTTPS
server {
    listen 80;
    server_name friday.fridaydev.ovh;
    return 301 https://$host$request_uri;
}

# Configuration HTTPS
server {
    listen 443 ssl http2;
    server_name friday.fridaydev.ovh;

    root /home/container/www;
    index index.php index.html index.htm;

    # Configuration SSL
    ssl_certificate /etc/letsencrypt/live/friday.fridaydev.ovh/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/friday.fridaydev.ovh/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    # Fichiers statiques servis directement
    location ~* \.(css|js|jpg|jpeg|gif|png|svg|ico|woff|woff2|ttf|eot)$ {
        try_files $uri @wordpress; # Tomber sur le backend si le fichier n'existe pas localement
        expires max;
        access_log off;
    }

    # Proxy vers le backend WordPress
    location / {
        proxy_pass 
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Port 443;
    }

    # Amélioration de la sécurité
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options DENY;
}

Étapes pour résoudre les problèmes :

Appliquez la nouvelle configuration Nginx :
Sauvegardez l'ancienne configuration :

sudo cp /etc/nginx/sites-available/friday.fridaydev.ovh /etc/nginx/sites-available/friday.fridaydev.ovh.bak

Remplacez le contenu du fichier de configuration par celui ci-dessus.
Testez la configuration :

sudo nginx -t

Redémarrez Nginx :

sudo systemctl restart nginx

Vérifiez les fichiers statiques :

Vérifiez si les fichiers CSS/JS sont présents dans /home/container/www sur le serveur Pterodactyl :

ls -l /home/container/www/wp-content/themes/

Si les fichiers ne sont pas présents, revenez vers moi.
0
artemis-037 Messages postés 63 Statut Membre 2
 

d'apres mes recherche le probleme serait que wordpress veut chargé les ressource en http alors que le site et en https, je cherche un solution avec un plugin qui convertie le http en https.

0
Bruno83200_6929 Messages postés 650 Statut Membre 150 > artemis-037 Messages postés 63 Statut Membre
 

Really Simple SSL
Description : C’est l’un des plugins les plus populaires (plus de 2 millions d’installations actives) pour migrer un site WordPress de HTTP vers HTTPS. Il redirige automatiquement les requêtes HTTP vers HTTPS et corrige les contenus mixtes en remplaçant les URLs HTTP par HTTPS dans la base de données et les pages rendues.

0
artemis-037 Messages postés 63 Statut Membre 2 > Bruno83200_6929 Messages postés 650 Statut Membre
 

re-bonjour desolé de revenir vers vous si tard mais au final j'ai abandoné wordpress qui fonctioné pas avec un reverse proxy et j'ai donc codé mon site en html

1

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
Réponse 5 / 5
Bruno83200_6929 Messages postés 650 Statut Membre 150
 

Oui, mais ou se trouve vos ressources ? Soit vous les copier sur le serveur Pterodactyl, soit vous laisser le backend servir les fichiers statiques.
0
Bruno83200_6929 Messages postés 650 Statut Membre 150
 

Avez-vous des erreurs spécifiques dans les logs Nginx (error.log et access.log).

0

Discussions similaires

Site Easywifi.config inaccessible /
Charly -
Repeteurwifi -

8 réponses
Comment se débarrasser de Welcome to Nginx! ?
polinek -
Kohane -

18 réponses
my.canalbox.africa changer le mot de passe
Thierry973 -
baladur13 -

16 réponses
Comment définir ma nouvelle PS4 comme PS4 principale ?
cod-alpha -
hhh -

8 réponses
Impossible de se connecter a 192.168.1.1
papemane -
Quels -

5 réponses