HTTPS反向代理嵌入Dify页面时静态资源缺失路径前缀致404

问题场景 #

通过Nginx将项目服务的/dify/路径反向代理至Dify服务器，嵌入的iframe地址为https://项目IP/dify/chatbot/xxxxx，但页面内所有_next相关资源均以https://项目IP/_next路径请求，缺失/dify/前缀，导致404错误。

解决方案 #

方案一：添加Nginx代理规则捕获/_next路径 #

修改Nginx配置，将所有/_next/开头的请求也转发至Dify服务器，配置示例：

server {
    listen 443 ssl;
    server_name xxx.xxx.xxx.xxx; # 项目服务IP或域名

    # 代理/dify/路径至Dify服务器
    location /dify/ {
        proxy_pass https://xxx.xxx.xxx.110/; # 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;
    }

    # 代理/_next/路径至Dify服务器，解决资源404
    location /_next/ {
        proxy_pass https://xxx.xxx.xxx.110/_next/;
        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;
    }

    # 项目自身的其他配置...
}

配置完成后重启Nginx，资源请求会被正确转发至Dify服务器。

方案二：配置Dify基础路径（推荐） #

若Dify支持设置基础路径，在Dify启动时通过环境变量指定BASE_PATH=/dify，让Dify生成的所有资源路径自动带上/dify前缀，比如/dify/_next/...。

示例启动命令：

BASE_PATH=/dify ./start.sh

此时Nginx仅需保留/dify/的代理配置即可，所有资源请求会自动匹配代理路径，无需额外规则。

总结 #

优先选择方案二，从应用层面适配反向代理路径，逻辑更规范；若Dify暂不支持基础路径配置，再用方案一的Nginx规则兜底。

内容的提问来源于stack exchange，提问作者陈铭雄