看起来你遇到的核心问题是Docker环境下WebLogic受管服务器的启动配置被“固化”了——哪怕修改甚至删除启动脚本，启动新服务器时还是会加载旧的infra_server1配置。我来分享几个针对性的排查和解决步骤：

1. 先检查Docker启动命令的参数硬编码 #

很多WebLogic Docker镜像的启动逻辑是直接通过命令行传入服务器名称，而不是完全依赖脚本配置。你得确认启动infra_server2的命令是否正确传递了服务器名：

• 原启动infra_server1的命令可能类似：docker run -d --name infra_server1 <镜像名> startManagedServer.sh infra_server1
• 启动infra_server2时，必须明确替换服务器名参数：docker run -d --name infra_server2 <镜像名> startManagedServer.sh infra_server2
  如果你的启动命令里没改这个参数，哪怕脚本改得再对也没用——Docker会把命令行参数直接传给脚本，覆盖脚本内部的配置。

2. 清理Docker容器的缓存与残留配置 #

Docker容器会保留之前的文件系统状态，如果你是基于同一个旧容器修改后重启，旧配置大概率还在缓存里：

• 先彻底停止并删除有问题的infra_server2容器：docker stop infra_server2 && docker rm infra_server2
• 别用docker restart，一定要完全销毁后重新创建容器，确保从镜像的干净状态启动。
• 如果用Docker Compose管理，执行docker-compose down -v删除关联的数据卷，避免卷里残留旧的配置文件。

3. 验证WebLogic域的受管服务器配置 #

登录WebLogic管理控制台，确认infra_server2已经正确添加到域配置中：

• 进入Environment > Servers，检查infra_server2是否存在，监听地址、端口等配置是否正确。
• 进入服务器的Server Start标签页，查看启动参数（Arguments）里有没有硬编码指向infra_server1的内容。

4. 确认startManagedServer.sh的实际执行路径 #

有时候Docker镜像里可能存在多个脚本副本，你修改的未必是容器实际调用的那个：

• 临时进入容器调试：docker exec -it <容器名/ID> bash
• 执行which startManagedServer.sh找到脚本的实际路径，确认你修改的是这个位置的文件。
• 也可以通过echo $DOMAIN_HOME查看域目录，去$DOMAIN_HOME/bin下直接检查脚本内容。

5. 追踪启动参数的来源 #

日志里显示sys.argv[1] = infra_server1，说明脚本接收到的第一个参数确实是infra_server1，这时候要搞清楚参数从哪来：

• 启动容器时可以加-e DEBUG=true（如果镜像支持的话），或者在startManagedServer.sh开头加一行echo "Received args: $@"，查看实际传入的参数。
• 如果参数确实来自启动命令，那就是你启动infra_server2时的命令写错了，必须确保传入正确的服务器名。

6. 重新构建自定义Docker镜像（如果有修改） #

如果你修改了startManagedServer.sh或者域配置，别直接在运行的容器里临时修改，而是通过Dockerfile重新构建镜像：

FROM oracle/weblogic-infrastructure:12.2.1.4
COPY modified_startManagedServer.sh $DOMAIN_HOME/bin/startManagedServer.sh
RUN chmod +x $DOMAIN_HOME/bin/startManagedServer.sh

用新构建的镜像启动infra_server2，确保修改的脚本被持久化到镜像里，而不是只存在于临时容器的文件系统中。

按照这些步骤排查，应该能定位到问题所在。核心是要区分Docker启动命令参数、镜像内脚本配置、WebLogic域配置这三个层面的内容，确保它们都指向正确的受管服务器名称。

内容的提问来源于stack exchange，提问作者Amal Vijayan