DEV Community: Billy

The Cheapest Dedicated Servers in 2026: A Price-Checked Shortlist

Billy — Mon, 06 Jul 2026 11:28:16 +0000

If you have ever tried to price a bare-metal server, you know the game: a big "from $X/mo" on the landing page, then the actually-orderable configs cost two or three times that, half of them are out of stock, and the cheap one ships "in 3–5 business days." This is a price-checked shortlist of where to rent a genuinely cheap dedicated server in 2026 — who each provider is for, roughly where pricing starts, and the catch.

I pulled the numbers for the last entry from a live, daily-refreshed dataset (linked at the bottom) so you can verify them instead of trusting a screenshot.

What "cheap" should actually mean

Before the list, four things that separate a real deal from bait:

The price you see is the price you pay. Watch for setup/install fees and "from" pricing that no in-stock config matches.
In stock now, not "provisioning in 5 days." A $16 box you can't deploy today isn't a $16 box.
Bandwidth and traffic caps. Unmetered 1 Gbps and a 30 TB cap are very different economics.
Location. A server two continents from your users is cheap and useless.

The shortlist

1. Kimsufi (OVH budget brand) — legacy boxes, rock-bottom

OVH's budget label recycles older Atom/Xeon hardware at the lowest headline prices in the market. Great for a cheap always-on box, a seedbox, or a lab. Catch: stock is famously thin, hardware is old, and support is minimal.

2. Scaleway Dedibox — cheap French metal

Long-running budget bare-metal out of Paris/Amsterdam, entry configs among the cheapest in the EU. Good if you specifically want France/NL and Scaleway's ecosystem. Catch: entry SKUs sell out and the cheapest tiers use aging CPUs.

3. Hetzner (server auction) — best price/performance in the EU

Not the lowest sticker, but the auction floor gets you modern Ryzen/EPYC with lots of RAM for what budget hosts charge for an Atom. The default answer for "cheap and fast" in Germany/Finland. Catch: auction inventory rotates, and it's EU-only locations.

4. Contabo — cheap high-spec, oversubscribed

Known for a lot of cores/RAM/disk per dollar. Fine for storage or batch workloads where you don't need guaranteed peak performance. Catch: reputation for oversubscription and variable I/O; read recent reviews for your region.

5. Leaseweb / enterprise carriers — not cheap, but predictable

When uptime SLAs and DDoS protection matter more than the invoice, the enterprise carriers start higher but deliver consistency. Catch: you'll pay for it, and it's overkill for a hobby box.

6. Valebyte — cheap and in-stock across 20 countries

Aggregates in-stock bare-metal across a wide provider network, so the differentiator is breadth + honesty: ~800 servers deployable now across 20 countries, prices are final (no "from $X" bait), and the whole catalog is published as a machine-readable dataset. Entry is $16/mo (Atom-class in France/NL), with modern Ryzen from ~$72 and EPYC from ~$160. Catch: it's an aggregator, so the cheapest tiers are still older CPUs — same as everyone else at $16.

Cheapest by region (live figures)

Where the boxes actually are and what the cheapest one costs, at the time of writing:

Region	In stock	Cheapest
France	241	$16/mo
Netherlands	120	$16/mo
Germany	87	$59/mo
United States	80	$41/mo
Poland	63	$54/mo
Singapore	29	$42/mo
Canada	28	$40/mo
Australia	18	$40/mo

France and the Netherlands are where the floor is; if you don't need a specific country, that's where the cheapest usable metal lives in 2026.

How to actually verify prices

The single most useful habit: check a machine-readable price list instead of marketing pages. The regional numbers above come from an open dataset that refreshes daily — dedicated-server-prices on GitHub — with CSV/JSON of specs, location, monthly price and order URL for every in-stock server. Clone it, sort by price, done. No "from $X," no stale screenshots.

Bottom line

Lowest sticker, don't care about hardware age → Kimsufi / Scaleway Dedibox.
Cheap and fast in the EU → Hetzner auction.
Lots of cores/RAM per dollar → Contabo.
SLA and DDoS matter more than price → Leaseweb.
Cheap, in-stock now, specific country → Valebyte.

Whatever you pick, sort by in-stock final price in your region — not the number on the hero banner.

Bypassing Telegram Blocks: How MTProto FakeTLS Proxies Actually Work

Billy — Sat, 04 Jul 2026 12:48:41 +0000

When an ISP or national firewall throttles or blocks Telegram, the usual advice is "use a VPN." But there's a lighter, Telegram-specific tool that is often more resilient and far simpler for end users: the MTProto proxy with FakeTLS.

DPI vs. Telegram

Deep Packet Inspection classifies traffic by its protocol fingerprint. A plain MTProto stream or a naive proxy is easy to spot and drop. The trick is to make the connection look like something completely ordinary.

How FakeTLS works

MTProto is Telegram's own transport protocol. FakeTLS wraps it so the wire looks like a normal TLS 1.3 handshake to a real website:

The client sends a TLS ClientHello with the SNI of a popular domain (e.g. www.microsoft.com).
Authentication is a per-user secret verified via an HMAC computed over the ClientHello (with the 32-byte random field acting as the digest).
If the HMAC is invalid (a censor's active probe), the proxy transparently proxies the prober to the real fronting domain — so an attacker who pokes the port just gets Microsoft's real certificate back.

To a censor, a real client's flow is indistinguishable from an HTTPS visit to that domain. That's what keeps it working where generic proxies are already blocked.

A failure mode nobody documents: clock skew

Here's a real-world gotcha we hit in production. FakeTLS embeds a timestamp for anti-replay. If the proxy host's clock drifts more than a couple of minutes, every legitimate client handshake is rejected:

invalid faketls client hello: incorrect timestamp. got=..., now=..., diff=2m54s

The nasty part: the proxy still accepts TCP, still answers TLS, still passes an openssl s_client masquerade check — it looks perfectly alive. It just silently falls back to domain-fronting instead of relaying, so every user on that host is broken at once. The fix is boring but essential: run NTP (chrony) on every proxy host. We shipped a box without it and spent an afternoon chasing "the proxy is down" tickets that were really a 3-minute clock drift.

MTProto proxy vs VPN

	MTProto proxy	VPN
Scope	Telegram only	whole device
Setup	one tap on a link	install + configure
Detectability	masked as TLS	often fingerprinted
Battery/speed	negligible / fast	heavier

For unblocking Telegram specifically, MTProto is usually the better tool.

Try it

Notes + setup (open): https://github.com/blureshot/free-telegram-proxy
A free, working MTProto proxy (24h, no signup, one-tap): https://t.me/NotifyGproxyBot?start=devto

Full disclosure: that bot is the free tier of a proxy service I work on (GProxy). But the mechanics above are protocol-level and vendor-neutral — any FakeTLS MTProto proxy (mtg, mtprotoproxy) works the same way, and the clock-skew lesson applies to all of them.

A free proxy list that's actually checked (HTTP/SOCKS4/SOCKS5, updated every 30 min)

Billy — Sat, 04 Jul 2026 10:38:33 +0000

Every "free proxy list" you find is the same story: a giant wall of ip:port lines, 90% of them already dead, no idea which are HTTP or SOCKS, no idea where they exit. You paste 500 into your scraper and three of them work.

So I put up a small one that's actually checked: gproxynet/free-proxy-list. A checker validates each proxy, tags it with protocol, country and latency, and the repo is regenerated every 30 minutes. It's a rotating sample, not a 50k dump — the point is that what's in it was alive minutes ago, not last month.

Grab it

Plain text, one ip:port per line, split by protocol:

curl -s https://raw.githubusercontent.com/gproxynet/free-proxy-list/main/all.txt
curl -s https://raw.githubusercontent.com/gproxynet/free-proxy-list/main/socks5.txt

Or the structured version with protocol, country and latency:

curl -s https://raw.githubusercontent.com/gproxynet/free-proxy-list/main/proxies.json

[
  {"proxy":"103.156.224.66:8080","protocol":"http","country":"ID","latency_ms":4225,"checked_at":"2026-07-04T09:34:16Z"},
  {"proxy":"185.26.180.180:80","protocol":"http","country":"NL","latency_ms":340,"checked_at":"2026-07-04T09:41:02Z"}
]

Use it in Python

Filter to the protocol and speed you want:

import requests

proxies = requests.get(
    "https://raw.githubusercontent.com/gproxynet/free-proxy-list/main/proxies.json"
).json()

fast_socks5 = [
    p["proxy"] for p in proxies
    if p["protocol"] == "socks5" and (p["latency_ms"] or 9999) < 2000
]
print(len(fast_socks5), "fast SOCKS5 proxies")

If you're rotating them across a scraper, feed the list straight into a pool. I use proxyspin (a small rotating pool with health tracking + ban detection), which can load a URL directly:

from proxyspin import ProxyPool
from proxyspin.requests_adapter import RotatingSession

pool = ProxyPool.from_url("https://raw.githubusercontent.com/gproxynet/free-proxy-list/main/all.txt")
session = RotatingSession(pool)          # dead ones get benched automatically
print(session.get("https://httpbin.org/ip").json())

The honest part

These are public proxies. They're shared by strangers, they're slow, they die within minutes to hours, and you should never send anything sensitive through them. A checked list saves you the "which of these 500 is alive" step — it does not make public proxies reliable. They're great for testing, learning, one-off checks and throwaway requests.

The moment you need proxies that stay up — real scraping, account work, ad verification — you'll want dedicated ones (residential, mobile or datacenter) instead of public ones. But if a free, checked, auto-updating list is what you need today, it's there:

➡️ github.com/gproxynet/free-proxy-list

Bookmark the raw URL, poll it every so often, and you've always got a fresh handful to work with.

Rotating proxies for Scrapy, Playwright and requests — one small library

Billy — Sat, 04 Jul 2026 10:28:29 +0000

If you scrape anything at scale, you know the drill: proxies die, sites start returning 403/429, and your run grinds to a halt. The classic Scrapy answer, scrapy-rotating-proxies, hasn't seen a real update in years — and it's Scrapy-only, so the moment you reach for Playwright or plain requests, you're rebuilding rotation from scratch.

I wanted one small proxy pool I could share across all three. So I wrote proxyspin: a rotating pool with health tracking, ban detection and sticky sessions, and thin adapters for Scrapy, Playwright and requests. Zero required dependencies, pure standard library.

pip install proxyspin

The pool

Everything is built around one object. Load proxies from a list, a file, or a URL:

from proxyspin import ProxyPool

pool = ProxyPool.from_file("proxies.txt", strategy="round_robin")
# or inline / from your provider's export endpoint:
pool = ProxyPool(["http://user:pass@gate1.example.com:8000", "10.0.0.2:8000"])
pool = ProxyPool.from_url("https://example.com/api/my-list.txt")

proxy = pool.get()        # -> Proxy; proxy.url is ready to use
pool.mark_failed(proxy)   # bench it after repeated failures
pool.mark_ok(proxy)       # reset its failure streak

It parses every common list format — host:port, host:port:user:pass, user:pass@host:port, scheme://user:pass@host:port — for HTTP, HTTPS, SOCKS4 and SOCKS5.

Rotation strategies

round_robin — cycle through healthy proxies in order (default)
random — pick one at random
sticky — keep returning the same proxy for a given key (a target domain, an account id, a worker name) until it goes unhealthy

The health model

Every proxy starts healthy. mark_failed bumps its failure streak; when the streak hits max_failures (default 2) the proxy is benched with exponential backoff (cooldown * 2**overshoot, base 60s, capped at 1h), then automatically rejoins rotation. mark_ok resets the streak. So dead proxies quietly drop out and recover on their own — you never manually prune the list.

Scrapy

Enable the middleware and point it at your proxies. Ban detection and retry-through-the-next-proxy are automatic:

# settings.py
DOWNLOADER_MIDDLEWARES = {
    "proxyspin.scrapy_middleware.ProxySpinMiddleware": 610,
}
PROXYSPIN_FILE = "proxies.txt"
PROXYSPIN_STRATEGY = "sticky"       # one proxy per target host
PROXYSPIN_BAN_CODES = [403, 429]    # these responses rotate the proxy
PROXYSPIN_MAX_RETRIES = 3

Any 403/429 (configurable) marks the proxy as failed and retries the request through the next healthy one. No spider code changes.

Playwright

Playwright takes a proxy per browser context, which is the natural rotation unit — great for one-IP-per-account flows:

from playwright.sync_api import sync_playwright
from proxyspin import ProxyPool
from proxyspin.playwright_helper import proxy_settings

pool = ProxyPool.from_file("proxies.txt", strategy="sticky")

with sync_playwright() as p:
    browser = p.chromium.launch()
    for account in accounts:
        context = browser.new_context(proxy=proxy_settings(pool, key=account.id))
        # each account keeps its own IP for the whole session

requests

A drop-in Session that rotates on every call and retries failures through another proxy:

from proxyspin import ProxyPool
from proxyspin.requests_adapter import RotatingSession

session = RotatingSession(ProxyPool.from_file("proxies.txt"))
print(session.get("https://httpbin.org/ip").json())   # new IP per call

Check a list first

Bad proxies waste run time. The bundled CLI tests a whole list concurrently and writes out the survivors:

proxyspin check proxies.txt --workers 100 --alive-out alive.txt

OK   45.155.10.4:8000        612 ms  HTTP 200
DEAD 91.10.77.2:3128                 TimeoutError
...
118/200 alive
wrote 118 proxies to alive.txt

Getting proxies to test with

Want to try it right now without your own proxies? Bootstrap straight from a live public list:

pool = ProxyPool.from_url("https://raw.githubusercontent.com/gproxynet/free-proxy-list/main/all.txt")

Fair warning: public proxies are unreliable by nature — they're shared, slow, and die within minutes. They're fine for kicking the tires, not for a real crawl. For production you'll want dedicated proxies (residential/mobile/datacenter); a pool of one gateway entry per endpoint is all proxyspin needs since rotation happens server-side.

Wrapping up

One pool, the same health model everywhere, and you stop babysitting dead proxies. The code is MIT-licensed and on GitHub — issues and PRs welcome. If you've been limping along on an unmaintained rotation middleware, give it a spin.

Finding Exposed Services (and Fixing Them) with ScanSearch and Python

Billy — Sat, 04 Jul 2026 04:00:19 +0000

Ever wondered what parts of your infrastructure are inadvertently exposed to the internet? Or maybe you're trying to debug a network service that just isn't behaving as expected, and you suspect a firewall issue or misconfiguration somewhere upstream. Manually scanning IP ranges can be tedious and slow, especially if you're dealing with a dynamic environment.

This article will walk you through a practical approach to quickly identify internet-facing services and potential vulnerabilities using ScanSearch, an internet-wide search engine for network devices and services, combined with a bit of Python to automate and interpret the results. The goal isn't to hack anything, but to gain insight into your own network's perimeter and improve its security posture.

The Problem: What's Visible?

It's surprisingly easy to accidentally expose services that shouldn't be public. A developer might spin up a test database, forget to configure its firewall rules, and suddenly it's reachable from anywhere. Or a misconfigured router might forward ports intended for internal use. These oversights create attack vectors that bad actors actively scan for.

Instead of waiting for a security incident, let's proactively find what's visible.

Introducing ScanSearch

ScanSearch is a powerful tool for discovering network devices, services, and even vulnerabilities across the internet. Think of it like Google, but for network ports and banners. You can query it for specific port numbers, service banners, protocols, and more.

For instance, if you want to find all devices exposing port 22 (SSH), you can simply search for port:22 on their website. The real power, however, comes from combining these queries and using their API for programmatic access.

Scenario: Finding Unexpected SSH Exposure

Let's say you manage a set of servers and want to ensure that only specific, hardened SSH servers are exposed to the public internet. You want to quickly check if any other devices within your known IP ranges are also inadvertently exposing SSH.

We'll use ScanSearch to query for devices running SSH on port 22, filtered by a specific IP range (e.g., your organization's public IP block). For this example, let's assume your organization uses the fictional IP range 192.0.2.0/24.

Step 1: Manual Query (for exploration)

Before diving into code, it's often helpful to test your query directly on the ScanSearch website. Go to the site and try searching for:

port:22 ip:192.0.2.0/24

This query tells ScanSearch to look for devices with port 22 open and that fall within the 192.0.2.0/24 IP range. You'll get a list of results, each showing the IP, port, and often a service banner (e.g., SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.3).

Step 2: Automating with Python

Manually checking results is fine for a one-off, but for regular auditing or more complex analysis, an API is essential. ScanSearch offers an API that allows you to programmatically submit queries and retrieve results. (Note: You'll typically need an API key for programmatic access beyond basic public queries. Refer to the ScanSearch documentation for details on API usage and authentication).

Here's a simple Python script to query ScanSearch for exposed SSH services within our example IP range and print the results.

import requests
import json

# Replace with your actual ScanSearch API endpoint and API key
# For simplicity, we'll use a placeholder URL here. 
# Check ScanSearch documentation for the correct API endpoint and authentication.
SCANSEARCH_API_URL = "https://api.scansearch.net/v1/search" 
# SCANSEARCH_API_KEY = "YOUR_API_KEY_HERE" # Uncomment and set if required by API

def search_scansearch(query, ip_range):
    full_query = f"port:22 {query} ip:{ip_range}"
    print(f"Executing ScanSearch query: {full_query}")

    headers = {
        "Content-Type": "application/json",
        # "Authorization": f"Bearer {SCANSEARCH_API_KEY}" # Uncomment if using API key
    }

    payload = {
        "query": full_query,
        "limit": 100 # Adjust limit as needed, check API docs for max
    }

    try:
        response = requests.post(SCANSEARCH_API_URL, headers=headers, data=json.dumps(payload))
        response.raise_for_status() # Raise an exception for HTTP errors

        results = response.json()
        return results
    except requests.exceptions.RequestException as e:
        print(f"Error querying ScanSearch API: {e}")
        return None

if __name__ == "__main__":
    target_ip_range = "192.0.2.0/24" # Replace with your actual public IP range

    # We're specifically looking for SSH on port 22, so the initial query is simple.
    # You could expand this to include specific SSH versions, e.g., 'ssh-2.0-openssh'
    query_string = ""

    search_results = search_scansearch(query_string, target_ip_range)

    if search_results and search_results.get("data"):
        print(f"\nFound {len(search_results['data'])} potential SSH exposures in {target_ip_range}:\n")
        for result in search_results['data']:
            ip = result.get("ip")
            port = result.get("port")
            service_banner = result.get("banner", "N/A")

            print(f"  IP: {ip}, Port: {port}, Banner: {service_banner}")

        # Further analysis: Check if these IPs are expected or unexpected
        # For example, maintain a whitelist of allowed SSH servers.
        expected_ssh_servers = ["192.0.2.10", "192.0.2.20"]
        print("\n--- Analysis ---")
        for result in search_results['data']:
            ip = result.get("ip")
            if ip not in expected_ssh_servers:
                print(f"  WARNING: Unexpected SSH exposure on {ip} (Port: {result.get('port')}, Banner: {result.get('banner', 'N/A')})")
            else:
                print(f"  INFO: Expected SSH server on {ip}")
    elif search_results:
        print(f"No SSH services found in {target_ip_range}.")
    else:
        print("Failed to retrieve ScanSearch results.")

Important Notes:

API Key: The example above shows placeholders. You will need to refer to the ScanSearch API documentation for the correct API endpoint, authentication methods (likely involving an API key), and usage limits. Set SCANSEARCH_API_KEY and uncomment the Authorization header if required.
IP Range: Replace 192.0.2.0/24 with your actual public IP address range or a specific IP address you want to monitor.
Error Handling: The script includes basic error handling for API requests. In a production scenario, you'd want more robust logging and error management.
Rate Limiting: Be mindful of API rate limits. The limit parameter helps control the number of results per query.

Interpreting Results and Taking Action

Once you run the script, you'll get a list of IPs within your specified range that have port 22 open. Your next steps depend on what you find:

Expected Services: If an IP shows up and you know it's a legitimate, hardened SSH server, that's great. Document it as part of your known infrastructure.
Unexpected Services: If an IP appears that you don't expect to have SSH exposed, this is a critical finding. Investigate immediately:
- Identify the machine: What server or device owns that IP? Who is responsible for it?
- Determine the cause: Is it a misconfigured firewall? An old test server that was never decommissioned? A rogue service?
- Remediate: Close the port, restrict access to specific trusted IPs, or remove the service if it's not needed. Ensure proper security configurations are in place (e.g., key-based authentication, disabled root login, up-to-date SSH daemon).

Beyond SSH: Finding Other Vulnerabilities

The power of ScanSearch isn't limited to just SSH. You can adapt the query_string to find a multitude of other potentially risky exposures:

Databases: port:3306 (MySQL), port:5432 (PostgreSQL), port:27017 (MongoDB) – often found with default credentials or no authentication.
Web Servers: port:80 (HTTP), port:443 (HTTPS) – look for unexpected admin panels or outdated server versions (server:nginx/1.10.3).
Remote Desktops: port:3389 (RDP) – a common target for brute-force attacks.
IoT Devices: Look for default credentials or known vulnerable device types.
Unsecured Storage: port:445 (SMB) or port:21 (FTP) with anonymous access.

By regularly scanning your external footprint with ScanSearch, you can proactively identify and mitigate risks before they become security incidents. It's a fundamental step in maintaining a robust security posture for any internet-connected infrastructure.

Stop Guessing What’s Public: Automating Attack Surface Discovery

Billy — Wed, 24 Jun 2026 04:00:19 +0000

The "Forgotten Server" Problem

Every developer has been there. You spin up a temporary staging instance to test a deployment script, or you launch a quick Redis container to debug a caching issue. You intend to tear it down in an hour, but then a Slack notification hits, a meeting starts, and that instance stays live.

Six months later, that "temporary" server is an unpatched entry point into your infrastructure.

You can't secure what you don't know exists. While internal asset trackers are great, they often miss what the outside world can actually see. This is where internet-wide search engines come in.

In this guide, we’ll look at how to use ScanSearch to programmatically audit your public-facing infrastructure and identify services you might have forgotten were exposed.

What is ScanSearch?

ScanSearch is an internet-wide search engine designed to index network devices, services, and vulnerabilities across the entire IPv4 space. Think of it as a specialized crawler that doesn't look for web content, but for open ports, SSL certificates, service banners, and misconfigurations.

For a developer or DevOps engineer, it’s a tool for External Attack Surface Management (EASM). Instead of manually running nmap against your IP ranges (which is slow and can be blocked), you query a pre-indexed database of the entire internet.

The Goal: Finding Exposed Databases

Let’s build a practical Python script. We want to find any instances associated with a specific organization or IP range that are running services they shouldn't be—specifically, we'll look for exposed database ports (like MongoDB on 27017 or Redis on 6379) that might be leaking data.

Prerequisites

To follow along, you'll need:

Python 3.x installed.
The requests library.
Access to the ScanSearch platform to retrieve your API credentials.

Writing the Audit Script

We’ll write a script that queries the ScanSearch API for a specific network range and flags any service that isn't on our "allowlist" (like 80 or 443).

import requests
import json

# Configuration
API_KEY = "YOUR_SCANSEARCH_API_KEY"
BASE_URL = "https://scansearch.net/api/v1" # Hypothetical API endpoint
TARGET_NET = "192.168.1.0/24"  # Replace with your actual public CIDR
ALLOWED_PORTS = [80, 443]

def fetch_exposed_services(net_range):
    """
    Queries ScanSearch for all indexed services in a specific CIDR.
    """
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json"
    }

    # We search for the net range using the 'net' filter
    query = f"net:{net_range}"

    try:
        response = requests.get(
            f"{BASE_URL}/search",
            params={"q": query},
            headers=headers
        )
        response.raise_for_status()
        return response.json().get('results', [])
    except Exception as e:
        print(f"Error fetching data: {e}")
        return []

def audit_infrastructure():
    print(f"--- Starting Audit for {TARGET_NET} ---")
    results = fetch_exposed_services(TARGET_NET)

    flagged_count = 0

    for entry in results:
        ip = entry.get('ip')
        port = entry.get('port')
        service = entry.get('service', 'Unknown')

        if port not in ALLOWED_PORTS:
            print(f"[!] ALERT: Unexpected service found!")
            print(f"    IP: {ip}")
            print(f"    Port: {port}")
            print(f"    Service: {service}")
            print(f"    Banner: {entry.get('banner', 'N/A')[:50]}...")
            flagged_count += 1

    if flagged_count == 0:
        print("No unexpected services found. Infrastructure looks clean.")
    else:
        print(f"Audit complete. {flagged_count} issues found.")

if __name__ == "__main__":
    audit_infrastructure()

Why This Matters

When you run the script above, ScanSearch doesn't just tell you a port is open; it gives you the banner data. If you have an Nginx server running, it will tell you the version. If you have an expired SSL certificate, it will flag it.

Common things to look for in your results:

Old Headers: Are you still running X-Powered-By: PHP/5.4? That’s a signal to attackers.
Dev Endpoints: Finding /swagger-ui.html or /_ast (Airflow) exposed to the public internet is a major risk.
Vulnerabilities: ScanSearch indexes known vulnerabilities associated with specific service versions. You can refine your search to net:1.2.3.4/24 has_vulnerability:true to prioritize your patching schedule.

Beyond Simple Port Scanning

One of the most powerful ways to use ScanSearch is to find "shadow" assets that aren't even in your known IP range. You can search by organization name or SSL certificate common names.

For example, searching for ssl.cert.subject.cn:"*.yourcompany.com" might reveal a marketing microsite hosted on a random VPS that your security team never knew existed. These are often the weakest links because they fall outside your standard patch management cycle.

Integrating into your Workflow

Security shouldn't be a one-time event. You can take the script above and:

Run it as a Cron Job: Get a weekly report of any new ports that appeared on your infrastructure.
CI/CD Integration: Add a step in your deployment pipeline to verify that a newly deployed service is visible (or invisible) as expected.
Slack Alerts: Instead of printing to the console, send a webhook to your team's security channel whenever a high-risk port (like 3389 for RDP or 22 for SSH) is detected on a production IP.

Conclusion

Visibility is the foundation of security. Tools like ScanSearch provide a "hacker's eye view" of your infrastructure, allowing you to find and fix holes before someone else does. By automating these checks, you move from reactive firefighting to a proactive security posture.

Next time you spin up a "temporary" instance, you'll know exactly when you've forgotten to turn it off.

On-demand internet scanning in Python: scan any IP, CIDR, or country with ScanSearch

Billy — Tue, 16 Jun 2026 08:05:30 +0000

Search engines like Shodan and Censys are great, but they show you an index — data collected on their schedule, which can be hours, days, or weeks old. Sometimes you don't want the last snapshot. You want to know what's open right now.

That's the gap ScanSearch fills: instead of querying a pre-built index, you trigger a real SYN + service-detection scan of a target through a REST API and get current results back in seconds. Here's how to drive it from Python.

Install

The SDK is open source (MIT). Until the PyPI release it installs straight from GitHub:

pip install git+https://github.com/ScanSearch/scansearch-python.git

Grab an API key from your dashboard at https://scansearch.net/dashboard/api-keys/ and export it — the client picks it up automatically:

export SCANSEARCH_API_KEY="your-key"

The free tier scans at 2 kpps, which is plenty to follow along.

Scan a CIDR and wait for the result

from scansearch import Client

api = Client()  # reads SCANSEARCH_API_KEY from the environment

job = api.scan(
    targets=["192.0.2.0/24"],
    ports="80,443,8080,8443",
    modules=["ports", "services"],
)

result = api.scan_wait(job["task_id"])
print(f"open ports: {result['open_ports_found']}")
print(f"services:   {result['services_found']}")

modules=["ports", "services"] means you get open ports plus service identification — banners, product/version, TLS certificate details, and JARM/JA3S fingerprints — per host/port.

Fire-and-forget for big targets

A /24 finishes fast. A whole country does not, so don't block on it — kick it off, store the task_id, and poll when you're ready:

job = api.scan(targets=["country:DE"], ports="9200")
print("task_id:", job["task_id"])

# ...later, from anywhere
print(api.scan_status(job["task_id"]))

Targets can be a single IP, a CIDR, a list of CIDRs, a domain list, or a country:<CC> code.

Turn up the speed

Scan rate is set per call (capped by your plan). Higher speed = the same job finishes sooner:

job = api.scan(
    targets=["10.0.0.0/16", "192.168.0.0/16"],
    ports="1-1024",
    modules=["ports", "services"],
    speed=1000,  # kpps
)
api.scan_wait(job["task_id"], poll_interval=10)

# changed your mind?
api.scan_stop(job["task_id"])

Handle the errors you'll actually hit

from scansearch import Client, AuthError, RateLimitError, NotFoundError, APIError

try:
    api.scan_status(99999)
except NotFoundError:
    ...                       # no such task
except RateLimitError:
    ...                       # daily quota or per-minute limit
except AuthError:
    ...                       # bad / revoked key
except APIError as e:
    print(e.status, e.body)

Prefer the shell?

Everything above has a CLI equivalent:

scansearch scan 192.0.2.0/24 --ports 80,443,8080 --modules ports,services --wait
scansearch scan country:DE --ports 9200 --speed 1000 --wait
scansearch status 1234
scansearch stop 1234

Where on-demand scanning beats an index

Bug-bounty recon — scan your in-scope CIDRs fresh and grab current open ports + banners, not last month's.
Asset discovery / shadow IT — point it at your own AS or netblocks and find what's exposed that shouldn't be.
Continuous monitoring — scan your ranges daily, diff the results, alert on new open ports.
Vulnerability triage — combine services enrichment with CVE matching to find newly exposed ssh, rdp, elasticsearch, etc.