> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gcore.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Integrate a CDN resource with Invision Community Classic 4.x

> Configure Gcore CDN custom URLs for Invision Community Classic 4.x file storage and troubleshoot integration issues.

Invision Community Classic 4.x can generate public file URLs through Gcore CDN by assigning a custom URL to each file-storage configuration. This setting applies to the file areas that use the updated configuration rather than every application resource.

> [!NOTE]
>
> Invision Community Cloud includes a managed global CDN and does not require this setup. The exact AdminCP labels in the current Classic release can differ from this verified 4.x workflow.

Administrator access to the self-hosted Invision Community installation, an active CDN resource, and an HTTPS-enabled [custom domain](/cdn/cdn-resource-options/general/create-and-set-a-custom-domain-for-the-content-delivery-via-cdn) are required. Back up the community files and database before changing storage settings.

**1. Prepare the CDN resource**

Configure the community hostname — `community.example.com` — as the CDN origin. Set the origin host header to the same hostname when the web server uses name-based virtual hosting.

Activate `cdn.example.com` as the HTTPS custom domain and confirm that a known file path returns successfully through both the origin and CDN domains.

**2. Open the storage configurations**

Log in to the Invision Community AdminCP and navigate to **System** > **Overview** > **Files** > **Storage Settings** > **Configurations**. This AdminCP path matches the [storage configurations](https://invisioncommunity.com/4guides/how-to-use-ips-community-suite/file-management/storage-configurations-r20/) workflow, including **Use a custom URL**.

**3. Select a supported storage configuration**

Edit the file-storage configuration used by the content that is delivered through the CDN. File System, FTP, and Amazon S3 configurations support a custom URL, while Database storage does not.

When several configurations serve different file areas, update each required configuration separately.

**4. Set the custom URL**

Enable **Use a custom URL** and enter the full HTTPS CDN URL that maps to the same path as the storage configuration.

For files stored under `/uploads`, enter:

```text theme={null}
https://cdn.example.com/uploads
```

Click **Save**.

**5. Check file-area assignments**

On **Storage Settings**, confirm that each required file area uses a configuration with the CDN custom URL.

Changing the assigned storage configuration can start a background task that moves existing files. Wait for the task to finish because old and new URLs can coexist during the move.

**6. (Optional) Refresh cached file URLs**

If rendered pages still contain the origin domain, run the AdminCP support tool to clear the system cache, then clear any full-page or application cache in front of the community.

**7. Verify CDN delivery**

Open a community page that contains a file from the updated storage configuration and use the browser developer tools:

1. Open the **Network** panel.

2. Reload the page.

3. Select an affected image, stylesheet, script, attachment, or theme file.

4. Confirm that the request URL uses `cdn.example.com` and returns a successful response.

## Integration troubleshooting

When files fail to load from the CDN domain, the cause is usually a storage assignment, a path mismatch, an origin error, or a cache that still serves the previous URL.

* If only some files use the CDN domain, identify their file areas under **Storage Settings** and update the associated configurations.
* For a `403` response, request the same file directly at the origin. Check file permissions, origin access rules, and the Host header.
* If the browser reports mixed-content blocking, load the file over the HTTPS custom URL.
* For a `404` response, compare the custom URL path with the original storage URL and the CDN origin path.
* For a `502` response, verify the origin pull protocol and host header in the CDN resource.
* If pages retain old URLs after clearing the cache, wait for any active storage move or background queue to finish.