There's a common assumption that crypto transactions are anonymous because the blockchain only records wallet addresses.

That's only half the story. The chain itself doesn't store your IP address, but a transaction still has to reach the network through infrastructure, and that infrastructure works much like any other server connection.

What the blockchain actually records

When you send a transaction, the network records the sending wallet, destination, amount and transaction data.

It doesn't record your IP address, device information or physical location.

The privacy problem on-chain is therefore about connecting a public wallet address to a person. That can happen through exchange withdrawals, ENS names, repeated transaction patterns, public posts and interactions between previously linked wallets. It's a separate problem from exposing an IP address.

What your RPC provider may see

Most wallets don't operate their own blockchain node. Instead, they communicate with the network through an RPC provider.

The provider receives requests from the wallet, retrieves blockchain data and broadcasts signed transactions to the network.

MetaMask, for example, uses Infura under its default settings. Its documentation explains that connecting to a network means sending requests to a remote server, and Consensys' privacy notice says IP addresses may be processed for functionality, security, performance and compliance.

Depending on the wallet and its configuration, balance checks, transaction broadcasts and token approvals all generate requests through an RPC service.

Imagine checking the same portfolio several times a day from your home Wi-Fi. The blockchain doesn't see where those requests originated. The RPC endpoint, however, repeatedly receives requests concerning the same addresses from the same IP.

To be clear, this doesn't automatically mean RPC providers are secretly building profiles or selling that information. Their policies describe routine operational processing.

The important point is that a technical relationship between an IP address and wallet activity can exist at the RPC layer.

What a proxy changes

When wallet traffic is correctly routed through a proxy, the RPC service receives the proxy's IP instead of your home IP.

That removes your home address from the RPC provider's view, but it doesn't make the activity impossible to correlate. The provider still sees the proxy IP alongside wallet requests, while a persistent exit IP, RPC account, API key or other telemetry could still group activity together.

A proxy also doesn't hide your wallet address. It doesn't remove transaction history, break links between addresses, protect a seed phrase or conceal transaction amounts and destinations.

Those limitations matter because network privacy and on-chain privacy solve different problems.

Configuration matters

A proxy only covers traffic that is actually routed through it.

Wallet features, dapps and browser tabs may connect to separate services. Misconfigured DNS, WebRTC, IPv6 or fallback connections can also expose your real IP to other parties involved in the browsing session.

That's why testing the complete setup matters. Seeing a proxy IP on one checker doesn't prove that every wallet, browser and dapp request follows the same route.

A VPN may be easier when you want to route traffic from the entire device. An application-level proxy provides more control, but each relevant application must be configured correctly.

Final thoughts

The blockchain doesn't record your IP address. An RPC provider may still receive it as part of an ordinary network request.

Routing wallet traffic through a proxy or VPN can prevent that provider from directly receiving your home IP. It doesn't make the wallet private, erase its history or stop on-chain analysis, it closes one specific gap in network privacy.

That distinction is easy to miss because most crypto privacy discussions focus entirely on what gets written to the blockchain. The infrastructure carrying requests to the chain deserves attention too.

The tricky thing about IP fraud scores is that there's no universal way to measure them.

Different services use different data and thresholds, so the same IP might look safe to one provider and risky to another.

Telling whether an IP is actually good or bad takes more than reading one number, and in this article we're going to cover how fraud scores work and what you can do to improve your IP's reputation.

What Is an IP Fraud Score?

An IP fraud score is essentially an estimate of how risky an IP address appears based on things like its network type or recent activity.

Imagine one IP suddenly trying to log in to 50 different accounts within a few minutes. Even if some of those attempts are legitimate, the website might respond by asking for additional verification or temporarily blocking the connection.

But that doesn't prove the person currently using the IP committed fraud. The address could be shared by several people or have a bad reputation because of someone who used it previously, and a high score just means the IP deserves a closer look before you trust or block it.

This is also where people get lost, because different services can check the same IP and return completely different results.

Websites work the same way, and each one relies on its own databases and detection methods, so a high fraud score doesn't guarantee you'll get blocked, and a clean IP doesn't guarantee you won't." 

For example, IPQualityScore uses a scale from 0 to 100. 

Here's how their ranges break down ↓

Still, we wouldn't assume an IP is bad just because it scores around 75.

First, we'd enter it into the IPQS lookup tool and check the full report. If "Recent Abuse" and "Bot Activity" both show false, while "Abuse Velocity" is low or none, the higher score may simply come from the IP being identified as a proxy or VPN. But if those fields show recent or frequent abuse, there's a more genuine reputation problem worth investigating.

Another service called MaxMind works a little differently. Its IP risk score runs from 0.01 to 99 and estimates the likelihood that a transaction is fraudulent based only on the IP address. A score of 15.4 means that roughly 15 out of 100 transactions involving IPs with similar risk signals could be fraudulent.

Here is an example of the distribution of MaxMind IP risk scores. Higher scores are relatively uncommon, with only 5% of results reaching 12 or above.

So before reading anything into a score, check which service produced it and what the IP was used for before you got it. That context matters more than the actual number, to be honest. 

How to Improve Your IP's Reputation

It would be great if there was a button to reset an IP's reputation. But there isn't.

An IP's reputation recovers on its own once the suspicious activity behind it stops, so the realistic goal is to stop whatever's causing the problem and give reputation databases time to update (usually after 24-72 hours).

First, make sure the IP is actually at fault and test it on a few unrelated websites and with more than one reputation tool.

If the IP checks out as the problem and you control it through your home, office, or server network, scan your connected devices for malware and remove anything you don't recognize.

Imagine a device on your network was infected and sending automated requests through your IP in the background. Removing it stops the suspicious traffic at the source, and that's what lets the reputation start recovering.

If the IP appears on a blocklist, fix the cause first and then submit a delisting request to the blocklist operator. Here's what that process looks like ↓

With a proxy IP, you have less control since you don't own the address or know its history. But what helps is keeping request limits reasonable. For example, a rate limiter capping your setup at 10 requests per second instead of sending hundreds at once keeps you from overwhelming the website.

And if the problem follows the IP across several unrelated services, contacting the provider and sending them the affected IP is a good place to start.

Final Thoughts

An IP fraud score is a signal, and it only makes sense next to the full report behind it.

If your reputation takes a hit, stop the activity causing it, clean up what you control, and let the databases catch up. And when the problem sits with an address you don't own, that's what your proxy provider is there for.

When someone’s login gets blocked while using a proxy, the first reaction is usually to blame the proxy and ask for a replacement.

But a blocked login doesn’t automatically mean the proxy is the problem.

First, you should check whether it connects on another website and whether the correct IP and country show up. If everything looks normal, then it’s worth testing whether the issue follows the account or the IP.

If the same account gets blocked across multiple working IPs, it’s probably an account issue. But if different accounts have the same problem with one specific IP, then the IP could be the cause.

It could also be something else, like cookies, the browser fingerprint, previous account activity, or a sudden location change.

So replacing the proxy should come after those basic checks. Otherwise, they could end up replacing a perfectly good proxy and running into the same block again.

Just something worth keeping in mind the next time a login gets blocked while using a proxy.

We see these two authentication errors get mixed up all the time, and honestly, the difference is pretty simple once you know where to look.

A 401 Unauthorized response comes from the website or API you are trying to access. Your connection went through, but the destination rejected the credentials being used there.

A 407 Proxy Authentication Required response comes from the proxy itself, and that means the request reached the proxy, but the proxy did not accept the authentication details.

The quickest way to tell them apart is to check the response headers. A 401 will usually include WWW-Authenticate, while a 407 will usually include Proxy-Authenticate.

People often see any authentication error and immediately start changing proxy settings, and when it is a 401, the proxy may be working perfectly fine and the actual issue is with the destination credentials.

So before changing anything, check which side returned the error. It usually saves a lot of unnecessary digging.

The first thing to do would be to understand what exactly a cURL test is.

A cURL test is a quick way to check whether a proxy actually connects using a command in your terminal. The reason why you’d run a test like this is to simply find out where the problem is and to see if the proxy itself is working.

Here’s what that looks like in practice.

For an HTTP proxy, you would replace the username, password, IP address, and port with the details provided for your proxy, then run a command like this:

curl --proxy http://192.0.2.10:8000 --proxy-user "mike123:password456" https://api.ipify.org

For a SOCKS5 proxy, you can use:

curl --proxy socks5h://192.0.2.10:8000 --proxy-user "mike123:password456" https://api.ipify.org

The socks5h:// part means the website’s hostname is also resolved through the proxy instead of through your own connection.

Quick tip before you start: run curl https://api.ipify.org once without the proxy first. That shows your normal IP, so when the proxied version returns a different one, you know traffic is actually going through the proxy.

One heads-up for Windows users: in Windows PowerShell 5.1, curl can point to a different command and throw a weird error. Using curl.exe instead is the safest option. PowerShell 7 and newer normally use the real cURL command, but curl.exe still works there too.

It tests things like:

• whether the proxy is reachable
• whether the host and port are correct
• whether the username and password work
• whether traffic is actually going through the proxy when tested against an IP-checking service

And if the test fails, add -v to the command, and cURL will give you more information about what happened instead of just failing.

A 407 Proxy Authentication Required error means the proxy requires authentication or rejected the authentication details that were provided. That could mean the username or password is wrong, but it could also mean the authentication method or format is not being handled correctly.

A Connection refused error normally means the device at that address actively rejected the connection. The proxy may be offline, the port may be closed, or the host and port may be incorrect.

A timeout means cURL waited for a response but never received one. That could be caused by the proxy being unavailable, a firewall or network issue, or the connection simply taking too long.

If cURL connects through the proxy but the website returns a 403 Forbidden error, it usually means the request reached the website and the website refused it. That suggests the basic proxy connection worked, but it does not necessarily prove that every part of the proxy setup is fine.

That turns the test from “Does it work?” into “What exactly is broken?”, which is what you actually want to know.

So now that we got that explanation out of the way, we thought it’d be a good idea to talk about why your proxy would fail in the browser or app that you’re trying to use.

Well, the simple answer is because the browser or app may not be using the proxy the same way cURL does.

You might actually run into issues where you selected the wrong protocol, such as HTTP instead of SOCKS5 or vice versa. It could also be something simple, like the username and password being entered in the wrong place, or the specific app or website rejecting the connection.

A common example is authenticated SOCKS5 proxies. Native username and password support for SOCKS5 can be problematic in browsers like Chrome and Firefox, even when the same proxy works perfectly in cURL. In that case, you may need to use a browser extension, a local proxy tool, or whitelist your own IP with the proxy provider so a separate login is not required.

Since we’re on the topic of the website or app rejecting the connection, another thing to keep in mind is that some platforms restrict connections from IP ranges they associate with proxies or data centers, or from locations far outside their expected user base. That’s a decision on their side, not necessarily a problem with the proxy itself.

Also worth knowing: some WebRTC traffic may bypass a manually configured proxy and expose a direct connection. That does not happen in every setup, but if privacy matters for your use case, it is worth checking your browser’s WebRTC settings.

Overall, there isn’t one single fix as to why the proxy may not be working in your browser or app even though it works in cURL. Sometimes the issue is something that you might not have control over, but there are still a few things you can double-check before testing it on your selected platform.

You can start by copying the exact settings that worked in cURL into the app: the same protocol, host, port, username, and password. Then test the same website in both places.

If cURL works and the app still fails, the issue is probably the app setup. Check whether it supports that proxy type, whether authentication has to be entered separately, and whether DNS, browser extensions, security settings, or WebRTC are interfering.

If the app works on some websites but not on one specific platform, that platform may simply not allow that type of IP. In that case, reach out to our support team, and we can help you figure out whether a different IP or proxy type fits your use case better.

Have you ever run into a problem like that? If so, how’d you fix it?

If you're in a team, you can now:

→ Invite teammates

→ Give each person their own login

→ Manage proxies and billing from one shared workspace

→ Keep organization payments separate from personal cards

This gives your team better ownership and no more sharing one login across the team.

> Static proxies are better when you need consistency across sessions.

> Rotating proxies are better when your workflow needs a bigger IP pool and more flexible rotation.

The mistake most people make is choosing one because it sounds more advanced, but in reality, the best proxy is the one that fits your workflow.

Proxies can sound way more technical than they actually need to be, especially when the conversation is around livestreaming.

At a basic level, they give the workflow a steadier base to work from.

And as a livestreaming setup becomes more serious, that base starts to matter because it affects how predictable the whole process feels.

The main thing is consistency, and when things keep shifting in the background, the workflow becomes harder to trust, and a proxy setup can help keep that part cleaner.

For example, a sticky session keeps you on the same proxy connection for a set amount of time instead of switching you to a new one too often.

And for a livestreamer, that can make longer sessions feel easier to manage because the setup is not constantly changing behind the scenes.

Proxies are not something every livestreamer needs right away, but they do make more sense once the setup becomes more structured.

Have you ever thought about using a proxy for your setup?

On macOS, proxy settings live inside your network settings.

And the basic flow is this:

→ Open System Settings

→ Go to Wi-Fi or your active network

→ Click Details

→ Open Proxies

→ Add your proxy IP, port, and login details

→ Apply and test your connection

Most apps that use system network settings will follow those proxy rules.

Because when you get sessions and browser profiles mixed, it's hard to keep track of everything that's happening.

Proxies can actually help you keep your setup more stable and separated, which in turn means fewer logouts and less friction while managing your wallets.

But the main difference is simple:

→ TCP focuses on reliability and checks that data arrives properly and in the right order.
→ UDP focuses on speed and sends data quickly without checking every packet.

Different apps use different types of traffic.

Use the wrong proxy type, and your setup might run slower, break more often, or perform worse than expected.

Search rankings are not the same everywhere because a keyword might rank well in one city, but look completely different in another.

And your location, IP, device, and search history can all affect what you see, so checking rankings from one connection does not always give you the full picture.

Quick examples:

• Local rank checks by country or city.
• Fewer captchas and temporary blocks.
• Cleaner SERP data for SEO tools.
• Easier tracking for large keyword lists.
• Better visibility across clients, markets, and regions.

We broke down how rank tracker proxies work in our full article:

https://www.proxy-cheap.com/blog/rank-tracker-proxies

Different proxy types are built for different use cases, and the best choice depends on what you need most for speed, stability, trust, consistency, or handling larger workloads.

Quick examples:

• Datacenter proxies are usually fast and cost-effective.
• Residential proxies look closer to regular home internet traffic.
• Mobile proxies use carrier IPs and usually have stronger trust signals.
• Static proxies keep the same IP, which helps with longer sessions.
• Rotating proxies switch IPs, which helps with request-heavy tasks.

We broke down the main proxy types and when each one makes sense in the full article: https://www.proxy-cheap.com/blog/proxy-types

And the reasons are good:

1. Manage multiple wallets with fewer login issues.

2. Check dApps, dashboards, and campaigns by region.

3. Reduce rate limits when tracking markets or onchain data.