# UXP fetch API bypasses system proxy settings on macOS

**URL:** https://forums.creativeclouddeveloper.com/t/uxp-fetch-api-bypasses-system-proxy-settings-on-macos/11545
**Category:** Photoshop
**Tags:** uxp
**Created:** [November 14, 2025, 4:31pm UTC](https://forums.creativeclouddeveloper.com/t/uxp-fetch-api-bypasses-system-proxy-settings-on-macos/11545 "2025-11-14T16:31:06Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![pixxio](https://avatars.discourse-cdn.com/v4/letter/p/a4c791/32.png) [@pixxio](https://forums.creativeclouddeveloper.com/u/pixxio)
#### Post date: [November 14, 2025, 4:31pm UTC](https://forums.creativeclouddeveloper.com/t/uxp-fetch-api-bypasses-system-proxy-settings-on-macos/11545/1 "2025-11-14T16:31:06Z")

</div>

## Summary

When migrating from CEP to UXP, we’ve discovered that the `fetch` API bypasses system proxy settings on macOS, while CEP’s `XMLHttpRequest` properly respected them. This is blocking deployment in corporate environments with mandatory proxy configurations.

## Background

In our CEP plugin, we used `XMLHttpRequest` to download files from our API, which correctly honored macOS system proxy settings:

```javascript
// CEP - Working with proxy
var xhr = new XMLHttpRequest();
xhr.open('GET', remoteUrl, true);
xhr.responseType = 'arraybuffer';
xhr.onload = function () {
  if (this.status == 200 || this.status == 304) {
    var uInt8Array = new Uint8Array(this.response);
    var buffer = Buffer.from(uInt8Array);
    fs.writeFileSync(absoluteFilePath, buffer);
    // Success
  }
};

xhr.send();

```

This worked perfectly in corporate environments where all network traffic must go through a configured system proxy.

## Problem in UXP

UXP doesn’t support `XMLHttpRequest` and only provides the `fetch` API. However, `fetch` appears to bypass system proxy settings on macOS:

```javascript
// UXP - Bypasses proxy on macOS
const response = await fetch(url);
if (!response.ok) {
  throw new Error(`Failed to download file: ${response.statusText}`);
}
const arrayBuffer = await response.arrayBuffer();

```

Our manifest.json has the correct network permissions:

```json

{
  "requiredPermissions": {
    "network": {
      "domains": "all"
    }
  }
}

```

## Environment

- **Host Applications** : InDesign 18.0+ and Photoshop 24.0+

- **UXP manifestVersion** : 5

- **Platform** : Primarily macOS (where proxy issues are observed)

- **Network setup** : Corporate environments with mandatory HTTP/HTTPS proxy configuration

## Questions

**Is there a way to make `fetch` respect system proxy settings in UXP?** Are there any configuration options or workarounds we’re missing?

## Impact

This is blocking our UXP plugin release for enterprise customers who require all network traffic to go through their corporate proxy infrastructure. Without a solution, we cannot migrate from CEP to UXP.

Any guidance or workarounds would be greatly appreciated!

---

<div class="post-metadata">

### Author: ![tomzag](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.creativeclouddeveloper.com/tomzag/32/2464_2.png) [@tomzag](https://forums.creativeclouddeveloper.com/u/tomzag)
#### Post date: [November 15, 2025, 6:32pm UTC](https://forums.creativeclouddeveloper.com/t/uxp-fetch-api-bypasses-system-proxy-settings-on-macos/11545/2 "2025-11-15T18:32:37Z")

</div>

I’m a bit confused, why do you say that `XMLHttpRequest` isn’t supported?  
According to the documentation, it is available: [https://developer.adobe.com/photoshop/uxp/2022/uxp-api/reference-js/Global%20Members/Data%20Transfers/XMLHttpRequest/](https://developer.adobe.com/photoshop/uxp/2022/uxp-api/reference-js/Global%20Members/Data%20Transfers/XMLHttpRequest/)  
I’m also using it in my plugins without issues.

---

<div class="post-metadata">

### Author: ![pixxio](https://avatars.discourse-cdn.com/v4/letter/p/a4c791/32.png) [@pixxio](https://forums.creativeclouddeveloper.com/u/pixxio)
#### Post date: [November 17, 2025, 10:14am UTC](https://forums.creativeclouddeveloper.com/t/uxp-fetch-api-bypasses-system-proxy-settings-on-macos/11545/3 "2025-11-17T10:14:36Z")

</div>

You’re absolutely right… I have no idea why I couldn’t get it to work last Friday. Now it works with XMLHttpRequest.

Dankeschön!