Same fare, different result — not always a proxy problem
Same route, same date, different price is not automatically a proxy failure. Travel sites return different fares based on market, currency, language, cookies, and cached calendar state. Check those inputs first. A proxy swap that leaves the browser profile or Accept-Language header unchanged will not change the result.
Write down the real target URL used for the test, including query parameters. Advice calibrated only against echo endpoints collapses once redirect chains and regional challenge pages enter the run.
Market boundaries need separate lines
A US fare run and an EU fare run can share a parser, but they should not share a browser profile, a cookie jar, or a proxy line with no country label attached. Country routing only helps if the stored row records which market produced it.
On a Proxynade residential pool, country targeting sits in the expanded username: rt97db6958d9-plan-volume-country-de-lifetime-10 routes through a German exit for ten minutes. Generate a separate credential per market and name the run before querying at scale. The dashboard usage logs export as CSV and include host, outcome, latency, and byte totals per request — that label is what lets you audit market coverage later.
Rotation strategy depends on where in the flow you are
Rotating residential proxies make sense for independent price checks across many routes. Rotate between searches. Do not rotate mid-sequence when the flow depends on cookies — a new IP mid-session typically invalidates the session token and forces a restart from a worse position than just finishing the original request.
Once the workflow moves from search results into fare details, bag options, or a quote screen, sticky sessions become the right choice. The lifetime-<minutes> token in the Proxynade username controls the rotation window: lifetime-15 holds the same exit for fifteen minutes, which covers most multi-step fare detail flows.
| Stage | Session type | Credential token |
|---|---|---|
| Route search (independent queries) | Rotating | lifetime-1 or omit |
| Fare detail, bag options, quote | Sticky | lifetime-15 or longer |
| Per-market baseline run | Sticky per market | country-<cc>-lifetime-30 |
Bandwidth from the proxy meter is not the same as rows collected
The scraper counter records accepted rows. The proxy meter records every transferred byte: redirect chains, failed result pages, challenge pages, calendar grid scripts, images, and retries all count. A run that stores 500 fare rows may have transferred data for 2,000 requests.
Volume Residential is billed at $0.89/GB. Running the usage export from the dashboard after each market run gives the actual byte total broken down by host and outcome, which makes the bill readable and the retry budget visible.
Stored rows need enough context to reproduce
Each fare row should carry: origin, destination, travel date, passenger mix, market, currency, provider, timestamp, HTTP status code, proxy route label, provider bytes, app bytes, and kept-or-discarded state. Without that, the next audit turns into guessing — whether a price changed or the market tag drifted or a retry inflated the count.
Status codes matter. A 200 (MDN: 200 OK) that returns a captcha page looks like success at the app layer and failure at the proxy layer. Logging the response body hash alongside the status code catches that class of error without extra parsing.
Public pages versus authenticated flows
Public fare search pages operate under the site's terms of service and robot exclusion rules (RFC 9309). If the workflow moves behind a login, into a loyalty account, a checkout screen, or involves repeated captcha solving, that is a separate permission question with a different answer. The Proxynade AUP prohibits unauthorized account creation and ban evasion — the proxy keeps markets separated for public data collection, not for bypassing account controls.
Travel fare aggregation FAQ
Why do I see different fares from the same query? Market, currency, language, cookies, and cached calendar state all influence what a travel site returns. Confirm those inputs match before treating the difference as a proxy problem.
When should I use rotating vs sticky sessions for fare collection? Rotate between independent searches. Once a flow moves into fare details, bag options, or a quote screen, sticky sessions keep the identity fixed across the page sequence.
How do I set a country for a Proxynade residential line? Append country-<cc> to the expanded username, for example rt97db6958d9-plan-volume-country-de-lifetime-10. The gateway routes through an exit in that country for the duration of the lifetime window.
Why does my bandwidth bill exceed the stored row count? The proxy meter counts all transferred bytes: redirects, failed result pages, challenge pages, images, scripts, and retries. The scraper counter only records accepted rows.
What fields make a fare row reproducible? Origin, destination, travel date, passenger mix, market, currency, provider, timestamp, status code, proxy route, provider bytes, app bytes, and kept-or-discarded state.
Run checklist
- Fix origin, destination, and dates before querying.
- One credential per market; label the run in usage logs before scaling.
- Rotate between independent searches; sticky for multi-step flows.
- Export usage CSV after each market run to check byte totals.
- Store status code, proxy route, and byte counts alongside each fare row.
- Limit retries per itinerary; log the retry count.