对此曲折的过程做个补充，由于仓促有些改动只是出于尽可能全面的目的，而并不严谨。2025年3月13日下午刚从坑里爬出来，趁着印象深刻做的记录。刚发布完此文章，结果在平台创建模型又出问题，紧接着Docker Desktop打开报错，安装的dify都没了，一朝回到了解放前。无奈之余重新装了一遍，有些地方稍作改动（不改动也没影响）。

有两篇很详细的操作步骤，按这个操作就可以：
参考1
参考2

1、遇到的第一个问题：下载Ollama时（https://ollama.com/download），页面不要关，不然下载就停了然后重下。下载完安装，默认安装到C盘默认路径，可以通过命令：

OllamaSetup.exe /DIR=D:\AI\Ollama

修改安装位置，里面提到的，但是我没试管不管用。
然后下载大模型，都很顺利。
2、遇到第二个问题，虚拟化主机：因为我是windows11家庭版，不能直接按里面提到的方式进行操作。
这里面提到的比较有效https://zhuanlan.zhihu.com/p/700411014

先安装沙箱（如果启用或安装windows功能里面没有沙箱选项的话）：https://zhuanlan.zhihu.com/p/700419029

@echo off
 
echo 检查权限
>nul 2>&1 "%SYSTEMROOT%\system32\cacls.exe" "%SYSTEMROOT%\system32\config\system"
 
echo 权限检查结果：%errorlevel%
 
REM --> 如果设置了错误标志，则没有管理员权限。
if '%errorlevel%' NEQ '0' (
echo 正在请求管理员权限...
goto UACPrompt
) else ( goto gotAdmin )
 
:UACPrompt
echo Set UAC = CreateObject^("Shell.Application"^) > "%temp%\getadmin.vbs"
echo UAC.ShellExecute "%~s0", "", "", "runas", 1 >> "%temp%\getadmin.vbs"
 
echo 正在运行创建的临时文件 "%temp%\getadmin.vbs"
timeout /T 2
"%temp%\getadmin.vbs"
exit /B
 
:gotAdmin
if exist "%temp%\getadmin.vbs" ( del "%temp%\getadmin.vbs" )
pushd "%CD%"
CD /D "%~dp0" 
 
echo 使用管理员权限成功启动批处理
echo .
cls
Title Sandbox Setup
 
pushd "%~dp0"
 
dir /b %SystemRoot%\servicing\Packages\*Containers*.mum >sandbox.txt
 
for /f %%i in ('findstr /i . sandbox.txt 2^>nul') do dism /online /norestart /add-package:"%SystemRoot%\servicing\Packages\%%i"
 
del sandbox.txt
 
Dism /online /enable-feature /featurename:Containers-DisposableClientVM /LimitAccess /ALL
 
pause

将上述代码保存至文本文件，另存为bat格式，双击执行（我好像开始直接把txt后缀直接改为bat，执行的有问题，也可能的没问题，不太确定），先不急重启计算机（应该重启后有效，安装完hyper-v一块重启）

在安装hyper-v：

pushd "%~dp0"
dir /b %SystemRoot%\servicing\Packages\*Hyper-V*.mum >hyper-v.txt
for /f %%i in ('findstr /i . hyper-v.txt 2^>nul') do dism /online /norestart /add-package:"%SystemRoot%\servicing\Packages\%%i"
del hyper-v.txt
Dism /online /enable-feature /featurename:Microsoft-Hyper-V-All /LimitAccess /ALL

同上操作，然后重启电脑
我在上述代码执行时，感觉一直在输出同样的指令，像是陷入死循环，等了一会手动关了，效果是好的

3、我也不知道什么时候装的wsl，可能是虚拟化主机的时候

4、安装Docker，改完配置信息（也可能是错误的改动了其他配置文件），发现Docker打开时报错，然后重新安装一遍就好了。
5、部署Dify，我安装时没报错，但是打开页面遇到问题http://localhost/install
我的80端口被占用了，修改web端口页面端口：
这是虚拟机中配置文件位置：

\\wsl.localhost\docker-desktop\tmp\docker-desktop-root\var\lib\docker\containers\

实际上，装完Docker（也可能是虚拟化主机后，当时没注意），资源管理器中会出现：
在里面可以找到上述路径

里面有好多文件，名称对应ContainerID，找到nginx-1对应的文件夹

修改config.v2.json和hostconfig.json里面的端口信息：反正出现80端口的地方都改为81，怕有地方不改可能会影响哪个功能，但是不要全局替换，因为有些id可能会出现“80”字符。改443端口同理。

修改完后，Dify部署目录里，修改nginx监听端口（二次重装发现这里不用修改，只需改上面的配置文件就可以，当启动容器后，这里会自动修改成81端口，而且上面有句话让改.env文件，按理说应该取的.env中端口值，但是我没改，文件中依旧默认80，但是nginx启动用的是Linux文件中修改的81端口，难道.env配置中的端口没用嘛）

D:\work\AI\dify-main\dify-main\docker\nginx\conf.d

然后访问：http://localhost:81/可以打开页面

6、结果，tm发现我的页面是这样的

控制台查看请求，有个setup的请求返回502。
Docker Desktop中查看服务，发现redis-1和plugin_daemon-1启动不了。
开始以为是端口冲突，我把我本机redis杀死，问题依然存在，redis日志报错

exec /usr/local/bin/docker-entrypoint.sh: exec format error

plugin_daemon日志显示，连不上redis，也就是plugin_daemon依赖redis这个服务。
查了全网，问了AI都没查到什么原因。但我无意中操作：

原先里面的服务是6-alpine，从这里运行，会添加至新的容器，结果发现单独运行也是报错的，而latest是可以运行的，那么应该是某些原因不支持6-alpine这个版本。
这些服务配置信息应该在这里面：

D:\work\AI\dify-main\dify-main\docker

的docker-compose.yaml文件
services下面的每个节点对应了docker容器里面的每个子容器：

在Docker Desktop中将redis删除，修改如下版本信息：
![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/f6ccdd99f2e7478bbe6c22ce6be67167.png

再次执行安装指令

docker compose up -d

会显示redis被重新创建，其他的存在没有被执行

然后重启Docker Desktop，发现Tag已经成了latest，并且再运行
再次打开网页，页面加载正常。（页面会有延迟，或者说服务有延迟，我第一次打开还是异常，以为不是redis的原因，但是过了一会我再次重启了Docker Desktop，然后发现页面突然正常了）

目前进行到这里，先记录一下免得忘了，毕竟后面还有坑等着去踩

7、新问题，在添加模型保存时，长时间未响应，然后显示操作取消。
我怀疑是我电脑性能有限，http请求时间过长而中断。
解决防范：修改nginx响应超时时间

D:\work\AI\dify-main\dify-main\docker

下的.env.example配置文件，原先默认的是65我改为165，重新上面操作，保存成功。

之后遇到问题继续补充。
愿一路顺畅，不再踩坑。