Écran de démarrage bloqué jusqu'au rechargement forcé

Soutien
1

Je vois parfois des forums que j’administre afficher un écran de démarrage qui ne cesse de charger.

Cela semble se produire après des reconstructions ou si je n’ai pas visité le forum depuis longtemps. Cela ne semble pas être associé à différents navigateurs ou plugins de forum. Et cela arrive à certaines personnes mais pas à d’autres.

Un actualisation forcée (Ctrl-F5 sous Windows ou Cmd-Shift-R sur Mac) semble résoudre le problème à chaque fois. Je suppose qu’il s’agit d’un problème de mise en cache avec le CDN, mais je ne suis pas sûr. D’autres personnes rencontrent-elles quelque chose de similaire ?

Console lorsque la page ne charge pas

avant
avant1640×1430 315 KB

Console après une actualisation forcée

après
après1644×428 107 KB

3 « J'aime »
2

image
image856×332 165 KB

Chacune de ces erreurs est due à la limitation du débit de la requête. Discourse ne peut pas fonctionner si ses ressources ne peuvent pas se charger.

Vous devriez vérifier :

  • l’adresse IP correcte de l’utilisateur final est-elle transmise au backend ?
  • la limitation du débit est-elle correctement configurée ? (en général)
  • quelle entité effectue la limitation du débit ici ?
4 « J'aime »
3

Pour ce serveur en question, il n’y a pas de proxy inverse qui cacherait tout le trafic utilisateur derrière une seule IP. Les limites de débit définies dans Discourse sont celles par défaut.

Je suppose que le CDN pourrait faire du proxying ? Existe-t-il une méthode recommandée pour confirmer que les adresses IP des utilisateurs finaux sont transmises au backend ? Je ne vois rien concernant un nombre excessif de requêtes dans les journaux.

Screenshot 2023-04-10 at 09.55.29
Screenshot 2023-04-10 at 09.55.292370×606 54.7 KB

4

C’est littéralement le travail du CDN, donc oui, vous devez vous assurer que la bonne adresse IP de l’utilisateur final est maintenue tout au long de la chaîne de requêtes.

Je suppose que vous ne l’avez pas fait, et que toutes les requêtes du CDN sont comptabilisées par rapport à la limite de débit de requêtes des POP du CDN plutôt que par rapport aux utilisateurs finaux.

image

Vous pouvez voir que le CDN renvoie le 429 ici, mais vous devrez enquêter sur votre configuration spécifique pour déterminer qui prend la décision de renvoyer cette erreur (c’est-à-dire le proxy ou le serveur réel).

3 « J'aime »
5

KeyCDN est le CDN en question. J’ai essayé d’activer OriginShield et d’ajouter un template.yml (dans le style de cloudflare.template.yml) à mon app.yml, mais j’obtenais toujours des erreurs 429.

Plutôt que de continuer à trifouiller, je suis passé à BunnyCDN et cela semble mieux fonctionner.

J’ai mis le fichier modèle ci-dessous au cas où cela aiderait quelqu’un d’autre.

keycdn.template.yml 
run:
  - file:
      path: /tmp/add-keycdn-ips
      chmod: +x
      contents: |
        #!/bin/bash -e
        # Add list of keycdn ips
        curl -s 'https://www.keycdn.com/shield-prefixes.json' | \
          python3 -c "import sys, json; print('\n'.join(json.load(sys.stdin)['prefixes']))" > /tmp/keycdn-ips

        # Make into nginx commands and escape for inclusion into sed append command
        CONTENTS=$(< /tmp/keycdn-ips sed 's/^/set_real_ip_from /' | sed 's/$/;/' | tr '\n' '\\' | sed 's/\\/\\n/g')
        
        echo keycdn IPs:
        echo $(echo | sed "/^/a $CONTENTS")
        # Insert into discourse.conf
        sed -i "/sendfile on;/a $CONTENTS\nreal_ip_header X-Forwarded-For;\nreal_ip_recursive on;" /etc/nginx/conf.d/discourse.conf
        # Clean up
        rm /tmp/keycdn-ips

  - exec: "/tmp/add-keycdn-ips"
  - exec: "rm /tmp/add-keycdn-ips"
6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.