r/Proxy_Cheap

▲ 4 r/Proxy_Cheap+3 crossposts

How to find your public and local IP address (on all platforms)

Figured it'd be useful to share some basics for anyone just getting into proxies. Starting with the simplest one, finding your IP.

Public IP is easy. Search "what is my IP" on Google and it shows up right at the top.

Local IP depends on the device.

  • Windows: run `ipconfig` in Command Prompt
  • macOS: System Settings > Network > your active connection
  • iPhone: Settings > Wi-Fi > tap the info icon next to your network
  • Android: Wi-Fi settings > gear icon next to the connected network

The quick difference between the two is that your public IP is your network as the internet sees it; the local IP is one device inside it. You'll run into both when setting up a printer, remote access, or troubleshooting a connection.

Hope that helps!

reddit.com
u/MikeProxyCheap — 3 days ago
▲ 11 r/Proxy_Cheap+5 crossposts

Screen scraping vs. web scraping: when you actually need OCR

The tricky thing with screen scraping is that most people reach for it when they don't need it.

The difference

Web scraping reads a page's HTML or an API. The data arrives already structured, tags and values you can grab directly. Screen scraping reads what's rendered on screen, so the data arrives as pixels and you need OCR to turn it back into text.

https://preview.redd.it/ovo6pbl07zih1.png?width=903&format=png&auto=webp&s=9fe453509e0405de1b4051afc1392b7d5a4458fe

Why the extra step matters

More stages means more places for things to break, and OCR errors are sneaky. In a quick test with Tesseract, clean text read at 100% accuracy, but a slightly low-res capture hit 96% and still flipped a price from 1299.00 to 2299.00. A blurry one turned a 4.6 rating into 46. The headline accuracy looks fine while single digits quietly corrupt your dataset.

When to actually use it

If the data exists in the HTML or an API, parse that. Screen scraping is for when it genuinely only exists visually, like prices rendered as images, embedded charts, scanned PDFs, or legacy terminal systems with no API at all.

If you do go the OCR route

Capture tight regions instead of full pages. If the number you need sits in one panel, screenshot that panel. Less noise means cleaner OCR output, and small layout changes elsewhere won't break your job.

https://preview.redd.it/m7zo8tj17zih1.png?width=970&format=png&auto=webp&s=08c196ae71b80971a0fc1368691f3b9ec11c6337

Validate output against expected formats, especially numbers. Don't trust raw OCR text for anything that ends up in a dataset.

For JS-heavy pages, render in a headless browser first, then capture. A plain HTTP request to a single-page app returns an empty shell.

One last thing

Budget for maintenance. A code-level parser breaks when the markup changes, a screen scraper breaks when the layout changes, and layouts change more often.

Curious if anyone here has run OCR pipelines at scale, and how you handle validation for numeric fields.

reddit.com
u/MikeProxyCheap — 8 days ago