Ich sehe gelegentlich, dass Foren, die ich betreibe, einen Splashscreen anzeigen, der nie aufhört zu laden.
Es scheint nach Rebuilds oder nach längerer Inaktivität auf dem Forum aufzutreten. Es scheint nicht mit verschiedenen Browsern oder Forum-Plugins zusammenzuhängen. Und es passiert einigen Leuten, aber nicht anderen.
Ein Hard Refresh (Strg-F5 unter Windows oder Cmd-Shift-R auf dem Mac) scheint es jedes Mal zu beheben. Ich vermute, dass es sich um ein Caching-Problem mit dem CDN handelt, aber ich bin mir nicht sicher. Erlebt jemand etwas Ähnliches?
Jeder einzelne dieser Fehler ist darauf zurückzuführen, dass die Anfrage einer Ratenbegrenzung unterliegt. Discourse kann nicht ausgeführt werden, wenn seine Assets nicht geladen werden können.
Sie sollten überprüfen:
Wird die korrekte Endbenutzer-IP-Adresse an das Backend übergeben?
Ist die Ratenbegrenzung korrekt eingerichtet? (im Allgemeinen)
Welche Entität führt hier die Ratenbegrenzung durch?
Für diesen Server gibt es keinen Reverse-Proxy, der den gesamten Benutzerverkehr hinter einer IP verbergen würde. Die in Discourse festgelegten Ratenbegrenzungen sind die Standardwerte.
Ich nehme an, das CDN könnte ein Proxying durchführen? Gibt es eine empfohlene Methode, um zu bestätigen, dass die IPs der Endbenutzer an das Backend weitergeleitet werden? Ich sehe nichts von zu vielen Anfragen in den Protokollen.
[quote=„Yaw Anokwa, post:3, topic:261206, username:yanokwa”]
Für diesen Server gibt es keinen Reverse-Proxy
[/quote]
[quote=„Yaw Anokwa, post:3, topic:261206, username:yanokwa”]
Ich nehme an, das CDN könnte ein Proxying betreiben?
[/quote]
Das ist buchstäblich die Aufgabe des CDN. Sie müssen also sicherstellen, dass die richtige Endbenutzer-IP in der Anforderungskette beibehalten wird.
Ich vermute, das haben Sie nicht getan, und alle Anfragen vom CDN werden gegen das Anforderungsratenlimit der CDN-POPs und nicht gegen die Endbenutzer gezählt.
Sie können sehen, dass das CDN hier die 429 zurückgibt, aber Sie müssen Ihre spezifische Einrichtung untersuchen, um festzustellen, wer die Entscheidung trifft, diese Fehlermeldung zurückzugeben (d. h. der Proxy oder der echte Server).
KeyCDN ist das betreffende CDN. Ich habe versucht, OriginShield zu aktivieren und eine template.yml (im Stil von cloudflare.template.yml) zu meiner app.yml hinzuzufügen, aber ich erhielt immer noch 429er.
Anstatt weiter daran herumzufummeln, bin ich zu BunnyCDN gewechselt, und das scheint besser zu funktionieren.
Ich habe die Vorlagendatei unten eingefügt, falls sie jemand anderem hilft.
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"
