Canada proxies: location, networks and session checks

For Canadian web tests, first decide whether the application needs a Canadian country result, a specific province or city, or a particular network. Write a separate acceptance condition for each requirement. A Toronto label does not establish French-language behaviour, a cellular connection or delivery eligibility.

This guide helps you evaluate a Canadian proxy sample before relying on it. Its network distinctions come from CRTC sources; its acceptance matrix and worked example are an evaluation method. No Canadian proxy provider or storefront was tested.

Choose the location the application actually uses

Use country-level targeting when the application only distinguishes Canada from other countries. Request Ontario, Quebec, Toronto or Montreal only when the named rule uses that level of IP-derived location. Write down the observable result that would confirm the rule: a region decision in your application log, for example, or an exposed country selector with a documented configuration mapping.

A supplier's location label, an IP database result and the target's decision are three different pieces of evidence. Preserve all three when they disagree. MaxMind documents variable accuracy, missing finer location fields and mobile IPs used across broad areas; it does not describe its IP data as precise enough to identify a street address. These are MaxMind's documented limits, not a measured Canadian proxy accuracy rate. MaxMind geolocation accuracy.

For a city requirement, record the checker and date, city/subdivision fields and any supplied accuracy radius. A missing city remains missing. If the application does not expose its location decision, report that gap instead of treating a separate checker as proof that the application recognized Toronto.

Read Canadian carrier names at the right layer

Canadian retail brands are not a count of independent networks. The CRTC's brand definitions place these examples in the following groups; a 2026 decision identifies Freedom Mobile and Videotron as Quebecor subsidiaries.

Group	Related retail names	What to clarify in a proxy request
Rogers	Rogers, Fido, Chatr	A Rogers/Fido pair does not establish two different provider groups.
Bell	Bell, Virgin, Lucky Mobile	Specify whether you need the retail brand, a mobile connection or an observed egress network.
TELUS	TELUS, Koodo, Public Mobile	A different retail name alone is insufficient evidence of different access infrastructure.
Quebecor	Videotron, Freedom Mobile; Fizz is a Videotron flanker brand	Ask which service and actual access path the sample uses.

Sources: CRTC brand definitions, CRTC 2026-84, background. This is a set of useful group examples, not an exhaustive list or ipvolt inventory.

Bell and TELUS also share radio-access infrastructure. CRTC decision 2025-245 describes their shared radio-access network and distinguishes it from each company's commercial identity. Its discussion of roaming and MVNO access further shows why a retail service can use another carrier's radio network. A Bell/TELUS pair therefore does not, from names alone, establish independent radio infrastructure. It also does not establish that the samples have identical public IPs or Internet routes. CRTC shared-network decision.

Decide which distinction matters before requesting “carrier diversity”:

• Different provider groups: record the retail brand and its parent group.
• A specific cellular access path: request relevant operator/access documentation and, where available, redacted device or modem evidence tied to the sampled egress. A company-name lookup alone does not establish the radio connection.
• Different Internet egress networks: record the observed public IP, ASN and lookup source/date for each sample. An autonomous system describes IP routing; it does not measure a SIM, tower or radio technology. RFC 1930, section 3.

Keep a missing layer unverified. Do not fill it from a familiar brand name. This approach also applies to “residential” and “ISP” offers: have the supplier define the access and hosting arrangement, then request evidence for the part your test requires.

Set the acceptance conditions before the sample

Select the rows relevant to your job. These are proposed checks, not universal performance guarantees.

Required condition	Record before and during the sample	Decision boundary
Canadian country behaviour	Named rule; fixed browser inputs; dated exit-country evidence; target's region result	Accept this condition only when the agreed target behaviour matches. A checker-only result leaves target recognition unverified.
Province or city targeting	Why the target reads that precision; exact region; checker/date; target decision	Preserve missing or conflicting results. Do not silently downgrade a required city to country.
Mobile or named-network access	Required brand/group, radio access or egress network; supplier's definition; evidence references	A retail name or ASN alone does not satisfy a required mobile-access proof.
Stable session	Duration, request schedule, permitted rotation and reconnect behaviour; observed IP at each check	An unexpected address change fails an unchanged-address condition. Equal sampled addresses do not prove exclusivity or uninterrupted stability between checks.
English/French experience	Browser language, explicit URL, stored choices and relevant application settings	Compare language separately while holding the exit fixed. An IP label alone is insufficient.
Delivery to a Canadian address	Approved full-address reference, configured delivery rule, cart/stock/checkout controls	Judge the configured address outcome separately from IP geography.

For routing setup, use the curl proxy guide with your authorized endpoint. Then perform the target check with the same client configuration. Record the IP family, protocol, client version, concurrency and request budget; the observed result applies to those conditions and that sample.

Keep planned checks and actual results separate. Record every attempt, including timeouts, address changes, missing location data and unexpected application responses. If retrying, retain the first attempt and describe the retry rule. Report both matches and the full attempt count, plus any unverified required conditions.

A Canadian sample decision, worked through

Hypothetical example — all outcomes below are invented. A team needs a Canadian mobile connection for a browser workflow, with the same exit at six checks over 15 minutes. The application's location rule only reads country. The proposed checks are at minutes 0, 3, 6, 9, 12 and 15; this is an example schedule, not a recommended universal sample size.

The supplier labels sample A “Fido, Toronto” and sample B “Rogers, Montreal.” Neither sample includes evidence of its cellular access path.

Invented observation	Sample A	Sample B
Target identifies Canada	6 of 6 attempts	6 of 6 attempts
Observed exit at the six checks	Same address at all six	Address changes between the third and fourth checks
Required cellular-access evidence	Missing	Missing
Decision	Country and sampled address conditions match; mobile requirement remains unverified	Country matches; unchanged-address condition fails; mobile requirement remains unverified

Neither is an accepted overall mobile sample. Sample A needs the missing access evidence; sample B also needs its rotation or reconnect behaviour resolved and a new recorded run. The Toronto/Montreal difference is not a failure of this country-only rule. Six Canadian results cannot cancel a failed session condition.

If the team also wants two provider groups, these labels do not supply that comparison: Fido belongs to the Rogers group. It must revise the supplier request and establish the required network distinction. Merely replacing one label with Bell or TELUS would still require clarity about whether the comparison concerns provider groups, shared radio infrastructure or observed Internet egress.

Keep French and postal delivery controls separate

For a Canadian storefront, record language and delivery requirements without converting them automatically into Montreal or Toronto proxy requirements. Shopify, for example, documents browser language, market entry and saved choices alongside IP localization; the shipping address determines the final checkout experience. That is platform-specific behaviour to verify against the store's configuration. Shopify localization.

Canada Post divides a postal code into a three-character Forward Sortation Area and a finer Local Delivery Unit. Shopify's local-delivery documentation gives M5V* as an example postal zone. For a store actually using that rule, compare approved complete addresses inside and outside the zone with the same exit and cart conditions. Eligibility also depends on address verification, stock, fulfillment location and checkout path. A Toronto IP cannot supply that evidence. Canada Post postal-code structure, Shopify local-delivery conditions.

For the full configuration snapshot, paired visits and record checker, use the separate Shopify Canada localization guide.

Take a precise brief to the provider

Use the existing Canada request brief in JSON or CSV. Both are blank templates; their not_run result is intentional.

Fill the named rule, minimum IP precision, client/protocol, session duration, volume and acceptance window before the sample. In network_type_or_origin_requirement_if_material, state whether you need a retail group, a cellular access path or a particular egress network, and the evidence you will accept. Keep those evidence references with the observation record. Confirm available targeting, permitted use, rotation and replacement terms with the provider; the template supplies no commercial terms.

Use accept only when all required conditions have enough evidence and match the agreed criterion. Record a mismatch when an observed result violates it. Leave a required but unmeasured condition unverified and state the next check. These are human decisions; the request JSON/CSV does not automatically validate a provider.

The source review and matrix were prepared on 27 September 2026. They do not establish proxy supply, speed, reputation or service quality. The guide and downloads are available without signup. Canadian country and carrier availability from ipvolt remains unconfirmed. Get early access to hear when access opens; joining does not reserve a Canadian endpoint. One email when access opens. Nothing else.