Proxies come with network rules that can silently drop or reject traffic to specific ports. For related connection, target, and protocol limits, see proxy usage limits.
Why providers block ports
Providers block risky or abuse-heavy services to protect their IP pools and keep targets from banning ranges. The most common blocks are email and legacy Windows file-sharing ports, with stricter rules on shared plans.
Abuse pressure is real: open SMTP becomes a spam magnet, and SMB/NetBIOS invites brute forcing and lateral movement attempts. Blocks also help providers pass upstream datacenter AUPs and keep whole subnets from getting null-routed.
Commonly blocked and allowed ports
Most shared pools either allow only web traffic or follow a strict “safe list.” SMTP 25 is almost always blocked, NetBIOS 135–139 and SMB 445 are often filtered, and some plans allow only 80 and 443.
| Port(s) | Service / Use | Typical policy | Notes |
| 80, 443 | HTTP, HTTPS | Allowed on nearly all plans | Some providers only allow these two ports. For protocol details, see HTTP/HTTPS proxies. |
| 25 | SMTP (server to server) | Always blocked | Primary anti-spam measure. Submission usually goes via 587 or 465, which may still be blocked on shared plans. |
| 465, 587 | SMTP submission | Often blocked on shared, case-by-case on private | If mail is essential, ask support for a custom rule on a private allocation. |
| 135–139 | NetBIOS/RPC | Commonly blocked | Legacy Windows services are a frequent target of abuse scanners. |
| 445 | SMB | Commonly blocked | File sharing; many upstreams prohibit it. |
| 21 | FTP | Mixed | Increasingly restricted due to credential stuffing and scanners. |
| 22 | SSH | Often blocked | Some providers allow for private allocations; rarely open in shared pools. |
| 53/UDP | DNS | Usually blocked or proxied differently | DNS over HTTPS/TLS on 443/853 may work; raw UDP is often not available on HTTP proxies. |
| 853 | DNS over TLS | Mixed | Might pass on generic TCP, but many upstreams restrict it. |
| 123/UDP | NTP | Usually blocked | UDP amplification risk. |
| 1900/UDP | SSDP | Blocked | Reflection/amplification vector. |
Port policies vary by plan and location
Providers use three main models. Fixed whitelists allow a small set of “safe” ports, custom openings are available on private or dedicated ranges, and some datacenters impose their own lists that differ by region.
In practice, you will see:
- A global whitelist for shared pools.
- Custom openings upon request for private IPs.
- Per-datacenter or per-ISP differences that change as upstream policies change.
SOCKS5 and UDP: what is technically possible vs allowed
SOCKS5 supports UDP ASSOCIATE and can carry non-HTTP protocols, but providers still drop or throttle risky traffic at the edge. UDP-heavy protocols, including QUIC, are frequently disabled.
If your workflow needs raw UDP or QUIC, confirm support first and expect constraints. Start with the basics in SOCKS4/5 proxies and see platform specifics in UDP & QUIC Support.
How to test a port safely
A quick, targeted check beats a noisy scan. Use a single connection attempt to the destination service and compare behavior over HTTP and SOCKS.
Linux/macOS examples
# Test HTTPS on a nonstandard port via an HTTP proxy
curl -v --proxy http://USER:PASS@PROXY_HOST:PROXY_PORT https://example.com:8443/
# Plain TCP probe with timeout (requires nc)
nc -vz -w 5 -x PROXY_HOST:PROXY_PORT -X connect example.com 587
# For SOCKS5 (if your nc supports it)
nc -vz -w 5 -x PROXY_HOST:PROXY_PORT -X 5 example.com 587
Windows (PowerShell)
# When the target is HTTP(S), let the app talk via the proxy
setx HTTPS_PROXY http://USER:PASS@PROXY_HOST:PROXY_PORT
setx HTTP_PROXY http://USER:PASS@PROXY_HOST:PROXY_PORT
# Then test with curl (PowerShell's curl is Invoke-WebRequest alias on some builds)
curl https://example.com:8443/ -v
Good practice
- Test one known host and one port at a time.
- Compare results over HTTP vs SOCKS to isolate proxy-level blocks.
- Read your provider’s port table before testing.
- Do not run port scans from proxies. It triggers abuse rules and can get your IPs recycled.
Why “only 80/443” plans exist
Plans limited to 80 and 443 are easy to police, match most web automation, and reduce the blast radius if a user goes rogue. They are cheaper to operate and less likely to get blackholed by upstreams.
If you need mail or SSH, you will usually need a private allocation with a custom rule. Be ready to justify the need and accept rate limits or logging.
What to ask support
You will get faster approvals if you state the exact destination ports and hosts, why they are needed, and whether traffic is TCP or UDP. Mention the protocol and whether encryption is used.
A concise ticket template:
- Ports and protocol: e.g., TCP 587 SMTP submission to smtp.provider.com
- Volume and schedule: e.g., 100 messages per hour, 09:00–18:00 UTC
- Plan type: shared or private, required timeline
Troubleshooting checklist
A blocked port looks like instant resets, silent timeouts, or consistent connection failures that do not reproduce on your local network. Confirm the proxy plan’s rules first, then re-test with the correct proxy type.
Typical pitfalls:
- Using HTTP proxy for a non-HTTP protocol. Switch to SOCKS5 if supported.
- Expecting UDP or QUIC on a plan that only forwards TCP.
- Testing SMTP 25 on a shared plan. It is almost certainly blocked.
- Mistaking target-side firewall rules for proxy blocks. Test the same port on a known-open host.
FAQs
Is SMTP port 25 usable through proxies?
Usually no. Port 25 is almost always blocked to prevent spam. Submission ports 465 or 587 may be possible on private allocations, but many shared plans still block them.
Why do SMB and NetBIOS ports fail?
Ports 135–139 and 445 are commonly filtered due to abuse and upstream AUPs. Most providers will not open them even on request.
My plan says “web only.” What does that mean?
It typically allows 80 and 443 and may block or silently drop other ports. For HTTP(S) behavior specifics, review HTTP/HTTPS proxies.
Can SOCKS5 send UDP or QUIC?
SOCKS5 supports UDP at the protocol level, but providers often disable or drop UDP and QUIC in production. See UDP & QUIC Support for details and caveats.
How do I confirm a port is blocked without scanning?
Attempt a single connection to a known host and record the result, then compare over HTTP and SOCKS. A repeatable timeout or reset on that port, when others work, indicates a policy block.