How to deploy dify under two nginx layer?

[AdaChamberss]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

Content

I used 'docker compose up -d' to start dify on 10.142.157.37 . The exposed nginx port is 5094:5094. My team has a unified nginx that all external requests must go through: 10.142.157.36:8080. So an external must go through 2 nginx layers: the unified nginx and the dify nginx.
My current setting for the unified nginx is:

location  ^~/dify/ {
        proxy_redirect ~^/dify/(.*) /$1;
        client_max_body_size 100m;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;    
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto  $scheme;
        proxy_http_version 1.1;
        proxy_read_timeout 1800s;
        proxy_pass http://10.142.157.37:5094/; 
        }

I modified some environment varibles for docker compose:

x-shared-env: &shared-api-worker-env
  CONSOLE_API_URL: ${CONSOLE_API_URL:-http://10.142.157.36:8080/dify}
  CONSOLE_WEB_URL: ${CONSOLE_WEB_URL:-http://10.142.157.36:8080/dify}
  SERVICE_API_URL: ${SERVICE_API_URL:-http://10.142.157.36:8080/dify}
  APP_API_URL: ${APP_API_URL:-http://10.142.157.36:8080/dify}
  APP_WEB_URL: ${APP_WEB_URL:-http://10.142.157.36:8080/dify}
  FILES_URL: ${FILES_URL:-http://10.142.157.36:8080/dify}

Also, I modified ~dify/web/utils/var-basePath.js as:

module.exports = {
  basePath: '',
  assetPrefix: '/dify',
}

modified some varibles in ~/dify/web/.env.local as:

# The base URL of console application, refers to the Console base URL of WEB service if console domain is
# different from api or web app domain.
# example: http://cloud.dify.ai/console/api
NEXT_PUBLIC_API_PREFIX=http://10.142.157.36:8080/dify/console/api
# The URL for Web APP, refers to the Web App base URL of WEB service if web app domain is different from
# console or api domain.
# example: http://udify.app/api
NEXT_PUBLIC_PUBLIC_API_PREFIX=http://10.142.157.36:8080/dify/api

However, I found that when testing external requests, the browser still automatically request http://10.142.157.36:8080/apps?_rsc=1dl4p instead of http://10.142.157.36:8080/dify/apps?_rsc=1dl4p.
So How can I solve this to make sure everything works right for 2 nginx layer (not only signin) ?

[dosubot[bot]]

To deploy Dify behind two nginx layers with a subpath like /dify, you need to coordinate changes in your frontend build, nginx proxy config, and environment variables. The main reason your browser requests are missing the /dify prefix is that Dify's frontend must be built with the correct base path—environment variables alone won't fix this.

Here's what you need to do:

1. Frontend:

   • Edit web/utils/var-basePath.js and web/utils/var.ts to set both basePath and assetPrefix to /dify (not just assetPrefix).
   • Update web/.env.local so NEXT_PUBLIC_API_PREFIX and NEXT_PUBLIC_PUBLIC_API_PREFIX include /dify in their URLs.
   • Rebuild the frontend Docker image after these changes. The base path is baked in at build time—just changing .env or nginx config is not enough.
   • Use this custom image in your Docker Compose setup.
   • Reference | Reference

2. External nginx (gateway):

   • Your location block for /dify/ should look like:

     location /dify/ {
         proxy_pass http://10.142.157.37:5094/dify/;
         proxy_set_header Host $host;
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Forwarded-Proto $scheme;
         proxy_set_header X-Forwarded-Prefix /dify;
         # Do NOT strip the /dify prefix if your frontend is built for /dify
     }

   • Do not use a rewrite that strips /dify if your frontend is built for /dify—the app expects all requests (including static assets) to include the prefix.
   • Reference

3. Backend:

   • Set all backend URL environment variables (like CONSOLE_API_URL, APP_WEB_URL, etc.) to include /dify if you use them for links or CORS.
   • Set RESPECT_XFORWARD_HEADERS_ENABLED=true in your backend .env for correct URL generation behind proxies.
   • No changes needed to the internal nginx config inside the Dify container.
   • Reference

Troubleshooting:

• If you see 404s for static assets or API calls, check that the frontend was built with /dify as the base path and that nginx is not stripping the prefix.
• In your browser's network tab, all requests should start with /dify/.
• Restart all containers after making these changes.

Summary:

• The frontend must be rebuilt with /dify as the base path.
• The external nginx should proxy /dify/ without stripping the prefix.
• Backend URLs and CORS settings should include /dify where needed.

This setup ensures all requests (including static assets and API calls) work correctly through both nginx layers with the /dify prefix.
Full step-by-step and explanation

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[AdaChamberss]

Followed the suggestion and seems to solve almost everything. However I found a image request failed. The dify nginx reported:

10.142.157.36 - - [31/Oct/2025:06:49:59 +0000] "GET /dify/_next/image?url=%2Fscreenshots%2Flight%2FChatflow.png&w=1920&q=75 HTTP/1.1" 400 54 "http://10.142.157.36:8080/dify/apps" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36" "10.142.81.41, 10.142.81.40"

@dosu

[dosubot[bot]]

The 400 error for /dify/_next/image is almost always caused by a mismatch between your frontend build's basePath/assetPrefix and how nginx proxies image/static requests. For Dify under a subpath, you need to:

1. Make sure both basePath and assetPrefix are set to /dify in web/utils/var-basePath.js and web/utils/var.ts before building the frontend image. Just changing environment variables or .env files is not enough—these values must be baked into the build reference.
2. Rebuild the frontend Docker image after making these changes.
3. In your external nginx, do not rewrite or strip the /dify prefix for requests to /dify/_next/image or other static assets—proxy them as-is to the Dify nginx. Only strip the prefix for API/backend requests reference.
4. The url parameter in the image request should be a path relative to the basePath (e.g., /screenshots/light/Chatflow.png). If your frontend and nginx configs are correct, Next.js will resolve this properly.

If you still see 400 errors, double-check that your frontend build, nginx proxy, and browser asset URLs all consistently include the /dify prefix for static/image requests. Runtime changes to basePath are not supported—you must rebuild after changing these settings reference.

Recent Next.js upgrades in Dify (now at 15.5.4) may help with edge cases, but the core requirement is correct build and proxy alignment reference.

Let me know if you want a sample nginx config or help checking your asset URLs!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[AdaChamberss]

The web docker reported:

06:42:03 1|dify-web | ⨯ The requested resource isn't a valid image for /screenshots/light/Chatflow.png received text/html; charset=utf-8

However, I checked '/app/web/public/screenshots/light/Chatflow.png' indeed exists in the dify web docker. You can see from the dify nginx logs that '/dify' is not stripped.
@dosu

[dosubot[bot]]

The 400 error from Next.js image optimization means the image optimizer received an HTML error page (like a 404 or 403) instead of the actual image file. Even though /app/web/public/screenshots/light/Chatflow.png exists in your container, this usually happens because the request to /dify/_next/image?url=%2Fscreenshots%2Flight%2FChatflow.png can't actually access /dify/screenshots/light/Chatflow.png as a static asset.

To troubleshoot:

• Make sure both basePath and assetPrefix are set to /dify in web/utils/var-basePath.js and web/utils/var.ts before building the frontend image. Environment variables alone won't fix this—these values must be baked into the build.
• Rebuild the frontend Docker image after making these changes.
• In your external nginx, do not rewrite or strip the /dify prefix for requests to /dify/_next/image or /dify/screenshots/light/Chatflow.png—proxy them as-is to the Dify nginx. Only strip the prefix for API/backend requests.
• Test direct access to /dify/screenshots/light/Chatflow.png from your browser or via curl through the nginx proxy. If you get a 404 or HTML response, the static asset isn't being served correctly.

If the static asset is accessible and returns the correct Content-Type: image/png, Next.js image optimization should work. If not, double-check your frontend build and nginx proxy alignment. Runtime changes to basePath are not supported—you must rebuild after changing these settings.
Reference | Reference

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[AdaChamberss]

How to install a plugin offline for this 2 nginx layer condition?
I upload a local difypakg and click install. The plugin docker raised an error:

2025/11/03 01:49:00 /app/internal/db/executor.go:259 record not found
[1.237ms] [rows:0] SELECT * FROM "plugins" WHERE plugin_unique_identifier = 'langgenius/openai:0.2.6@e2665624a156f52160927bceac9e169bd7e5ae6b936ae82575e14c90af390e6e' ORDER BY "plugins"."id" LIMIT 1
[GIN] 2025/11/03 - 01:49:00 | 200 | 39.457843ms | 192.168.48.7 | POST "/plugin/3d178871-1256-4b6e-85d6-955ed810d225/management/install/identifiers"
[GIN] 2025/11/03 - 01:49:00 | 200 | 869.964µs | 192.168.48.7 | GET "/plugin/3d178871-1256-4b6e-85d6-955ed810d225/management/install/tasks/76cc26b0-d6fc-415b-a9f2-969d9ec0096a"
[GIN] 2025/11/03 - 01:49:00 | 200 | 831.122µs | 192.168.48.7 | GET "/plugin/3d178871-1256-4b6e-85d6-955ed810d225/management/install/tasks?page=1&page_size=100"
2025/11/03 01:49:00 full_duplex.go:27: [INFO]new plugin logged in: langgenius/openai:0.2.6
2025/11/03 01:49:00 full_duplex.go:59: [INFO]init environment for plugin langgenius/openai:0.2.6
[GIN] 2025/11/03 - 01:49:10 | 200 | 962.815µs | 192.168.48.7 | GET "/plugin/3d178871-1256-4b6e-85d6-955ed810d225/management/install/tasks/76cc26b0-d6fc-415b-a9f2-969d9ec0096a"
[GIN] 2025/11/03 - 01:49:21 | 200 | 808.08µs | 192.168.48.7 | GET "/plugin/3d178871-1256-4b6e-85d6-955ed810d225/management/install/tasks/76cc26b0-d6fc-415b-a9f2-969d9ec0096a"
[GIN] 2025/11/03 - 01:49:32 | 200 | 784.495µs | 192.168.48.7 | GET "/plugin/3d178871-1256-4b6e-85d6-955ed810d225/management/install/tasks/76cc26b0-d6fc-415b-a9f2-969d9ec0096a"
[GIN] 2025/11/03 - 01:49:40 | 200 | 748.39µs | 192.168.48.7 | GET "/plugin/3d178871-1256-4b6e-85d6-955ed810d225/management/install/tasks?page=1&page_size=100"
2025/11/03 01:49:42 full_duplex.go:65: [ERROR]init environment failed: failed to install dependencies: exit status 2, output: error: Failed to fetch: https://pypi.org/simple/numpy/
Caused by: Request failed after 3 retries
Caused by: error sending request for url (https://pypi.org/simple/numpy/)
Caused by: client error (Connect)
Caused by: dns error
Caused by: failed to lookup address information: Temporary failure in name resolution
, retrying
2025/11/03 01:49:42 full_duplex.go:59: [INFO]init environment for plugin langgenius/openai:0.2.6

Seems it was installing dependencies online, but the server does not have internet. Can I install everything on a machine with internet and then upload everything once to the server?

@dosu.

[AdaChamberss]

Found a new environment variable TRIGGER_URL in the .env of dify 1.10.0. What is this variable used for? Does it conflict with the ones above?
@dosu.

[dosubot[bot]]

TRIGGER_URL in Dify 1.10.0 is used to configure the base URL for trigger-related services, such as webhook handling and workflow triggers. Its default value is http://localhost:5001, and it's defined specifically for the new trigger functionality introduced in this version. It does not conflict with other environment variables like CONSOLE_API_URL, APP_API_URL, or the various WEB_URL and NEXT_PUBLIC variables, since those are for frontend or general API routing, while TRIGGER_URL is only for trigger service configuration.
Details in the PR introducing TRIGGER_URL

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}