Implementing Nginx Reverse Proxy for Dify to Access Claude Model

Background: Due to policy changes, Dify cannot directly access AWS Bedrock services and the Claude model from within China. The urgent problem is how to call the Claude model without migrating data centers, ensuring service stability and user experience.

Proposed Options:

Dify migration to overseas regions – Advantages: proxy servers can forward requests to AWS, making speed and response time easier to control while preserving the existing architecture. Disadvantages: requires additional proxy configuration and handling of SSL/TLS issues.

Dify using a proxy model – Advantages: theoretically uses AWS services directly, avoiding network interference. Disadvantages: adds complexity, may significantly degrade overall access speed because Dify already integrates other models and services.

Chosen Solution: Use a reverse proxy (Nginx) to forward Claude requests, as it offers minimal impact on other Dify models, lower implementation cost, and easier rapid deployment.

Implementation Steps for Nginx Reverse Proxy:

Obtain the latest Claude endpoint address from AWS documentation.

Configure Nginx in stream mode because Claude uses HTTPS and Dify does not have the SSL certificate. This mode allows reading the SNI information with ssl_preread to route traffic based on domain.

Enable the ssl_preread module and set up an upstream block that uses variables and a resolver for dynamic DNS resolution.

Update Dify’s docker-compose.yml to add the proxy IP in the hosts section of the API and worker services.

Restart the Docker services to apply the changes.

Key Considerations:

Using Nginx’s reverse proxy keeps the impact on other Dify models minimal.

Configuration cost is lower than full migration.

HTTPS handling requires ssl_preread and proper SNI routing.

The final deployment includes updating Docker Compose, binding the Claude domain to the proxy address, and restarting the services.