Skip to content
View in the app

A better way to browse. Learn more.

MSFN

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Error 502 Continues to Cause Issues - Please Be Patient

Featured Replies

A websitedown.org test some minutes ago produced this:

img%5D

... and that's why I used a Singapore node; in case some of you can't see the imgur image:

Mixed signals for msfn.org: Reachable in 2of 8 signals, with regional or policy differences elsewhere.

US East (IAD): Server error 502 Bad Getway
US West (SFO): Server error 502 Bad Getway
Europe (CDG): Server error 502 Bad Getway
Europe Central (FRA): Server error 502 Bad Getway
South America (Sao Paolo): Timed Out
Asia East (Tokyo): Server error 502 Bad Getway
Asia Pasific (SIN): Reachable 200 OK
Ocania (Sydney): Reachable 200 OK

In the hope it helps 😸 ...


... And now, ALL is GREEN:

img%5D

... and I, after so many hours, can again connect through my own Greek IP; I'm losing my sanity, it seems...

  • xper changed the title to Error 502 Continues to Cause Issues - Please Be Patient

@xper Is this all just server overload?

ie, the gateway errors have NOTHING to do with the visitor's IP Address, but all about the CPU Percentage at the time of the visitor's attempted visit?

4 minutes ago, NotHereToPlayGames said:

@xper Is this all just server overload?

ie, the gateway errors have NOTHING to do with the visitor's IP Address, but all about the CPU Percentage at the time of the visitor's attempted visit?

It is not entirely correct.

It's something among these. It's not a lack of memory.

The Backend Server is Down: Apache or PHP-FPM crashed or stopped running because of a configuration error or lack of memory.

Configuration Syntax Error: A leftover Cloudflare rule or file was deleted, but another configuration file is still looking for it, causing a processing failure.

A Connection Timeout: Invision Community 5 application took longer than 60 seconds to process a request (like rebuilding its Redis cache), so Nginx gave up and dropped the bridge.

Firewall Blocks: CSF firewall is misinterpreting the local communication between Nginx (Port 80) and Apache (Port 8181) as an attack and is blocking it.

cpu.png

Another "peculiarity" I want to share is that often times, while I am indeed able to load the board from my real physical location (like at this moment), I get the 502 just for the board's favicon, resulting in MSFN tabs without favicon:

img%5D

and

img%5D

Really strange, isn't it? dubbio

@xper said;

Wednesday at 02:29 AM

"Ok. I am going to delete all members with 0 posts. I was planning on cleaning up the database anyway."

That might catch some members who, say, are cataloging
bots (e.g. Google-like catalogers) who we might not mind having them sign in and transverse the topics, and perhaps there are long time members from programming companies or news organizations (...and perhaps other circumstances which we just haven't thought of).

Maybe (in the 1st instance) just try deleting;
-members with zero posts,

WHO ARE ALSO,

-members who have not signed in for n years,

WHO ARE ALSO,

-members who have never donated.

How it would be considered to determine what n year to delete back from? (shrug) ...15 years? Mmm, I seem to recall many years back (perhaps a decade?) an occurance when ALL members on MSFN had to change their password (vaguely recall it was due to a supposed exploit where USA said that global gateway or servers' routers might have been compromised? anyway,) so maybe an appropriate alternate n year determination might be that date/year that all members had to do that password change, because if the member never did do that password change then they are surely unlikely to be ever coming back nowadays... .

Addendum: Also, not specifically related to deleting zero post members, just in the spirit of that general cleanup thought, maybe if possible look at what files the forum server is constantly downloading to see if the server is wasting its time fetching say, external website emoticons or gravatars that might be better having their external URL's redirected to fetch from a copy of that file instead saved to MSFN servers' internal storage (assuming that there might be some external files that can be found that for some reason the server is not caching in server memory).

Also, in like thought, see what the largest files are that the MSFN servers' are constantly sending out, and see if those particular files can be significantly reduced in size (I'm not worried about. MSFN's forum headlining pics, but as an example I've seen other forums where the freakin' masthead picture could have had a substantially smaller file size utilized instead), so not-particularly- large size files that simply due to being constantly served/sent out might end up making a non-trivial part of the total data served per forum webpage. PNG pics can be smushed down in file size quite a bit, for instance.

Possibly this has been considered already, just trying to cover all the bases.

Cheers

Everything is sorted out regarding the bots, server configuration, and server security. Bots are blocked on 3 levels—scrapers and malicious bots alike, as well as those attempting SQL injection. Everything is working exactly as it should now.

Thanks for the advice anyway.

On 9/1/2026 at 12:04 PM, AstroSkipper said:

Here is a short catalogue of measures to tackle bot attacks, generated by AI:

Effective Anti-Bot Measures for Invision Community (IPS)

To effectively mitigate automated bot registrations and HTTP flooding

As someone who has spent time to investigate this somewhat recent issue of bot storms, none of that which was posted is relevant. These bots are not trying to register on the site, they are not the typical search engine spiders or spammers trying to post on the site. They are the result of large LLM farms from all over the world (mostly South East Asia last time I dug through an access.log) that are attempting to build their models. The legit LLM companies like xAI, Gemini, Co-Pilot, use legit tagging and follow established access rules such as robots.txt or similar. These dark LLM bots do not, and use proxies or Tor or other ways to reach a site.

They are not taking down sites by using common flood methods, aka access of ports, trying to log into the host (what fail2ban is for) or anything like that. They are viewing generated pages and using search fields. They end up taking down sites because those actions, while not triggering a flood edge, are causing connection limits and overhead on Database applications to hit their limit. Sites that heavily rely on a database application (such as a forum) go down because the db app goes down.

So far, the only ways to prevent this are to use aggressive blocking methods like Cloudflare OR tiresome manual settings. Or the absolute worst case scenario which is to set up a site to only be able to view generated pages if logged in with an account, and only show cached/static pages to guests.

2 hours ago, Tripredacus said:

These bots are not trying to register on the site

Hundrets or rather thousands of the 0-post accounts deleted recently by @xper were definitely registered automatically. The status showed "Never visited" although a real human user would visit MSFN after registration. And BTW, the 0-posts accounts are growing again. I consider a lot of them, where date and time of registration and visitation are identical, conspicuous and potentially susceptible to being used for dubious purposes. That’s why I’m not really convinced by your statement I quoted above.

Edited by AstroSkipper

I implement a two-step email validation process during sign-up, alongside manual approval (checking mail and IP for known spamers) for every new account. Server firewall also integrates five anti-spam databases to prevent malicious registrations along with IPS antispam feature.

As someone who has spent time to investigate this somewhat recent issue of bot storms, none of that which was posted is relevant. These bots are not trying to register on the site, they are not the typical search engine spiders or spammers trying to post on the site. They are the result of large LLM farms from all over the world (mostly South East Asia last time I dug through an access.log) that are attempting to build their models. The legit LLM companies like xAI, Gemini, Co-Pilot, use legit tagging and follow established access rules such as robots.txt or similar. These dark LLM bots do not, and use proxies or Tor or other ways to reach a site.

Exactly. They are primarily scraping endpoints like /profile and /discover. Lately, there has been a massive surge in automated bot traffic originating from China, causing widespread disruption.

A single bot is sending hundreds of requests per second, whereas we previously had a few thousand bots across the site. This is crashing the database and taking the website offline.

They are running a Layer 7 DDoS / Aggressive Scraping attack.
Everything is fine now, and there is no need to bring this issue up again.

Create an account or sign in to comment

Recently Browsing 0

  • No registered users viewing this page.

Account

Navigation

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.