# NGINX Configuration Guide: WordPress Uploads CDN Integration in cloudpanel

**URL:** <https://forum.hhf.technology/t/nginx-configuration-guide-wordpress-uploads-cdn-integration-in-cloudpanel/403>\
**Category:** Wordpress\
**Tags:** nginx, wordpress, cloudpanel, cdn-integration\
**Created:** [November 16, 2024, 5:55pm UTC](https://forum.hhf.technology/t/nginx-configuration-guide-wordpress-uploads-cdn-integration-in-cloudpanel/403 "2024-11-16T17:55:00Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![hhf.technoloy](https://forum.hhf.technology/user_avatar/forum.hhf.technology/hhf.technoloy/32/68_2.png) [@hhf.technoloy](https://forum.hhf.technology/u/hhf.technoloy)\
**Post date:** [November 16, 2024, 5:55pm UTC](https://forum.hhf.technology/t/nginx-configuration-guide-wordpress-uploads-cdn-integration-in-cloudpanel/403/1 "2024-11-16T17:55:00Z")

</div>

# NGINX Configuration Guide: WordPress Uploads CDN Integration

## Overview

This technical documentation outlines the implementation of an NGINX configuration designed to intelligently route WordPress media requests between local storage and a Content Delivery Network (CDN). The configuration implements a fallback mechanism where requests first attempt to serve files from the local filesystem before redirecting to the CDN.

## Architecture

### Components

1. **Local WordPress Installation**

2. **Content Delivery Network (CDN)**

3. **NGINX Server**

## Configuration Implementation

### Base Configuration

```nginx
# Define CDN endpoint
set $production cdn.example.com/example-subdirectory;

# Named location for production CDN redirects
location @prod_uploads {
    rewrite "^(.*)/wp-content/uploads/(.*)$" "https://$production/wp-content/uploads/$2" break;
}

# Primary location block for uploads directory
location ~ "^/wp-content/uploads/(.*)$" {
    try_files $uri @prod_uploads;
}

```

### Configuration Breakdown

#### 1. CDN Variable Declaration

```nginx
set $production cdn.example.com/example-subdirectory;

```

- Defines a variable storing the CDN domain
- Allows easy modification of CDN endpoint
- Supports subdirectory paths if required
- Should be updated to match your CDN provider’s endpoint

#### 2. Named Location Block

```nginx
location @prod_uploads {
    rewrite "^(.*)/wp-content/uploads/(.*)$" "https://$production/wp-content/uploads/$2" break;
}

```

- Creates a named location for handling CDN redirects
- Uses regular expression capture groups for path manipulation
- Maintains original file path structure on CDN
- `break` directive prevents further rewrite rule processing

#### 3. Primary Location Block

```nginx
location ~ "^/wp-content/uploads/(.*)$" {
    try_files $uri @prod_uploads;
}

```

- Matches requests to uploads directory using regex
- Implements `try_files` directive for fallback logic
- Attempts local file serving before CDN redirect
- Maintains transparent operation for end users

## Implementation Considerations

### Security

1. **SSL/TLS Configuration**

2. **Access Controls**

### Performance Optimization

1. **Caching Headers**

2. **Compression Settings**

## Monitoring and Logging

### Access Logging

```nginx
log_format cdn_log '$remote_addr - $remote_user [$time_local] '
                   '"$request" $status $body_bytes_sent '
                   '"$http_referer" "$http_user_agent" '
                   'cdn=$upstream_http_x_cdn_status';

access_log /var/log/nginx/cdn_access.log cdn_log;

```

### Error Handling

```nginx
location @prod_uploads {
    error_log /var/log/nginx/cdn_error.log notice;
    rewrite "^(.*)/wp-content/uploads/(.*)$" "https://$production/wp-content/uploads/$2" break;
}

```

## Testing and Validation

### Configuration Testing

1. Syntax validation:

2. Request flow testing:

3. CDN fallback verification:

## Troubleshooting

### Common Issues

1. **404 Errors on CDN**

2. **Mixed Content Warnings**

3. **Performance Issues**

### Debug Configuration

```nginx
location ~ "^/wp-content/uploads/(.*)$" {
    error_log /var/log/nginx/debug.log debug;
    add_header X-Debug-Path $request_filename;
    try_files $uri @prod_uploads;
}

```

### Server Block Explanation

The server block listening on port 8080 is essentially a backend server that handles PHP processing. Here’s why it exists and how it works:

1. The main server (listening on port 443) acts as a reverse proxy and forwards PHP requests to this backend server. This is evident from the line in the main server block:

```nginx
proxy_pass http://127.0.0.1:8080;

```

1. The port 8080 server block has several important functions:

```nginx
listen 8080;
listen [::]:8080; # IPv6 support
server_name hhf.technology;

```

Its main responsibilities are:

1. PHP Processing:

```nginx
location ~ \.php$ {
    fastcgi_pass 127.0.0.1:{{php_fpm_port}}; # Forwards PHP requests to PHP-FPM
    include fastcgi_params; # Includes necessary FastCGI parameters
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    # ... other FastCGI configurations
}

```

1. WordPress-specific handling:

```nginx
try_files $uri $uri/ /index.php?$args; # WordPress pretty URLs
index index.php index.html; # Default files to serve

```

This setup provides several benefits:

- Separation of concerns: Static content is handled by the main server, while PHP processing is isolated
- Better security: PHP processor isn’t directly exposed to the internet
- Performance: It allows for different optimization settings for static and dynamic content