Scope the monitor before touching the proxy
This setup is for monitoring pages the operator is authorized to watch: public product detail pages, catalog endpoints, partner pages, and owned retail systems. The monitor records stock text, price, variant ID, HTTP status, parser output, and check time. It does not add cart, checkout, account, or payment behavior unless that work is explicitly authorized somewhere else.
Write down the target host, allowed paths, country, plan, session mode, polling ceiling, dedupe window, and stop condition before writing any code. If the release window ends at 14:30, the job needs to know that. A monitor that runs past its window wastes bandwidth and sends stale alerts.
The first setup mistake is mixing status checks with account state. A stock watcher should not inherit checkout cookies just because both jobs run near the same release window. Keep them separate. The monitor can wake a person or trigger another approved workflow, but it should not quietly become the buyer.
Pick the plan the page actually requires
Start with the cheapest pool that the target page tolerates. Datacenter works for plain public pages that do not care about the request ASN. Volume Residential at $0.89/GB is the normal first choice for broad retail release monitoring — most public product pages pass it without challenge. Premium Residential at $5.00/GB is for after logs show the cheaper path is the blocking problem, not because the SKU feels important.
Generate the proxy line in the dashboard for the funded plan and country. The pool gateway is http://proxynade.net:2555 with Proxy-Authorization username and password auth. Do not hand-edit the generated username at 03:58 because a launch page is still returning the previous state.
The expanded username carries the routing options: base user, a plan token (volume, premium, or datacenter), an optional country code, and an optional rotation lifetime in minutes. Datacenter lines skip the lifetime token. A 10-minute sticky window for a session that needs to stay on one exit looks like: rt97db6958d9-plan-volume-country-us-lifetime-10.
Plan balances are separate. A depleted Volume balance stops Volume traffic while Premium can still have credit. That sounds obvious until the alert reads "proxy down" and the only broken thing is the wallet attached to one plan.
Read Usage Logs before trusting app counters
Keep raw source and parser output beside each other in the job record, not blended together. Raw HTML shows what the retailer returned. Parser output shows what the code believed. When "sold out" changes to "notify me" or a size grid moves one div down, that separation saves the next debugging session.
App-level byte counters undercount. Failed bodies, redirect chains, blocked assets, and retry traffic all cross the proxy without surfacing in application logs. Export the Usage Logs CSV from the dashboard after a dry run and sort by host before release day. The dashboard network logs show host, outcome, latency, and byte totals per request.
Block waste domains only after seeing them in the logs. Exact domains first. Broad subdomain rules are how image hosts, required scripts, and JSON endpoints disappear. After every blocklist change, run a small sample and check for blocked outcomes before trusting the monitor again.
What the logs tell you when something breaks
| Log symptom | What it means | Next check |
|---|---|---|
| No rows for target host | Client skipped the proxy entirely | Verify the proxy is wired into the HTTP client, not just defined in config. |
| Blocked rows spike | Blocklist is catching required traffic | Audit the blocklist before blaming the retailer. |
| Byte totals jump between runs | New image CDN or third-party bundle appeared | Diff the raw source and add the domain to the allow list if needed. |
| Parser flips without a status change | Page structure changed, not route | Diff the raw HTML before changing plan or country. |
| 407 on every request | Credentials rejected at the proxy | Check username format, password, and account balance. |
Retail release monitoring FAQ
Which Proxynade plan should a retail stock monitor use? Volume Residential at $0.89/GB covers most public retail pages. Use Premium Residential at $5.00/GB only after logs show the cheaper path is the blocking problem.
How do I know the monitor is actually going through the proxy? Export the Usage Logs CSV from the dashboard and look for the target host. No rows means the client skipped the proxy.
Should the stock monitor share credentials with the checkout workflow? No. Keep them separate. A stock watcher should not inherit checkout cookies or account state from a nearby workflow.
What username format does the Proxynade pool use? The expanded username carries the base user, a plan token (volume, premium, or datacenter), an optional country code, and an optional lifetime rotation window in minutes. Example: rt97db6958d9-plan-volume-country-us-lifetime-10. Datacenter lines skip the lifetime token.
Why do app-level byte counters undercount proxy bandwidth? Failed bodies, redirect chains, blocked assets, and retry traffic cross the proxy but never surface in app-level counters. The Usage Logs CSV shows what the proxy actually transferred.
Production checks
- Monitor only pages you are authorized to watch.
- Keep the stock watcher out of checkout and account state.
- Set a polling ceiling and a stop condition before the window opens.
- Generate the proxy line in the dashboard; do not hand-edit the username.
- Export Usage Logs CSV after every dry run and sort by host.
- Audit the blocklist after every change before trusting the output.