FABRIC ON PREMISED GATEWAY DATA ACCESS USING A COPY DATA ACTIVITY FROM A PIPE LINE

Great, that rules out the two easiest culprits. Let me clarify the two open items.

On the region thing don't let that alarm you, I don't think it's a misconfiguration on your end. Not every Fabric region runs its own dedicated pipeline "frontend" cluster; smaller/newer regions get mapped to a nearby hub region for this specific backend service, and the pipeline/gateway traffic gets routed there even though your capacity metadata correctly shows France Central everywhere else. So seeing "we" (West Europe) instead of "fr" is very likely just how the France Central capacity resolves for this particular service not evidence that something's misaligned. The practical takeaway: don't chase changing your capacity or gateway region over this. Instead, just explicitly confirm outbound access to we.frontend.clouddatahub.net by name (not just the wildcard rule you think covers it) — sometimes the wildcard entry in the firewall doesn't actually catch every subdomain if it was written narrowly (e.g., matching *.frontend.clouddatahub.net at the wrong depth, or an old rule that only allow-listed the endpoint your org saw at setup time, like eu. or eu2., and never got updated when traffic started resolving to we.).

On point 4 sorry, that one was compressed. What I meant: even when ping/telnet to we.frontend.clouddatahub.net succeed, that only proves TCP/443 connectivity exists — it doesn't prove the actual HTTPS/TLS session the gateway needs goes through cleanly. If your network has any SSL/TLS inspection (a proxy that intercepts and re-signs HTTPS traffic, common in corporate environments), the gateway can fail to validate the certificate chain it gets back, and you'll see exactly this kind of "can't reach X" error even though basic network connectivity is fine. Since you're on a VM, it's worth checking whether that VM's outbound traffic goes through any corporate proxy or firewall appliance that does deep packet inspection on 443 and if so, whether *.frontend.clouddatahub.net (and ideally *.clouddatahub.net more broadly) is on the bypass/exclusion list for that inspection, not just "allowed" at the firewall level.

Given you've already ruled out gateway version and multiple installs, I'd actually check the TLS inspection angle before digging further into region stuff that mismatch between "manual browse to the URL works" and "gateway still fails" is the classic signature of an inspecting proxy, and it lines up with what others have hit on this exact error

Hi Jean, this one's actually a fairly known gotcha with the on-prem gateway + Copy activity combo, and the "network connectivity" wording in the error is honestly a bit misleading it's rarely a pure firewall problem when Dataflow Gen2 works fine on the same gateway.

A few things worth checking, roughly in order of how often they turn out to be the culprit:

1. Gateway build/version. Copy activity support for on-prem gateways in pipelines needs gateway version 3000.214.2 or newer. If auto-update isn't turned on, it's easy to be running something months old without realizing it worth checking Gateway → About in the app and just manually pushing the latest monthly release even if it "shows as updated." A few people have had this exact error clear up purely from a manual gateway update.

2. Copy activity and Dataflow Gen2 don't use identical backend paths. That's actually why you can see this split — Dataflow Gen2 can succeed while the Copy Data table picker/execution fails, even though both ride the same gateway. So "it works in one but not the other" doesn't rule out a gateway-side issue, it's actually a pretty typical symptom of one.

3. Region alignment. The endpoint in your error (we.frontend.clouddatahub.net) is region-specific — the "we" prefix ties to a specific Fabric region. If your gateway's registered region doesn't line up with where your capacity/workspace lives, Copy activity can be pickier about that than Dataflow Gen2 is. Worth checking what region your gateway is registered under vs. your capacity's region.

4. Outbound access to the full endpoint family. Since it's a wildcard, *.frontend.clouddatahub.net needs to be reachable over 443, not just the one hostname shown in the error if there's TLS inspection/SSL decryption on your proxy, that can also break this even when telnet/ping to the specific host succeed, since it's not a raw connectivity problem so much as the handshake being tampered with.

5. Multiple gateway installs. If there's more than one on-prem gateway installed anywhere associated with this cluster, that's caused this exact kind of pipeline failure for others worth a quick check under Manage Gateways to make sure there's only one.

My money would be on #1 or #3 given it "used to work" and now doesn't with no config changes on your end that pattern usually points to either a stale gateway build hitting a backend change, or a region mismatch that got more strictly enforced. Worth posting your gateway version and the region it's registered under; that'll narrow it down fast.