抛开场景谈需求都是耍流氓
- 大部分时候,我们只能从客户那边拿到一个端口号
- 一个端口便于管理
- 私有桶,公开桶不需要做这样的设置
- 下载上传不受影响,因为是后台对后台,通过 docker 的 servername:端口直接访问的
- 前端直接调用 minio 的服务预览会有问题
环境
使用 docker-compose 编排的 ruoyi-vue-plus 环境,并且使用 minio,假定客户访问的地址或者域名是 example.com,想要实现的效果是
- example.com/web 访问 web 前端
- example.com/ 下的其他请求请求转发到后台
- example.com/minio-ui 转发到 minio 的web 控制台
- example.com/minii-* 其他请求转发到 minio 的 api
做法
这里docker-compose 具体写法就不贴了,假定 minio 在 docker-compose 中的名称就叫 minio
- 配置
/minio-ui/
的请求,到 minio 的控制台,这一步比较简单 - 配置
^~ /minio-
的请求,转发到 api 端口 - 由于
S3 API签名计算算法 不 支持通过代理方案来托管MinIO服务器API的情况,例如 example.net/s3/
,需要建一个以minio-
开头的桶 - 将文件的自定义访问域名设置成
http://example.com
这样,假如一个请求是
http://example.com/minio-kakashine/2025/07/02/a.jpg?签名
经过 nginx 的转发就会变成
http://minio:9000/minio-kakashine/2025/07/02/a.jpg
这不是什么高级用法,只是投机取巧而已,可以将 minio-
改成任何路径,甚至是桶名称,但这样就需要配置多个 nginx 的路径配置
这是 nginx 配置文件
location /minio-ui/ {
#URL重写,将请求中的 minio-ui 部分去掉
rewrite ^/minio-ui/(.*) /\ break;
#转发到 minio服务器
proxy_pass http://minio:9090;
proxy_set_header Host $http_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-NginX-Proxy true;
real_ip_header X-Real-IP;
proxy_connect_timeout 300;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
chunked_transfer_encoding off;
}
#官方文档的写法是:S3 API签名计算算法 不 支持通过代理方案来托管MinIO服务器API的情况,例如 example.net/s3/
location ^~ /minio- {
proxy_set_header Host $http_host;
proxy_pass http://minio:9000;
proxy_pass_request_headers on;
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_connect_timeout 5;
}
docker-compose 中 minio 的环境变量,做了反代是需要加这个,否则会出现 web 控制台资源文件无法加载情况的
environment:
MINIO_BROWSER_REDIRECT_URL: "http://192.168.100.10:8095/minio-ui"
这是 ruoyi-vue-plus 的配置
https://minio.org.cn/docs/minio/linux/integrations/setup-nginx-proxy-with-minio.html - 官方文档