Would you be open to offering MASQUE proxying? I started to as support to GOST, been testing with Bright Data (only for UDP sadly, not TCP), but would love to see others add support so I could test with more than just 1 vendor.
I mentioned this in a podcast recently; fingerprinting of proxy servers using QUIC is a lot harder as UDP doesnt have enough headers to allow for unique characteristics like a TCP does.
Theres no way to include a timestamp in a UDP datagram so all timestamps received would be from the client machine.
So far I've only seen Bright Data (among the large players) offer UDP proxying over QUIC/HTTP3, but that's pretty limiting since less than half of sites have HTTP/3 enabled to begin with.
BrighData offer H3/QUIC but only in beta and you have to contact their sales team as far as I'm aware.
We (PingProxies) might be the only company to offer H3 to the proxy/QUIC to the target using the CONNECT-UDP method publicly. Although, it is in beta/unstable until I merge my changes into Rust's H3 library.
If you wanna play around with it, email me and I'll get you some credit. I think theres potential for stealth since outdated proxy clients/servers mean automated actors never use H3.
The proxy industry is full of another 100 companies saying they offer H3/QUIC, when they mean UDP proxying using SOCKS. I suppose the knowledge gap and what customers care about (protocol to end target) is very different to what I care about (being right/protocol to the proxy server).
> BrighData offer H3/QUIC but only in beta and you have to contact their sales team as far as I'm aware.
That's what I thought too, but it's working for me. (I've sent a lot of tickets, maybe they've put our account as something special without telling me, but doubt it.)
> If you wanna play around with it, email me and I'll get you some credit.
Done, emailed! :) Thanks!
> The proxy industry is full of another 100 companies saying they offer H3/QUIC, when they mean UDP proxying using SOCKS.
Out of the large players I've tested, none actually seem to even support SOCKS5's UDP ASSOCIATE. (I have not tested PingProxies yet.)
> I suppose the knowledge gap and what customers care about (protocol to end target) is very different to what I care about (being right/protocol to the proxy server).
I think there's a knowledge gap between the people making the sales landing pages, and the folks who actually run/maintain the proxy servers. There's some large vendors that advertise UDP support (for residential and/or mobile proxies) that I have yet to actually see working.
I'm not sure that's correct -- the first party APIs are priced per query but BD is per 1k results. Not immediately obvious what they count as a "result" tho.
It's really poor wording. Bright Data does indeed consider 100 results in a single request to be a single billed "result" event, billed at $1.5/1000 requests.
I always set 100 results per request from Bright Data, and I can see my bill indeed says `SERP Requests: x reqs @ 1.5 $/CPM` (where `x` is the number of requests I've made, not x * 100).
For serper.dev, they consider 10 results to be 1 "credit", and 20 to 100 results to be 2 "credits". They bill at $50/50,000 credits, so it becomes $1/1000 requests if you are okay with just 10 results per request, or $2/1000 requests if you want 100 results per request.
(Both providers here scale pricing with larger volumes, just trying to compare the easiest price point for those getting started.)
https://github.com/go-gost/x/pull/75
https://github.com/go-gost/x/pull/76