How to Test Landing Pages Across Countries with Thunderproxy and Afina

To test a landing page across countries, select a proxy in the required country and create a separate browser profile for each test scenario. Then compare what you see with the site's display rules for that region. Thunderproxy provides the proxy connection, while Afina Browser lets you manage browser settings.

Record the browser language, cookies, login state, and selected market separately. An IP address from a specific country does not necessarily determine the page language, currency, or available offer. A similar approach applies to local market research: a website may consider both IP location and browser settings.

This guide describes a workflow for your own website or a client resource you are authorized to test. Here, QA means checking whether the page behaves according to the established requirements. A few profiles and a short checklist are enough to get started. The example below is illustrative and does not contain real measurement results.

What should a regional landing page test establish?

Regional testing helps determine whether a page follows its established rules under specific conditions. It does not mean that every visitor from a particular country will see the same result.

Start by reviewing the website owner's requirements. Should the website automatically redirect a new visitor based on country? Does it only suggest a language, or switch languages immediately? Can visitors select another market manually? Does currency depend on IP address, the selected storefront, or account settings?

Record these rules before testing. If you have not defined the expected result, a difference between two sessions remains an observation. It does not necessarily indicate a defect.

An English page served to a German IP address may be correct if the visitor previously selected English. The important point is whether that behavior matches the website requirements.

Why use Thunderproxy together with Afina Browser?

Each tool handles a different part of the test. Thunderproxy provides the network route, while Afina Browser lets you save the settings for each test in a separate profile.

Thunderproxy's residential proxy network supports location selection and rotating or sticky modes where available. This lets you check how a landing page responds to a connection from a selected country while controlling browser language and saved settings separately.

In Afina, you can create isolated profiles and attach proxy configurations to them. A separate QA profile prevents test settings from mixing with everyday browsing data. Profile isolation alone, however, does not prove that the website treats the profiles as different users.

Use both tools when you need to select the country of the exit IP and control browser settings. A proxy may not be necessary when checking a translation through the URL of a specific language version.

Follow applicable laws, platform rules, account owner permissions, and testing limits. A proxy changes traffic routing, but it does not expand access rights or guarantee that a website will accept a request.

Which settings can change the landing page you see?

IP location, browser language, and saved website settings can all affect the landing page. A website may prioritize these factors differently.

MDN describes Accept-Language as a language preference signal and advises servers not to override an explicit user choice. A route through a particular country therefore does not automatically select a language. Cookies may also preserve a selected market or session between requests. Changing the proxy alone does not clear that state.

Record the following parameters before each check:

A new profile reproduces a first visit without saved data for that website. During a repeat visit, data from the previous visit may remain, including the selected language. These are test conditions, not types of proxy.

Do not change the viewport or website version while comparing regional behavior. If you change the country, language, login state, and window size at the same time, identifying the cause of a different result becomes difficult.

Browser-provided geolocation is another independent factor. It is a browser feature that requires permission. The proxy country does not confirm GPS coordinates or granted location access. If the page uses geolocation, record that permission separately.

How do you prepare a Thunderproxy connection?

In the Thunderproxy dashboard, select the required country and connection mode, then copy the corresponding configuration.

1. open Subscriptions and select the Residential subscription
2. use Quick Access for one connection or Export for generated proxy lines
3. copy the complete username, password, host, port, and supported protocol
4. keep every routing suffix in the username field
5. create a new export after changing the required parameters

Exported lines retain the settings selected at export time. Changing a dashboard option later does not rewrite a configuration already copied into another application.

Sticky mode helps maintain a relatively stable connection while you review the landing page and move to the next step. On a residential network, a sticky session does not guarantee the same IP address: the peer may become unavailable before the configured time to live, or TTL, ends. If the exit IP changes during a check, record it and repeat the observation.

Rotating mode suits independent checks. Different session identifiers do not prove that each session received a separate or unique exit IP address.

The protocol and port must match the generated configuration and the client. Thunderproxy currently supports SOCKS5 over TCP only, so browser capabilities do not imply automatic UDP or QUIC routing.

How do you organize profiles in Afina?

Create a clearly named profile for each scenario, then attach the required proxy and browser settings. This makes test scenarios easier to organize in Afina.

The screenshots below show the Afina interface. The sample connection addresses are not Thunderproxy credentials or results from this test. Use values from your Thunderproxy dashboard. UDP labels elsewhere in Afina do not mean that Thunderproxy supports SOCKS5 over UDP: only TCP is available for this protocol.

Save a proxy connection

First, save the connection in Afina's Proxies section.

1. select Add Proxy
2. choose the protocol from your Thunderproxy configuration
3. enter Host, Port, Login, and Password
4. select Check proxy
5. select Add Proxy to save the entry

The Change IP URL field is optional for this workflow. Do not copy an address shown for another provider.

Before saving, give the connection a clear name that identifies the country and session type, such as DE - sticky. A consistent naming scheme makes the correct route easier to select and reduces the risk of testing through a proxy intended for another market.

Assign the connection to a profile

In Accounts, select Add Account for a new QA profile or open an existing profile for editing. On the Proxy tab, choose Saved proxies and select the required entry. Set proxy lets you enter the details directly. Check the connection and save the profile.

After assigning the proxy, run a brief connection check and confirm the exit IP country. Open the test landing page only after this step so that a routing mistake is not confused with incorrect page localization.

Do not include passwords in profile names, screenshots, or shared test reports. A name such as Landing QA - DE - Fresh helps identify the test scenario, but it does not confirm the current IP address or the presence of saved website data.

Afina includes Timezone from IP and Languages from IP settings. Review them against the scenario instead of enabling them automatically for every test. A German visitor who selected English is a valid case. Record the language and time zone required by the test scenario.

An existing profile may contain saved website data. To check a first visit, create a new test profile without imported history or clear the site data according to an approved procedure. Keep repeat visits separate so you do not accidentally delete the settings whose effect you need to investigate.

After launching the profile, open an approved IP-check page inside it. Record the exit IP address visible to websites and the country reported for that address. You may use your team's internal diagnostic page. A successful proxy check confirms connectivity, not correct localization.

Review proxy assignments before testing

Return to Proxies and review Profiles count and Account names for the saved entries. This shows which profiles use the same connection. It does not confirm that each profile has a separate exit IP.

Before running tests in parallel, check whether several profiles share the same connection. A shared sticky session may place them behind one exit IP, so assign separate routes in advance when the results must remain independent.

What should you check on the landing page?

Open a direct URL or an authorized preview link and compare the page with the expected result for that context. Use the same input address and do not change query parameters between markets.

Check the elements in this order:

1. record the final URL and visible country or language redirects
2. inspect headings, navigation, form fields, and error text, not only the first screen
3. compare the currency, eligibility terms, and offer with the website rules
4. check whether the consent banner behaves correctly for the selected settings
5. follow the primary button to the permitted next screen and confirm that the market is preserved

A visual check is not a legal compliance assessment. Do not complete a purchase or submit a production lead unless the test plan permits it. For advertising landing pages, use approved preview or test links without creating artificial clicks, impressions, or conversions.

For advertising pages, Thunderproxy's guide to proxies for ad verification extends this process to country-based redirects and repeated destination checks. It also explains when residential proxies or a dedicated Static ISP address are appropriate.

Record the time, profile name, exit IP country, browser language, saved-data state, website version, expected result, and actual result. Redact personal data from shared screenshots.

How do you investigate an unexpected regional result?

Check the recorded variables first. Do not change the proxy or declare a localization defect before completing that review. The cause is difficult to identify when several parameters change at once.

If the wrong language appears, inspect the language URL, language selector, browser settings, and saved website choice. Repeat the test in a new profile while keeping the network country unchanged. This separates first-visit behavior from a saved user choice.

If the wrong currency appears, check the storefront, account, and delivery country where applicable. Currency does not have to follow IP location. Compare the result with the website's actual priority rules.

If the reported connection country is unexpected, copy the configuration again and check the exit from inside the launched profile. The gateway hostname is not the exit IP address. Geolocation databases may disagree, and an IP address does not identify a specific household or street address. An IP-check result is useful report evidence, but it may not match the geolocation data used by the website.

If access is denied or a request limit is reached, stop the check and contact the website through its authorized support channels. Do not rotate addresses repeatedly to circumvent an access decision.

Before starting the plan, review the Accounts list and its Proxy column. Match each QA profile with its saved connection, then select Start for the required profile.

Record the profile name, proxy alias, launch time, and landing page URL in the test log. These details make the test conditions reproducible and help determine whether a discrepancy comes from the route, the profile, or the page itself.

What does a simple regional test plan look like?

Consider a website launching in the United States, Germany, and the United Kingdom. Its specification says that new visitors receive a market offer based on country, while a manually selected language is preserved on later visits.

A practical sequence is:

1. prepare a new QA profile for each country without changing the viewport or website version
2. open the generic landing page and record the suggested market and default language
3. select another language on the website and reopen the page in the same profile
4. compare the repeat visit with a first visit in a separate new profile using a proxy from the same country
5. if the result conflicts with the specification, change one relevant variable and repeat the check

These are proposed checks, not measured results.

Example: a German route still shows English

Suppose the website rules require German content for a new visitor on a German route unless the visitor previously selected another language. The table below is a diagnostic example, not a result produced by Thunderproxy or Afina.

In the new profile, set the language required by the test scenario and open the main landing page rather than a URL that opens the English version directly. Do not change the website version, viewport, login state, or consent state between comparisons.

Rotating proxies one after another will not show whether English appeared because of a previous user choice, the URL, or the website's localization rules. Controlled conditions give the team a more precise issue report.

Sources and further reading

The connection steps follow Thunderproxy's residential documentation. Afina documentation explains proxy assignment to profiles and session behavior.

• Afina browser profile management
• Afina proxy configuration

Thunderproxy handles the network route, while Afina stores browser state in separate profiles. Before the next authorized regional check, review the available locations and session modes for Thunderproxy Residential proxies, then document the test plan.

Download