Photoshop 2026 GenAI components ignore all system proxy configuration

Component: Photoshop 2026 / Generative AI (transmute module, Firefly services) Affects version: Photoshop 27.6.0 (PHSP 27), ACPL SDK 5.11.0, UXP Runtime 9.2.0 

Summary

Photoshop 2026's Generative AI features connect directly to their service endpoints, ignoring every proxy configuration mechanism Windows provides. On networks where direct internet egress is restricted and traffic must traverse an explicit HTTP proxy, these features fail with generic timeout errors after 75–95 seconds.

Other components inside the *same Photoshop process* use the configured proxy correctly and concurrently. This is not a machine-wide or network-wide misconfiguration — it is specific to the code path serving these features.

Because these components connect directly, they succeed only where the network perimeter happens to permit the destination. Where a destination's address pool is partially permitted, the same feature succeeds or fails depending on which address DNS returns, producing intermittent, hard-to-diagnose behavior.

Impact — tested across seven features

Every one of these features connected directly, bypassing the proxy. The difference between success and failure was solely whether the perimeter permitted the destination address — not whether the proxy was configured or permitted the host.

Notably, Generative Fill and Generative Expand use the same host (di-me.ff.adobe.io) and produced different outcomes in the same session. Both logged a transport error first; Fill recovered via import-images-succeed-with-retries, Expand did not.

Rotate Object has 22 failures and 0 successes across all available logs on this host.

Control: the same Adobe account works correctly on a machine with unrestricted direct internet access. This rules out entitlement, licensing, and account state.

Environment

• Adobe Photoshop 2026, version 27.6.0 (PHSP 27)
• ACPL SDK 5.11.0, UXP Runtime 9.2.0 (win32 10.0.19045; x64)
• Windows 10 Enterprise 19045
• Enterprise network, restricted direct egress, explicit HTTP proxy (Squid 5.4)

Internal hostnames, IP addresses and domain names in this report have been replaced with placeholders (proxy.internal, 10.0.0.10, .internal.example.com). Adobe-owned hostnames and public addresses are unmodified. All other values — timings, counts, memory addresses, error strings — are verbatim.

Affected endpoints

From Required/transmute/config.json and runtime ps.url values:

Root cause

The affected components open direct TCP connections to their service endpoints and never issue an HTTP CONNECT request to the configured proxy — under any proxy configuration, including configurations the components themselves have API access to read.

Evidence

1. All five proxy mechanisms were configured, verified active, and ignored

Each mechanism was independently verified as *active and correct at the moment of failure*, not merely set:

Environment variables were confirmed present in the running process by reading PEB → ProcessParameters → Environment from PID 37960:

Environment block : 0x1B833993480   size=35554 bytes   (285 variables)
  HTTP_PROXY=http://proxy.internal:8080
  HTTPS_PROXY=http://proxy.internal:8080
  ALL_PROXY=http://proxy.internal:8080
  http_proxy=http://proxy.internal:8080
  https_proxy=http://proxy.internal:8080
  NO_PROXY=.internal.example.com,localhost,127.0.0.1

NO_PROXY contains only internal domains and matches no affected endpoint, so the direct connections were not a legitimate no-proxy bypass.

2. The proxy demonstrably permits these hosts

Tested independently with curl through the same proxy the application was pointed at:

CONNECT filix3.ff.adobe.io:443                       → 200 Connection established
CONNECT di-imaging.ff.adobe.io:443                   → 200 Connection established
CONNECT di-imaging-genharm.ff.adobe.io:443           → 200 Connection established
CONNECT cis-utils-storage-prod.s3-accelerate...:443  → 200 Connection established

TLS is not intercepted — the certificate presented is genuine Adobe (CN=*.ff.adobe.io, O=Adobe Inc., issued by DigiCert), so certificate pinning is not a factor.

3. Same-process control: the proxy path is healthy, the direct path is chosen anyway

Socket sampling of Photoshop.exe at 1 Hz over a 15-minute window containing one Rotate Object and one Harmonize attempt:

2475×  10.0.0.10:8080         ESTABLISHED   proxy connections, healthy throughout
  65×  34.193.227.236:443     ESTABLISHED   image.adobe.io — DIRECT, and succeeds
 254×  3.163.24.x:443         SYN_SENT      di-imaging — never completes
  13×  3.169.163.116:443      SYN_SENT      cis-utils-storage — never completes
   0×  CONNECT for any affected host

The decisive line is image.adobe.io: 65 successful direct connections in the same process, at the same time. The component always connects directly. It succeeds only where the perimeter permits the destination. This demonstrates the behavior is unconditional — not a fallback after a proxy failure.

A separate 15-minute window covering Generative Fill, Expand, Image and Upscale showed the same pattern. Every destination Photoshop reached directly was a Firefly endpoint or a certificate-revocation host; every other destination in the process went through the proxy. The bypass is confined to one code path and is consistent across features.

4. Partial reachability produces intermittent failures

Within a single host's address pool, some addresses were reachable and others were not:

di-me.ff.adobe.io    35.80.193.162    ESTABLISHED   ← 1 of 4
                     32.184.59.208    SYN_SENT
                     44.254.102.171   SYN_SENT
                     54.148.103.46    SYN_SENT

upsampler-v1.ff.adobe.io   52.35.200.68 / 44.250.87.225 / 184.34.94.30   all SYN_SENT

This is why Generative Fill (which retries) recovered and Generative Expand did not, despite using the same hostname in the same session — and why Generative Upscale, whose pool had no reachable address, failed every time.

These endpoints publish DNS TTLs of 4–5 seconds with rotating address pools, which makes the resulting behavior non-deterministic from the user's perspective and extremely difficult to diagnose from the UI.

5. Protocol analysis

The affected API traffic is ordinary HTTPS and is proxy-compatible:

• API traffic: TCP 443 only; no UDP/QUIC to any external address in any capture
• Schemes: every URL in transmute/config.json and every runtime ps.url is https://
• WebSocket: the binary contains WebSocket code, but the only ws:// URL is ws://localhost (local panel IPC). No remote wss:// endpoint is used by these features, and no HTTP Upgrade or WebSocket handshake appears in any capture.
• Certificate revocation: the same components additionally issue direct TCP 80 OCSP/CRL requests to *.amazontrust.com, which also bypass the proxy and are also blocked. These are listed among the affected endpoints above.

Most conclusively, di-imaging.ff.adobe.io was observed completing successfully through an HTTP CONNECT tunnel — CONNECT → 200, TLS 1.2 handshake, 268 KB upload, response in 350 ms, with Select Subject logging success. The endpoint is fully proxy-compatible; the client simply does not use the proxy.

6. Binary analysis

Photoshop.exe imports:

WinHttpOpen  (×2)                        WinHttpGetIEProxyConfigForCurrentUser
WinHttpGetProxyForUrl                    WinHttpSetCredentials
WinHttpQueryAuthSchemes                  WinHttpConnect / WinHttpSendRequest / ...

No libcurl symbols are present. Photoshop therefore *has* full proxy-aware and proxy-authentication plumbing available, and uses it elsewhere in the same process.

WinHttpOpen appearing twice, combined with the observed split behavior, is consistent with one WinHTTP session being created with WINHTTP_ACCESS_TYPE_NO_PROXY while another uses the proxy-aware path.

Note: this specific mechanism is an inference from observed behavior plus the import table, not a conclusion from disassembly. The observable facts — that five configured proxy mechanisms are all ignored on this code path while honored on others in the same process — hold regardless of the internal cause.

Steps to reproduce

1. Configure a Windows host with no direct internet egress; require an explicit HTTP proxy.
2. Configure the proxy via any or all of: WinINET static, PAC, WPAD, netsh winhttp, environment variables.
3. Ensure the proxy permits CONNECT to *.ff.adobe.io and the S3 upload endpoints (verify with curl -x).
4. Launch Photoshop 2026 and invoke any Generative AI feature — Rotate Object and Generative Upscale reproduce most reliably.

Expected: Photoshop issues CONNECT filix3.ff.adobe.io:443 (or equivalent) to the configured proxy.

Actual: Photoshop opens a direct TCP connection that the network drops, retries for 75–95 seconds, then reports generic-error or 1004 server-not-responding. No CONNECT is ever issued for these endpoints.

Ruled out

• Entitlement / licensing — same account works on a direct-internet machine
• Proxy allowlist — proxy returns CONNECT ... 200 for all affected hosts
• TLS interception / certificate pinning — genuine Adobe DigiCert certificate, no MITM
• Adobe service availability — the one call that does traverse the proxy responds in 350 ms
• Protocol incompatibility — plain HTTPS over TCP 443; no WebSocket, QUIC, or alternate scheme
• NO_PROXY misconfiguration — verified in-process; matches no affected host
• Proxy authentication — reproduced against a proxy requiring no authentication for these hosts

Requested actions

1. Route Firefly/GenAI traffic through the same proxy-aware HTTP client used elsewhere in Photoshop — honoring WinHttpGetIEProxyConfigForCurrentUser and WinHttpGetProxyForUrl, including Negotiate/NTLM proxy authentication. This should cover OCSP/CRL retrieval as well.
2. Short term: provide a documented configuration override to force proxy usage for these endpoints.
3. Surface the underlying transport error. generic-error and 1004 server-not-responding are indistinguishable from entitlement failures, service outages, or network problems, which made this substantially harder to diagnose than necessary.
4. Publish the complete endpoint list for GenAI features, including ports. These services are sharded across many hostnames (filix3, di-me, di-imaging, di-imaging-genharm, firefly-substance3d, firefly-clio-imaging, image-v5, upsampler-v1, di-imaging-clio-erase) plus S3 upload endpoints and OCSP/CRL hosts. At present they are discoverable only by triggering failures, which makes enterprise network configuration reactive and incomplete.

Note for triage

This is not a customer network misconfiguration. The proxy is correctly configured and permits the traffic; Photoshop does not use it. Any enterprise operating behind an explicit proxy should reproduce this.

The image.adobe.io control — 65 successful direct connections alongside 267 failed direct attempts, in a single process — demonstrates the component never attempts the proxy under any configuration. The feature matrix above shows the behavior is systemic across the Generative AI feature set rather than specific to one tool.