J'ai de nouveau cette erreur ci-dessous malgré votre solution, j'ai changé IP sur votre recommandation après tout marchait bien, revenir à la normale mais dans la soirée, je n'arrive plus à ajouter des produits dans ma base de données via mon site web. Voici mon nom de domaine : shephela.com, je suis sur shepheb.cluster028.hosting.ovh.net et l'erreur est :
Backend fetch failed
XID: 940188595
Il me semble que ça ressemble à la conversation https://community.ovhcloud.com/t/1358
Etes-vous passé en mode développement ?
Pouvez-vous montrer le contenu de votre fichier .htaccess ainsi que index.php ?
Avez-vous été voir les logs web (via votre espace client) ?
Oui la conversation ressemble à celle que vous aviez mentionné. Car il y a eu la même erreur de 503. Je ne suis pas passé en mode de développement car le site est dans production, dans ma version locale, tout marche bien, il y a rien à signaler plutôt dans la production que je commence à avoir cette erreur il y a 2 semaines auparavant c'était sur les portables mais maintenant sur les navigateurs. La 1ere solution de changer l'adresse IP que vous aviez suggéré je le fais directement ça commencer à marcher mais après une journée, même erreur quand je tente d'ajouter les produits dans la base de données. Voici ici le contenu de fichier logs web en pièces jointes. Voici .htaccess :
# Use the front controller as index file. It serves as a fallback solution when
# every other rewrite/redirect fails (e.g. in an aliased environment without
# mod_rewrite). Additionally, this reduces the matching process for the
# start page (path "/") because otherwise Apache will apply the rewriting rules
# to each configured DirectoryIndex file (e.g. index.php, index.html, index.pl).
DirectoryIndex index.php
# By default, Apache does not evaluate symbolic links if you did not enable this
# feature in your server configuration. Uncomment the following line if you
# install assets as symlinks or if you experience problems related to symlinks
# when compiling LESS/Sass/CoffeScript assets.
# Options +FollowSymlinks
# Disabling MultiViews prevents unwanted negotiation, e.g. "/index" should not resolve
# to the front controller "/index.php" but be rewritten to "/index.php/index".
<IfModule mod_negotiation.c>
Options -MultiViews
</IfModule>
<IfModule mod_rewrite.c>
RewriteEngine On
# Determine the RewriteBase automatically and set it as environment variable.
# If you are using Apache aliases to do mass virtual hosting or installed the
# project in a subdirectory, the base path will be prepended to allow proper
# resolution of the index.php file and to redirect to the correct URI. It will
# work in environments without path prefix as well, providing a safe, one-size
# fits all solution. But as you do not need it in this case, you can comment
# the following 2 lines to eliminate the overhead.
RewriteCond %{REQUEST_URI}::$0 ^(/.+)/(.*)::\2$
RewriteRule .* - [E=BASE:%1]
# Sets the HTTP_AUTHORIZATION header removed by Apache
RewriteCond %{HTTP:Authorization} .+
RewriteRule ^ - [E=HTTP_AUTHORIZATION:%0]
# Fix OVH RewriteBase
RewriteBase /
# Forcer la redirection HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# Redirect to URI without front controller to prevent duplicate content
# (with and without `/index.php`). Only do this redirect on the initial
# rewrite by Apache and not on subsequent cycles. Otherwise we would get an
# endless redirect loop (request -> rewrite to front controller ->
# redirect -> request -> ...).
# So in case you get a "too many redirects" error or you always get redirected
# to the start page because your Apache does not expose the REDIRECT_STATUS
# environment variable, you have 2 choices:
# - disable this feature by commenting the following 2 lines or
# - use Apache >= 2.3.9 and replace all L flags by END flags and remove the
# following RewriteCond (best solution)
RewriteCond %{ENV:REDIRECT_STATUS} =""
RewriteRule ^index\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]
# If the requested filename exists, simply serve it.
# We only want to let Apache serve files and not directories.
# Rewrite all other queries to the front controller.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ %{ENV:BASE}/index.php [L]
</IfModule>
<IfModule !mod_rewrite.c>
<IfModule mod_alias.c>
# When mod_rewrite is not available, we instruct a temporary redirect of
# the start page to the front controller explicitly so that the website
# and the generated links can still be used.
RedirectMatch 307 ^/$ /index.php/
# RedirectTemp cannot be used instead
</IfModule>
</IfModule>
Voici mon index.php :
<?php
use App\Kernel;
require_once dirname(__DIR__).'/vendor/autoload_runtime.php';
return function (array $context) {
return new Kernel($context['APP_ENV'], (bool) $context['APP_DEBUG']);
}; Ma question est de savoir pourquoi depuis presque au tant presque 2 ans je n'ai jamais eu ce genre d'erreur seulement cette semaine parce que même dans mon serveur de production je n'ai pas travaillé ou modifié quelque chose alors l'erreur est de chez vous.
Bonjour,
Je vais être franc avec vous:
1) vous dites "alors l'erreur est de chez vous". Vous vous adressez à la communauté d'utilisateurs. NON L'ERREUR N'EST PAS CHEZ NOUS.
1a) ce n'est pas parce que vous ne touchez pas à un site (ce qui est mal) que l'environnement autour du site n'évolue pas.
1b) si vous ne touchez pas à votre site depuis "presque 2 ans" vous êtes de + en + la chèvre pour les pirates qui découvrent de nouvelles vulnérabilités jour après jour, et en ne faisant pas les mises à jour vous devenez vulnérable.
2) D'après le log il y a des redirections 301 qui fonctionnent, puis échec en 500. A moins de pouvoir expliquer ce que vous faites dans chaque ligne de votre .htaccess, à votre place je mettrais en commentaire toutes les lignes dont vous ne comprenez pas l'utilité, voire même désactiver ce .htaccess en changeant son nom.
3) je reviens avec la supposition que votre site a peut-être été piraté. Après une sauvegarde de sécurité, restaurez depuis chez vous une version plus ancienne (et qui fonctionnait) ...
Je m'excuse d'abord, je croyais que je m'adressais au support de OVH malheureusement, vous êtes utilisateurs. Une autre chose, le site n'est pas piraté, dans mon site il n y a pas grande chose, juste présentation des mes produits, tout est intact, quand je dis presque 2 ans cela ne signifie pas que deux ans sans rien faire, car je me connecte via ssh vérifié et ajouter des parties donc la suite mais pour le moment toutes les fonctionnalités sont à jour via symfony 7 la dernière version. C'est juste que dans les foires aux questions de OVH, il y a erreur 503 ça existe donc je ne suis pas le premier à avoir cette erreur donc comme ça existe c'est un problème DE OVH. Pourquoi alors vous répondez et demander des infos qui peuvent être sensibles? en plus 500 et 301 ce n'est pas pour les erreur donc je suis entrain de parler car il y a des redirections pendant la construction du site ne marchait pas aussi. OK je souhaiterai m'adresse au support de OVH, ils vont m'expliquer les vrais raisons de l'erreur 503 apparemment vous ne le comprenez pas aussi.
Le support d'OVH n'est pas de l'assistance à l'utilisation de l'hébergement. Une consultance informatique vous allez la payer entre 400€ et 1000€ par jour, et ce n'est pas avec un abonnement d'hébergement à 3€ ou 15€ par mois que vous avez la consultance incluse.
Vous pouvez toujours essayer, parfois on tombe sur des gens sympas.
Avez-vous une page qui renvoie un 503 et à laquelle j'ai accès ?
Ok, merci
j'ai créé déjà un ticket avec OVH support.