Proxy Analysis on a bigger scale with very interesting results, good, bad and fantastic

[theusualkeysersoze]

So I have built a Multilogin headful warmup bot and during testing, I have used various proxy providers and I have some very interesting findings.

the results are… mixed. Some things are bad, some things are surprisingly protective, and it even behaves like an accidental adblocker.

Test Setup​

• Automation: MLX / Puppeteer warmups
• Session duration: 224s (~3.7 minutes)
• Tabs / Navigation: 2 tabs, 8 navigations, 110 cookies collected
• Proxy: SOCKS5, QUIC/HTTP3 disabled, WebRTC blocked
• IP Rotation: 1 rotation attempted (IP stayed the same)

===== PROXY DIAGNOSTICS REPORT =====
Session Duration: 224.5s
Total Requests: 445
Failed Requests: 769
Socket Errors: 17
Connection Drops: 52
Timeouts: 1
Blocked: 29
IP Rotations: 0
Success Rate: -72.8%
IP History: 24.45.205.31 → 24.45.205.31 → 24.45.205.31 → 24.45.205.31 → 24.45.205.31

ERROR BREAKDOWN:
26x Request failed: net::ERR_ABORTED - https://pagead2.googlesyndication.com/pagead/gen_204?id=av-js&typ
26x Request failed: net::ERR_ABORTED - https://pagead2.googlesyndication.com/pagead/gen_204?id=av-js&typ
24x Request failed: net::ERR_ABORTED - https://pagead2.googlesyndication.com/pagead/gen_204?id=av-js&typ
21x Request failed: net::ERR_ABORTED - https://pagead2.googlesyndication.com/pagead/gen_204?id=av-js&typ
21x Request failed: net::ERR_ABORTED - https://pagead2.googlesyndication.com/pagead/gen_204?id=av-js&typ
16x Request failed: net::ERR_ABORTED - https://pagead2.googlesyndication.com/pagead/gen_204?id=av-js&typ
16x Request failed: net::ERR_ABORTED - https://pagead2.googlesyndication.com/pagead/gen_204?id=av-js&typ
8x Request failed: net::ERR_ABORTED - https://1909c31e298abff981226ff475bc52cf.safeframe.googlesyndicat
6x Request failed: net::ERR_ABORTED - https://pagead2.googlesyndication.com/pagead/gen_204?id=av-js&typ
6x Request failed: net::ERR_ABORTED - https://cdn.segment.com/analytics.js/v1/null/analytics.min.js
=====================================

Looks bad at first sight, yes? I thought so too, but then I looked closer.

The Good​

Protective against Google QUIC/HTTP3 tracking:

Many net::ERR_ABORTED errors come from Google endpoints (pagead2.googlesyndication.com, Safeframe, Segment). QUIC/HTTP3 blocked at the browser layer , the requests fail without leaking your real IP(more on this later). Acts like a network-layer adblocker: tracking and ad scripts rarely load(!!!)
Sticky IP session works as intended:

IP did not rotate, providing consistent session behavior for testing or warmups
WebRTC masked to exit IP:

WebRTC still functions but reports the proxy exit IP instead of your real IP. Prevents direct IP leaks while keeping features like WebRTC intact.
Accidental adblocker effect:

• Ads barely materialize on pages
• Pages function normally, cookies are still collected
• Essentially stealthy ad/tracking blocking without a Chrome extension

The Bad​

High “failure” count partially inflated by ad/tracking retries:

Many connection drops and socket errors come from ad/tracking networks repeatedly polling after aborted requests

While the proxy is not perfectly stable, some failures are caused by aggressive retries from Google, LinkedIn, Segment, etc.

Socket errors (17) and connection drops (52) indicate some real TCP instability

Other endpoints fail inconsistently:

Some custom endpoints experienced aborted requests unrelated to QUIC. Could break warmup scripts, automation, or analytics tests

SOCKS5 vs HTTP proxy context​

If this were an HTTP proxy, the QUIC/HTTP3 aborts wouldn’t just fail, they would have leaked your real IP repeatedly.

• UDP fallback for QUIC .....direct to your real IP
• Local DNS queries..... exposed all domain requests
• HTTP headers (X-Forwarded-For, Client-IP, etc.).... handed your IP to servers
• Non-HTTP traffic bypassing the proxy ......direct connections

In short: it would have been more leaky than the Titanic, the Hindenburg, and a sieve combined. SOCKS5, by contrast, tunnels TCP at a low level, so your real IP stays safely hidden, making it far more secure.

Now if you do not understand Quic and UDP and how they behave and what they might cause, just understand the following:

• QUIC is UDP-based, so Google tries to bypass TCP/SOCKS5 proxies to maintain a low-latency connection to the client’s “real” network.
• By disabling QUIC and forcing HTTPS over TCP via the SOCKS5 proxy, those endpoints abort gracefully, because Google can’t establish the preferred UDP path.

The request fails cleanly rather than revealing your real IP, which is a very real risk with Socks5 proxies, if not done right, your real IP is out at the first request, plain as that. This discovery is interesting because this literally works like an AD blocker and it never leaks my real IP, very important , since this is an automation.

Now the proxies, all of them, clean exit IPs or not, all of them have more or less bad connectivity, some because theyre part of botnets (Spamhaus reported for CSS or XBL are botnet IPs usually) , some because the proxies randomly go offine and some because some providers lie about sticky sessions.

But if this automation would have been done with an HTTP proxy, fasten your seat belts. For people who enjoy a more extensive read:

So all the Google QUIC traffic (UDP) that is cleanly blocked would instead:

• bypass the proxy entirely
• attempt direct UDP communication
• hit Google from your real IP
• and get logged in their attestation / AdTech profiling stack(I hope yall understand the gravity of this one)

HTTP proxy - QUIC “falls back” to direct host = IP leak.

HTTP proxies leak DNS (Socks5 doesn’t if configured correctly)​

My setup currently forces DNS over the SOCKS5 tunnel, so no DNS queries hit the local resolver. If this were an HTTP proxy:

DNS resolution would occur locally, not over the proxy

All domains visited = leaked to your ISP resolver or system resolver

Many CDNs (Akamai/Cloudflare/Fastly) do geolocation on DNS (mismatch instantly detectable)

“Abort” (ERR_ABORTED) becomes​

“I tried via HTTP proxy, failed, so I retried via normal network stack.” i.e., a full fallback to direct IP.

Most browsers will do exactly that unless explicitly neutered. If your anti detect does not have that, if their support does not know what it is , they do not deserve your business.

HTTP proxies cannot tunnel encrypted non-HTTP traffic​

My setup makes dozens of requests that are NOT plain HTTP:

analytics beacons
websocket upgrade attempts
CDP probes
attestation endpoints
ad scripts sending POST beacons
tracking pixels that “upgrade” to HTTPS

HTTP proxies often silently fall back = direct leak.

SOCKS5 tunnels everything at the TCP level aka no fallback possible.

Further.....

With HTTP proxies:

Chrome bypasses for non-HTTP schemes
Internal browser subsystems route around it
Extensions ignore it
Service-workers ignore it
WebRTC doesn’t care about it

The HTTP proxy is basically optional at best, harmful at worst.

With all this in mind, what is the marketing world take away? Here’s the uncomfortable truth nobody wants to say out loud:

If your proxy layer is leaking IPs long before your anti‑detect browser even boots, you’ve already lost the game.

Marketing cookies, retargeting pixels, tracking scripts, ad exchanges, and browser‑level telemetry operate far below the surface‑layer “fingerprint” stuff everyone obsesses over. These networks are interconnected, constantly polling, retrying, and syncing signals. If your proxy is unstable or improperly configured, your real IP will be exposed before your profile fingerprint ever matters, silently linking:

• all your accounts
• all your sessions
• all your browser instances
• all your “separate identities”

And to make matters worse, you’re also feeding your proxy provider’s IPs straight into the global blacklist ecosystem. Not because of SSH brute force or spam, but because Google, Meta, Amazon, LinkedIn, and the ad-tech backbone see these IPs misbehaving ...live, IRT.

Remember that Google isn’t just “a website.” Google is the largest advertising network on the planet, the owner of Chrome, the controller of QUIC/HTTP3, and the operator of most of the tracking scripts loaded on every major website.

They absolutely know which proxy IPs you’re using and they absolutely score them.
They absolutely attach behavioral risk and reputation to them.

And we contaminate those IPs faster than proxy providers can buy or generate new ones. That’s how the pool dies. Everyone is asking which proxy provider is good instead of doing some reading, guess what, no proxy provider is good, theres only less bad aka longer sticky sessions and bigger pools with untouched IPs, you make of that what you will.

And it’s even worse when providers sell TTL 64 Android “residential” devices that are basically random IoT rubbish(half the time hacked smart fridges in , ahem, somewhere in Eastern Europe) and present them as premium mobile proxies. You're not Keyser Soze, you're riding behind a compromised washing machine owned by some elderly Russian woman who has no clue her appliance is now a “residential node” in someone’s proxy farm.

This is the real ongoing risk the community ignores.

If your proxy layer is weak, unstable, leaking QUIC/DNS/UDP, or exposing fallback requests, then the anti‑detect browser, the fingerprints, the canvas spoofing ,none of that matters. The opponent is Google and they are formidable.

That’s the marketing-world takeaway.
Ignore it at your own account farm’s funeral.

 

[theusualkeysersoze]

So you all know how the American GTP models throw a fit when anything might hurt their business model?

That is why you run a local non American GTP model or FraudGTP or something, this will give more candid feedback, like so

 

[MrWhite17]

Now I want to make the same bot for myself! I need to adapt it to the Linken Sphere API. But the topic is great, thanks for the work you've done!

 

[badhabitsdestroyer]

Wow, thanks for linking in my poll thread (here). That's a remarkable piece of knowledge, thank you a lot @theusualkeysersoze !

 

[theusualkeysersoze]

Thank you all, since this is a great opportunity to check the proxy providers promises about sticky time, here is one liar, promises 24 hours sticky time, but:

View attachment 490194

Maybe I just got unlucky and the promises time expired exactly in the middle of my session, but I have had the same happening to me on the same provider yesterday.
This makes for agreat testing tool for some purposes, if anyone wants, drop me the proxy connections strings, has to be usa , residential sticky and socks5 and the format ip/host : port:user: pass and Ill run them (Edited since ":" followed by a "p" gives an emoji)

 

[badhabitsdestroyer]

Thank you all, since this is a great opportunity to check the proxy providers promises about sticky time, here is one liar, promises 24 hours sticky time, but:

View attachment 490194

Maybe I just got unlucky and the promises time expired exactly in the middle of my session, but I have had the same happening to me on the same provider yesterday.
This makes for agreat testing tool for some purposes, if anyone wants, drop me the proxy connections strings, has to be usa , residential sticky and socks5 and the format ip/host : port:user: pass and Ill run them (Edited since ":" followed by a "p" gives an emoji)

Is it only me or the attachment isn't visible? >>"You do not have permission to view this page or perform this action."

 

[proxygo]

So I have built a Multilogin headful warmup bot and during testing, I have used various proxy providers and I have some very interesting findings.

the results are… mixed. Some things are bad, some things are surprisingly protective, and it even behaves like an accidental adblocker.

Test Setup​

• Automation: MLX / Puppeteer warmups
• Session duration: 224s (~3.7 minutes)
• Tabs / Navigation: 2 tabs, 8 navigations, 110 cookies collected
• Proxy: SOCKS5, QUIC/HTTP3 disabled, WebRTC blocked
• IP Rotation: 1 rotation attempted (IP stayed the same)

===== PROXY DIAGNOSTICS REPORT =====
Session Duration: 224.5s
Total Requests: 445
Failed Requests: 769
Socket Errors: 17
Connection Drops: 52
Timeouts: 1
Blocked: 29
IP Rotations: 0
Success Rate: -72.8%
IP History: 24.45.205.31 → 24.45.205.31 → 24.45.205.31 → 24.45.205.31 → 24.45.205.31

ERROR BREAKDOWN:
26x Request failed: net::ERR_ABORTED - https://pagead2.googlesyndication.com/pagead/gen_204?id=av-js&typ
26x Request failed: net::ERR_ABORTED - https://pagead2.googlesyndication.com/pagead/gen_204?id=av-js&typ
24x Request failed: net::ERR_ABORTED - https://pagead2.googlesyndication.com/pagead/gen_204?id=av-js&typ
21x Request failed: net::ERR_ABORTED - https://pagead2.googlesyndication.com/pagead/gen_204?id=av-js&typ
21x Request failed: net::ERR_ABORTED - https://pagead2.googlesyndication.com/pagead/gen_204?id=av-js&typ
16x Request failed: net::ERR_ABORTED - https://pagead2.googlesyndication.com/pagead/gen_204?id=av-js&typ
16x Request failed: net::ERR_ABORTED - https://pagead2.googlesyndication.com/pagead/gen_204?id=av-js&typ
8x Request failed: net::ERR_ABORTED - https://1909c31e298abff981226ff475bc52cf.safeframe.googlesyndicat
6x Request failed: net::ERR_ABORTED - https://pagead2.googlesyndication.com/pagead/gen_204?id=av-js&typ
6x Request failed: net::ERR_ABORTED - https://cdn.segment.com/analytics.js/v1/null/analytics.min.js
=====================================

Looks bad at first sight, yes? I thought so too, but then I looked closer.

The Good​

Protective against Google QUIC/HTTP3 tracking:

Many net::ERR_ABORTED errors come from Google endpoints (pagead2.googlesyndication.com, Safeframe, Segment). QUIC/HTTP3 blocked at the browser layer , the requests fail without leaking your real IP(more on this later). Acts like a network-layer adblocker: tracking and ad scripts rarely load(!!!)
Sticky IP session works as intended:

IP did not rotate, providing consistent session behavior for testing or warmups
WebRTC masked to exit IP:

WebRTC still functions but reports the proxy exit IP instead of your real IP. Prevents direct IP leaks while keeping features like WebRTC intact.
Accidental adblocker effect:

• Ads barely materialize on pages
• Pages function normally, cookies are still collected
• Essentially stealthy ad/tracking blocking without a Chrome extension

The Bad​

High “failure” count partially inflated by ad/tracking retries:

Many connection drops and socket errors come from ad/tracking networks repeatedly polling after aborted requests

While the proxy is not perfectly stable, some failures are caused by aggressive retries from Google, LinkedIn, Segment, etc.

Socket errors (17) and connection drops (52) indicate some real TCP instability

Other endpoints fail inconsistently:

Some custom endpoints experienced aborted requests unrelated to QUIC. Could break warmup scripts, automation, or analytics tests

SOCKS5 vs HTTP proxy context​

If this were an HTTP proxy, the QUIC/HTTP3 aborts wouldn’t just fail, they would have leaked your real IP repeatedly.

• UDP fallback for QUIC .....direct to your real IP
• Local DNS queries..... exposed all domain requests
• HTTP headers (X-Forwarded-For, Client-IP, etc.).... handed your IP to servers
• Non-HTTP traffic bypassing the proxy ......direct connections

In short: it would have been more leaky than the Titanic, the Hindenburg, and a sieve combined. SOCKS5, by contrast, tunnels TCP at a low level, so your real IP stays safely hidden, making it far more secure.

Now if you do not understand Quic and UDP and how they behave and what they might cause, just understand the following:

• QUIC is UDP-based, so Google tries to bypass TCP/SOCKS5 proxies to maintain a low-latency connection to the client’s “real” network.
• By disabling QUIC and forcing HTTPS over TCP via the SOCKS5 proxy, those endpoints abort gracefully, because Google can’t establish the preferred UDP path.

The request fails cleanly rather than revealing your real IP, which is a very real risk with Socks5 proxies, if not done right, your real IP is out at the first request, plain as that. This discovery is interesting because this literally works like an AD blocker and it never leaks my real IP, very important , since this is an automation.

Now the proxies, all of them, clean exit IPs or not, all of them have more or less bad connectivity, some because theyre part of botnets (Spamhaus reported for CSS or XBL are botnet IPs usually) , some because the proxies randomly go offine and some because some providers lie about sticky sessions.

But if this automation would have been done with an HTTP proxy, fasten your seat belts. For people who enjoy a more extensive read:

So all the Google QUIC traffic (UDP) that is cleanly blocked would instead:

• bypass the proxy entirely
• attempt direct UDP communication
• hit Google from your real IP
• and get logged in their attestation / AdTech profiling stack(I hope yall understand the gravity of this one)

HTTP proxy - QUIC “falls back” to direct host = IP leak.

HTTP proxies leak DNS (Socks5 doesn’t if configured correctly)​

My setup currently forces DNS over the SOCKS5 tunnel, so no DNS queries hit the local resolver. If this were an HTTP proxy:

DNS resolution would occur locally, not over the proxy

All domains visited = leaked to your ISP resolver or system resolver

Many CDNs (Akamai/Cloudflare/Fastly) do geolocation on DNS (mismatch instantly detectable)

“Abort” (ERR_ABORTED) becomes​

Most browsers will do exactly that unless explicitly neutered. If your anti detect does not have that, if their support does not know what it is , they do not deserve your business.

HTTP proxies cannot tunnel encrypted non-HTTP traffic​

My setup makes dozens of requests that are NOT plain HTTP:

analytics beacons
websocket upgrade attempts
CDP probes
attestation endpoints
ad scripts sending POST beacons
tracking pixels that “upgrade” to HTTPS

HTTP proxies often silently fall back = direct leak.

SOCKS5 tunnels everything at the TCP level aka no fallback possible.

Further.....

With HTTP proxies:

Chrome bypasses for non-HTTP schemes
Internal browser subsystems route around it
Extensions ignore it
Service-workers ignore it
WebRTC doesn’t care about it

The HTTP proxy is basically optional at best, harmful at worst.

With all this in mind, what is the marketing world take away? Here’s the uncomfortable truth nobody wants to say out loud:

If your proxy layer is leaking IPs long before your anti‑detect browser even boots, you’ve already lost the game.

Marketing cookies, retargeting pixels, tracking scripts, ad exchanges, and browser‑level telemetry operate far below the surface‑layer “fingerprint” stuff everyone obsesses over. These networks are interconnected, constantly polling, retrying, and syncing signals. If your proxy is unstable or improperly configured, your real IP will be exposed before your profile fingerprint ever matters, silently linking:

• all your accounts
• all your sessions
• all your browser instances
• all your “separate identities”

And to make matters worse, you’re also feeding your proxy provider’s IPs straight into the global blacklist ecosystem. Not because of SSH brute force or spam, but because Google, Meta, Amazon, LinkedIn, and the ad-tech backbone see these IPs misbehaving ...live, IRT.

Remember that Google isn’t just “a website.” Google is the largest advertising network on the planet, the owner of Chrome, the controller of QUIC/HTTP3, and the operator of most of the tracking scripts loaded on every major website.

They absolutely know which proxy IPs you’re using and they absolutely score them.
They absolutely attach behavioral risk and reputation to them.

And we contaminate those IPs faster than proxy providers can buy or generate new ones. That’s how the pool dies. Everyone is asking which proxy provider is good instead of doing some reading, guess what, no proxy provider is good, theres only less bad aka longer sticky sessions and bigger pools with untouched IPs, you make of that what you will.

And it’s even worse when providers sell TTL 64 Android “residential” devices that are basically random IoT rubbish(half the time hacked smart fridges in , ahem, somewhere in Eastern Europe) and present them as premium mobile proxies. You're not Keyser Soze, you're riding behind a compromised washing machine owned by some elderly Russian woman who has no clue her appliance is now a “residential node” in someone’s proxy farm.

This is the real ongoing risk the community ignores.

If your proxy layer is weak, unstable, leaking QUIC/DNS/UDP, or exposing fallback requests, then the anti‑detect browser, the fingerprints, the canvas spoofing ,none of that matters. The opponent is Google and they are formidable.

That’s the marketing-world takeaway.
Ignore it at your own account farm’s funeral.

great insite and info well done

 

[theusualkeysersoze]

Is it only me or the attachment isn't visible? >>"You do not have permission to view this page or perform this action."

Same for me maybe the mods can fix this, I do not have the screenshot any more, it was showing my logs how a sticky residenital IP changed IP mid session, I will try to upload rather than paste the image if this happens on next tests.

 

[theusualkeysersoze]

great insite and info well done

Thank you, glad to hear that from a proxy seller. btw now I will upload the log summary here from a provider which held up, good stability and did not leak anything nor rotate IPs, though the session was very short.

 

[0d1n]

As far as I know - proxy providers are blocking google services (and bunch of others, simple by domain), so it's more about this and not ads/tracking I guess. And yeah, you don't want http(-s) for anything nowadays, it's just previous iteration of proxy protocol and pretty much redundant now.

 

[theusualkeysersoze]

As far as I know - proxy providers are blocking google services (and bunch of others, simple by domain), so it's more about this and not ads/tracking I guess. And yeah, you don't want http(-s) for anything nowadays, it's just previous iteration of proxy protocol and pretty much redundant now.

Ah yes, but Google can bypass that if some very specific things are not set up and then the real IP is out on first reuqest, but yes, I agree with everything else.

 

[yayayas]

Thank you, glad to hear that from a proxy seller. btw now I will upload the log summary here from a provider which held up, good stability and did not leak anything nor rotate IPs, though the session was very short.

Who is this supplier?

 

[theusualkeysersoze]

Who is this supplier?

Well, the forum rules, if the internal warnings I have received are to be believed, would state I cannot open my mouth about this else I am seeling outside the marketplace and such so it demands that you start a want to buy thread or something where you will be inundated by resellers who barely know how to promounce proxy, let alone know how they work at all under the hood can get a "fair shot"

 

[SettingSun77]

you will be inundated by resellers who barely know how to promounce proxy

They might be able to spell it, though.

 

[Mrnewbie]

Well, the forum rules, if the internal warnings I have received are to be believed, would state I cannot open my mouth about this else I am seeling outside the marketplace and such so it demands that you start a want to buy thread or something where you will be inundated by resellers who barely know how to promounce proxy, let alone know how they work at all under the hood can get a "fair shot"

Also, we have sellers who are around the world, and English is not their first language. That is what makes BHW so great, and as @SettingSun77 is pointing out, they might not be able to pronounce it, but they know how it works.

 

[theusualkeysersoze]

They might be able to spell it, though.

I had to laugh there myself, but you do get the point, this guy is asking for specific providers which I have tested, if I say who it is, even if I am not even affiliated, I get a warning(yes, absolutelly happened before) if I tell him as per policy to create a thread, he will have 50 unrelated replies from resellers who have not done the testing.

So, how are we serving his interest?

Do you believe the chat gtp generated offers for sticky google reviews actually provide that service? I am certain they do not, so much is evident in the comments of the threads.

So if I pay 30 usd or what it is then I can shill and resell proxies and nobody will say a word, but an independent test result cannot be published?

The proxy provider is right here on this forum anyway, how does this serve the purpose of the people asking? Who is the customer base here?

Let me smell the coffeee for a minute, ah yes, the customer here is whoever pays for jun VIP status, that is where the money comes in

 

[theusualkeysersoze]

Also, we have sellers who are around the world, and English is not their first language. That is what makes BHW so great, and as @SettingSun77 is pointing out, they might not be able to pronounce it, but they know how it works.

I will heavily object to the last bit of that statement, either they do not know or they are malicious, I have personally tested some proxy providers here and its pure junk at times, the whole proxy ecosystem is pure junk, but lets not blow sugar on reproductional organs shall we

 

[badhabitsdestroyer]

from resellers who have not done the testing.

I think it would be a good idea if you could give this testing approach to those who check marketplace offers.
So that moderators could quickly execute it on every proxy offer.
This would level up the quality of the providers.
I don't mean to refuse service from those who don't meet your criteria, but just show who pass your check and who doesn't.

I mean you could do a big good to the forum if you could think how you could approach moderators and provide easy to reproduce test set.

P.S. you're talking about quite advanced topic (internet networking) which I don't understand deeply and I'm sorry in advance if your tests can't be executed easily (which makes me look like I say nonsence).


This would reverse the approach you took of looking at this negatively:

Let me smell the coffeee for a minute, ah yes, the customer here is whoever pays for jun VIP status, that is where the money comes in

I hope I won't be misunderstood in my good intentions.

 

[theusualkeysersoze]

They might be able to spell it, though.

Oh really, let me get back at this so snarky post. I have paid 150 quid for this status, so certainly, I can say something when someone is trying to be funny on a technicality. Yes, having a bad day, but never as bad as poitning out typos.

Now, from what I see here, mods are just here to protect monetary interests, do not post things where you shouldnt if you have not paid for the jr vip status etc.

Now you go and search my contribution history, afaik I have entries in post of the week or month etc, and the general coherence and contributory value of the posts, not just having my backside kissed because mod status.

Then you go and compare that to the sellers posts and perhaps...your own? And then tell me how much gravity these few typos of mine have, in case you have not realized, I do not use gtp models to post, so yeah there will be a typo or two at times.

Let me know the brand of clown you have eaten for breakfast today and how snark falls under your moderator duties besides protecting the obvious monetary interests.

 

[badhabitsdestroyer]

Oh really, let me get back at this so snarky post. ...

Please ignore such things. There are more than enough of those who deeply admire your contributions here.
Don't set yourself up against the whole forum. It will do no good for both you and those who cherish your posts.
Of course there are b*tt load of bot posts here and low-effort, but there is still gold hidden underneath. A lot of valuable potential relationships, especially among high-stake mods and admins. Which you won't reach by choosing being negative and noticing foolish remarks to your side.
I offered you above the path that might yield a reputation bump for you (maybe relationship, as every new marketplace proxy selling post will start having your footprint of quality assurance). You got real skill, now you gotta obtain soft skills to become invincible.
I wish you the best, friend.