Unfortunately, there’s many many reasons that could be the case. I’m just putting this out there since it’s easy to check for and mitigate against.

Can’t edit the post (Thanks Cloudflare! /s) but additional info:

• I truncated the log excerpts in the post. The user agent string in these requests isn’t shown here, but it is blank in the actual logs.
• This is for Lemmy admins only. It might apply to others in some form, but this seems to be specifically exploiting a Lemmy API endpoint
• My Nginx solution may have room for improvement; I was just trying to block that behavior without breaking comments in posts and move on with my day. Suggestions for improvement are welcome.

but I send you a PM

Oh, sorry. One of the new features in this dev branch is the ability to disable PMs and mentions. I’ve been running with those turned off. Seems like that feature is working lol.

I turned DMs back on and found the message - will try to join here when I’m back on desktop. Dunno how active I can be right now, but I am eventually going to start on Piefed so would be nice to have a sounding board.

Some of the devs are already working on shared logic/libraries between apps.

Nice!

Oh, I meant just if the instance isn’t know, I thought resolving would make it “aware” of that instance. I could be wrong. But yeah, the instance would have to federate with the other one for it to be able to resolve, though. e.g. it won’t resolve an object from an instance that is on the current instance’s “block” list.

I believe you can, yeah, and I also think that “bootstraps” that instance to yours if it doesn’t already know about it. But in that case, the way I have the search written, it’ll “fall back” to regular search which also does resolveObject. That just takes longer.

The ap_id check is just to short-circuit that behavior to avoid the lengthy, often unnecessary, search and quickly redirect you to your instance’s local copy.

Have had that working for about a week now, and it’s pretty nice. Please do steal this feature lol.

At startup, it calls /api/v3/federated_instances and stores the result to a lookup variable. Then I’ve got a couple of helper functions that accept either an instance ID or a domain name which looks them up from the lookup variable.

Awesome! Win-win.

“Message” bucket is kind of a general purpose bucket that covers a lot of different endpoints. I had to ask the lemmy devs what they were back when I was adding a config section in Tesseract for the rate limits.

These may be a little out of date, but I believe they’re still largely correct:

https://nginx.org/en/docs/http/ngx_http_proxy_module.html

$proxy_add_x_forwarded_for is a built-in variable that either adds to the existing X-Forwarded-For header, if present, or adds the XFF header with the value of the built-in $remote_ip variable.

The former case would be when Nginx is behind another reverse proxy, and the latter case when Nginx is exposed directly to the client.

Assuming this Nginx is exposed directly to the clients, maybe try changing the bottom section like this to use the $remote_addr value for the XFF header. The commented one is just to make rolling back easier. Nginx will need to be reloaded after making the change, naturally.

     # Add IP forwarding headers
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header Host $host;
      # proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-For $remote_addr;

Yeah, you are setting it, but that’s assuming the variable $proxy_add_x_forwarded_for has the correct IP. But the config itself is correct. Is Nginx directly receiving traffic from the clients, or is it behind another reverse proxy?

Do you have a separate location block for /api by chance, and is the proxy_set_header directive set there, too? Unless I’m mistaken, location blocks don’t inherit that from the / location.

I replied to your other comment, but most likely cause is the API server not getting the correct client IP. If that’s not setup correctly, then it will think every request is from the reverse proxy’s IP and trigger the limit.

Unless they’re broken again. Rate limiting seems to break every few releases, but my instance was on 0.19.12 before I shut it down, and those values worked.

Not sure. I had mine set to 20 per 60 for a long time without issue.

Most likely cause would be the Lemmy API service not getting the correct client IP and seeing all API requests come from the reverse proxy’s IP.

Are you sending the client IP in the X-Forwarded-For header? Depending on how your inbound requests are routed, you may have to do that for every reverse proxy in the path.

So, a ‘Comments’ Rate limit: 10, Per second: 60, means a maximum of 10 comments per minute, correct?

Correct, per client IP.

Maybe the reason you see 99999999 is due to troubleshooting

Could be. I try not to speculate on “why” when I don’t have access to the answer lol.

I don’t recall any of them being from mander (unless they were dealt with before I started testing?), but thanks for taking preventative measures :)

I don’t know what ‘Antiyanks’ is

It’s the codename for a particular long-term troll and is based off of their original username pattern (which they still use sometimes). I have reason to believe it’s also the same troll that used to spam the racist stuff in Science Memes.

These are most of today’s batch (minus the JON333 which was just a garden-variety spammer that made it into the last screenshot).

What they lack in quality they make up for in quantity.

Wish I’d have thought of that before I started cleaning up the codebase 😆. Several releases were technically Oberth class haha.

I like it. Might just take you up on your suggestion.

All apps should sprinkle a little Trek in when they can:

Haven’t decided what I’m gonna call 1.5 series. I want to do Defiant class, but I already wasted that on the short-lived 1.3 series.

Sure. Would be willing to at least help with the riff-raff. My main alt is @ptz@dubvee.org