Passage en https nginx

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;
}

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;
}

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 !

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.

Oui, mais ou se trouve vos ressources ? Soit vous les copier sur le serveur Pterodactyl, soit vous laisser le backend servir les fichiers statiques.