服務器剛短暫離線了幾分鐘，已恢復。
3 Likes
恢复了好耶desuwa～
2 Likes
哎我去这是suen的声音吗，这么好听？（没听过）
7 Likes
气泡音
这个功能好，你们能唱歌给我听吗
3 Likes
哇啊啊啊啊啊啊suen啊啊啊啊啊啊啊啊啊啊啊
3 Likes
上课时候声音不是这样的 
3 Likes
其实还有suen的打招呼，因为说得太快，吧“你好”说成了“喵”
3 Likes
这个是只能现场录音还是可以上传音频
3 Likes
修完⋯⋯
2 Likes
平板適配⋯⋯ DONE⋯⋯
6 Likes
平板的适配搞定了，不容易呀（笑）
2 Likes
今天早晨六點多順手更新維護論壇後出現暫短無法登陸， * 429 Too Many Requests，關了 bot 們禁閉。
中午整理：
加入前置機保護，解決此後可能的瞬間流量風暴。
統一了前後機器上傳附件大小為 100M 。
加入反代風控。
5 Likes
Incident Brief: Login/Load Failures & “Storm” Mitigation (Front Proxy + Discourse)
Date: Jan 30, 2026 (UTC / local time mixed in logs)
Site: forum.rdfzer.com
Architecture: DMIT front proxy (154.17.1.193) → Discourse origin (172.93.160.202)
Uploads: Stored on Cloudflare R2 (Discourse S3-compatible), but upload requests still pass through the front proxy.
1) What happened (symptoms)
- Users (including admin) experienced:
- Pages “stuck” / incomplete styling
- Intermittent inability to enter /latest and other pages
- HTTP 429 Too Many Requests seen during normal browsing
- It looked like a login problem, but the underlying issue was broader: the site UI and JS/CSS pipeline was breaking under rate limiting.
2) Timeline (high level)
- Morning: Forum became hard to access; pages partially rendered or froze.
- During testing: Large attachment uploads were attempted from an external IP , triggering retries/refreshes.
- Storm effect: Front proxy rate limiting began throttling essential static assets (CSS/JS), causing the UI to “break” and appear unusable.
- Mitigation deployed: Static assets were exempted from the front proxy’s general rate-limit zone; .map files were disabled (404).
- Verification: Nginx config tested and reloaded; static assets returned 200; .map returned 404; rate-limit errors stopped appearing for those assets.
3) Root cause (confirmed by logs)
Primary cause
The front Nginx rate-limit (limit_req zone=forum_general) was applied to location /, so static resources (especially /stylesheets/*.css and related assets) were treated like normal dynamic traffic and got throttled.
Evidence
Front proxy error.log showed entries like:
- limiting requests, excess: … by zone “forum_general”, request: “GET /stylesheets/…css …”
When critical CSS/JS gets 429’d, Discourse pages render incomplete and users perceive it as “can’t log in / can’t enter the forum”.
Trigger
Large upload attempts (and user retries/refreshes) increased overall request volume. That amplified the chance that static resources got rate-limited and cascaded into widespread “broken UI”.
4) What we changed on the front proxy (DMIT)
Files involved
- /etc/nginx/sites-enabled/forum.rdfzer.com.conf (vhost)
- /etc/nginx/snippets/forum_proxy_common.conf (new)
- /etc/nginx/snippets/forum_static_allow.conf (new)
Changes made
- Backups created for the vhost config.
- Added a shared proxy header snippet (forum_proxy_common.conf) to avoid repeating long proxy blocks.
- Added a static allowlist snippet (forum_static_allow.conf) that:
- Returns 404 for *.map (e.g., common.css.map) to prevent non-essential debug map requests from contributing to storms.
- Creates a dedicated location for static directories to bypass forum_general rate limiting:
- /stylesheets
- /theme-javascripts
- /assets
- /plugins
- /fonts
- /images
- /svg-icons
- /user_avatar
- Included the static allowlist snippet early in the vhost, right after the existing SNI-based protection check.
Security note: Anti-reverse-proxy protection preserved
The existing protection to prevent others proxying the forum behind their own domain remains in place:
- Hostname check ($host) and TLS SNI check ($ssl_server_name) returning 444 if not forum.rdfzer.com.
5) Verification (post-change)
- nginx -t succeeded.
- Nginx reload succeeded.
- Test requests:
- Static CSS returned 200
- Emoji/images returned 200
- Avatar URLs returned 200
- *.map returned 404
- Front error log no longer showed limiting requests … zone “forum_general” for the static paths.
6) What’s “fixed” vs what remains
Fixed / mitigated
- The “storm” failure mode where CSS/JS gets 429’d and the forum appears broken.
- Reduced blast radius during spikes: UI-critical static resources are no longer punished by the general limiter.
Remaining constraint (known)
- The front proxy has a hard upload body limit (client_max_body_size 100m).Discourse upload settings were aligned to 100MB to avoid misleading UI prompts and repeated retries.
7) Takeaways / Recommendations
- Never rate-limit static assets the same way as dynamic routes on a front proxy for Discourse.
- Disable .map (404) at the edge unless you explicitly need sourcemaps in production.
- Keep front upload size limits aligned with Discourse site settings to prevent user retry storms.
- Keep the anti-reverse-proxy (Host/SNI 444) protection enabled to stop third-party domain proxying.
2 Likes
例行版本更新，已完成。
2 Likes