企业官网建设流程全解析

简介：在Windows 64位环境下搭建Maven私服，Nexus是广泛应用的开源仓库管理器。nexus-3.45.0-01-win64是Sonatype推出的Nexus 3.x版本安装包，面向Java开发者、运维人员及企业内网依赖管理场景，用于解决依赖下载慢、内部构件统一存储与权限控制等问题。压缩包内共690个文件，大小约240.62MB，主要包含jar、dll、xml、png、exe、properties、cfg等类型：jar构成核心运行库，dll支持Windows本地调用，exe用于启动服务，xml、properties、cfg为配置与元数据，png等为界面资源。目前已有417人学习/下载。解压后可直接获得Nexus完整目录结构，包括sonatype-work运行时数据目录和nexus-3.45.0-01程序目录，便于理解仓库管理、依赖代理、发布部署与权限控制等机制；同时包含安全与认证相关的配置项，如JMX远程访问、证书库等，适合搭建企业级私服并进行二次配置，或离线安装使用。

1. 装了三天 Nexus 私服，最后发现是 8081 端口被占

Maven 私服这东西，小团队可能觉得用中央仓库就够了，但等你遇到内网构建超时、同一个 SNAPSHOT 依赖被反复下载、或者同事问你要一个公共仓库里没有的第三方 jar 时，就会意识到本地私服不是可选项而是必需品。Nexus 是这类工具里最常用的一个，而 3.45.0-01 这个版本在 Windows 上的安装套路和旧版有不少差异，装不好最常见的翻车点其实是端口冲突和内存配置，而不是 Nexus 本身。

这篇笔记会从版本选择开始，把下载、解压、启动、仓库配置、Maven 集成、以及我踩过的几个坑完整走一遍。适合正在 Windows 上给团队搭私服的开发者，也适合第一次接触 Nexus Repository Manager 3 的人照着做。我不讲太多概念，直接把能跑通的步骤和参数写清楚，你照着来就行。

2. 装之前先看明白的事：JDK 版本、目录结构和下载选择

2.1 3.45.0-01 到底需要什么环境

Nexus 3.45.0-01 是 Sonatype 在 2023 年发布的维护版本，它最大的变化之一是对 JDK 版本的要求更明确了。官方说它支持 JDK 8 和 JDK 11，但我实际在 Windows Server 2019 和 Windows 10 上都跑过，建议直接用 JDK 11，因为 3.45 系列对 JDK 8 的支持虽然没删，但某些安全相关的特性会需要更高版本。

一个容易忽略的点：Nexus 3.45.0-01 的 Windows 版 zip 包内嵌了它自己运行时需要的 Jetty 容器和相关依赖，所以你不必预先安装 Tomcat，也别试图把它丢进已有的 Tomcat 里跑，它是独立的应用。你只需要装一个 JDK，然后设置 JAVA_HOME 环境变量就行。

内存方面，默认会占用较多，后面我会讲到怎么调。如果没有特殊要求，不要在 PATH 里同时混入 JDK 8 和 JDK 11，因为我遇到过 Nexus 启动时读到了错误的 Java 版本导致 Jetty 起不来，这种事很玄学，但确实会发生。

2.2 下载哪个包，zip 和 exe 怎么选

3.45.0-01 在 Windows 有两个版本：一个 zip 压缩包，适合绿色解压、改配置、做多实例；另一个 exe 安装程序，会把 Nexus 注册成 Windows 服务。如果你只是在开发机上临时用，我建议用 zip 包，因为它不污染系统服务列表，删掉目录就算卸载干净了。如果是给团队做正式私服，建议用 exe 方式安装，能开机自启，断电重启后不用手动去点启动脚本。

不管选哪个，下载时注意文件名里的平台标识，nexus-3.45.0-01-win64 是 64 位版本，如果你的系统是 32 位的，请去找对应的 win32 版本。下载完成后先校验一下文件哈希，官方页面会给出 SHA-1 或 SHA-256，用 PowerShell 的 Get-FileHash 对比一下比较稳。

2.3 解压后目录里每个文件夹是干什么的

zip 包解压后会出现两个并列的目录，这是很多人第一次用会搞混的地方。一个是 nexus-3.45.0-01，里面是程序本体；另一个是 sonatype-work，里面才是你的仓库数据、配置、日志。这两个目录必须放在同一级，启动脚本会按照相对路径去寻找 sonatype-work，如果你只拷贝了 nexus 目录而漏掉了 sonatype-work，启动时会报错说找不到 work 目录。

sonatype-work/nexus3 下面有几个关键子目录：etc 存放配置文件，log 存放日志，blobs 存放你上传的构件内容，db 是 OrientDB 数据库。日常备份私服数据时，只需要把 sonatype-work 整个目录打包即可，程序本体丢了重新解压一个就行，数据才是真正不能丢的。

3. 安装 Nexus 3.45.0-01：从解压到服务化的完整步骤

3.1 用 zip 包手动安装的步骤

假设你下载的是 nexus-3.45.0-01-win64.zip，我习惯把它解压到 D 盘的根目录下，比如 D:\nexus，这样路径短一些，避免后面配置文件中出现很长的 Windows 路径导致转义问题。

# 打开 PowerShell，进入解压后的 bin 目录 cd D:\nexus\nexus-3.45.0-01\bin # 前台启动 Nexus，便于观察启动日志 .\nexus.exe run

第一次启动强烈建议用 run 参数在前台跑，而不是直接双击启动脚本。原因很简单：如果启动过程中报错，前台模式会把错误信息直接打在控制台里，你能一眼看到是端口问题还是 JVM 参数问题。后台模式会把错误写进日志文件，排查时多一步操作。

看到类似Started Sonatype Nexus OSS 3.45.0-01的日志后，说明启动成功。此时浏览器访问 http://localhost:8081，就能看到 Nexus 的页面了。注意第一次启动会比较慢，因为要初始化数据库和内置仓库，这个初始化过程可能需要一到三分钟，别急着关掉窗口。

3.2 注册成 Windows 服务的方法

如果是给团队用的正式环境，我一般会注册成 Windows 服务。

# 在 bin 目录下执行，把 Nexus 安装为 Windows 服务 .\nexus.exe install # 启动服务 .\nexus.exe start # 查看服务当前状态 .\nexus.exe status

install 命令执行后，可以去 Windows 服务管理器里看到名为 nexus 的服务，会设置为自动启动类型。这个服务运行时会以后台方式拉起 Nexus，日志会写到 sonatype-work/nexus3/log 目录。

还有两个运维时常用的命令值得记一下：.\nexus.exe stop停止服务，.\nexus.exe uninstall卸载服务。注意卸载服务不会删除 sonatype-work 里的数据，如果想彻底清掉私服，需要手动删目录。

3.3 修改默认端口和绑定地址

Nexus 默认只监听 8081 端口，如果机器上已经有别的程序占用，或者你希望它监听特定 IP，需要改配置文件。配置文件位置在 nexus-3.45.0-01\etc\nexus-default.properties，修改前先停止服务或进程。

# 监听端口，改成 8082 可以避开冲突 application-port=8082 # 绑定地址，0.0.0.0 表示所有网卡可访问 application-host=0.0.0.0 # 上下文路径，一般保持根路径 nexus-context-path=/

application-host 这个参数要看场景。如果只是本机开发用，填 127.0.0.1 更安全；如果是团队内网使用，填 0.0.0.0 可以让别的机器通过 IP 访问。改完配置后必须重启服务才能生效，运行中的 Nexus 不会热加载这个文件。

4. 初始化配置：管理员密码、内置仓库和 Maven 集成

4.1 第一次登录时的 admin 密码在哪里

Nexus 3.45.0-01 首次启动后，admin 账号的初始密码不是默认的 admin123，而是随机生成的一个字符串，保存在 sonatype-work/nexus3/admin.password 文件里。这个设计是为了安全，但第一次用的人经常找不到密码在哪。

用文本编辑器打开 admin.password 文件，复制里面的完整字符串，然后在登录页面输入用户名 admin 和这串密码。登录成功后，系统会强制要求修改密码，此时可以设置成自己习惯的密码。修改完密码后，admin.password 文件会自动删除，这是正常现象，不用慌。

如果在修改密码前不小心关闭了浏览器，重新打开登录页再输入原随机密码就能继续。如果超过一段时间没有完成修改，那个文件可能已经消失，这时候最省事的办法是去 sonatype-work/nexus3/log 目录看看有没有报错，或者直接用 Nexus 提供的重置脚本。

4.2 内置仓库类型搞清楚再动手

登录后你会看到仓库列表，Nexus 3 内置了三种类型的仓库需要理解：proxy 类型是代理远程仓库的，比如代理 Maven Central；hosted 类型是自己托管的仓库，团队内部发布的私有构件放这里；group 类型是组合仓库，可以把多个 proxy 和 hosted 仓库合并成一个统一的访问地址。

默认配置里已经有一个 maven-central 的 proxy 仓库和一个 maven-releases、maven-snapshots 的 hosted 仓库，以及一个 maven-public 的 group 仓库。我见过不少人一上来就新建了一堆仓库，结果 Maven 配置里引了一堆地址，最后也不知道从哪下的依赖。

一个建议：先沿用默认的 maven-public 作为唯一对外地址，不要急着建新仓库。等到确实需要隔离权限或分项目管理时，再按照 maven-public 的模板复制创建，配置项可以参考默认值改。

4.3 配置阿里云代理仓库加速依赖下载

在国内网络环境下，直接代理 Maven Central 的速度通常不太理想。常见做法是新增一个 proxy 仓库，远程地址填阿里云的公共仓库地址，这样 Maven 依赖从阿里云镜像拉取。

在 Nexus 管理界面中找到仓库管理，新建一个 proxy 类型的仓库，Repository Format 选择 maven2，Remote Storage 填阿里云的 Maven 仓库地址，然后把这个新仓库加入 maven-public 的成员列表里，顺序放在 maven-central 前面，这样会优先走阿里云。

这种配置在团队里的价值很明显：只要私服上缓存过某个依赖，后续构建就不会重复访问公网，内网构建速度会快很多。SNAPSHOT 依赖的更新策略也可以在仓库配置里调整，默认的 daily 更新策略对日常开发通常是够的。

4.4 Maven 的 settings.xml 怎么指向私服

客户端的配置要修改 Maven 安装目录下 conf 文件夹里的 settings.xml，或者在用户目录下的 .m2 文件夹里建一个 settings.xml。嫌麻烦的话我一般直接改用户目录那份，这样不影响 Maven 安装目录的全局配置。

<mirrors> <mirror> <id>nexus</id> <mirrorOf>*</mirrorOf> <name>Nexus Mirror</name> <url>http://你的服务器IP:8081/repository/maven-public/</url> </mirror> </mirrors>

mirrorOf 配置成星号表示所有依赖都走私服，这种情况下哪怕你项目里配置了别的仓库地址，也会被 Nexus 接管。url 一定要填 group 仓库 maven-public 的地址，而不是某个 proxy 仓库的地址，这一点至关重要，填错了构建时会报 401 或 404 错误。

如果私服设置了匿名访问权限，这个配置就够了，不用配认证信息。如果关闭了匿名访问，还需要在 settings.xml 的 servers 节点里加上对应 server 的账号密码。

<servers> <server> <id>nexus</id> <username>admin</username> <password>你的密码</password> </server> </servers>

注意 server 的 id 必须和 mirror 中的 id 一致，否则 Maven 不会自动带上认证信息。

5. 避坑指南：我这几天踩过的四个高频坑

5.1 启动后页面一直打不开，端口是通的但没反应

现象：使用nexus.exe start启动后再访问 8081 端口，浏览器一直转圈，或者显示连接被重置。查看进程发现 Java 进程确实存在。

原因：后台模式下 Nexus 启动需要时间，特别是在首次初始化数据库时。另外 3.45.0-01 在 Windows 上启动时会做一堆文件权限检查，如果解压目录在 Program Files 下，会因为权限不足导致 Jetty 绑定端口失败但进程还在。

解决：先停止服务，把 Nexus 目录移动到没有权限限制的路径下，比如 D:\nexus 或 C:\nexus。然后改用nexus.exe run前台模式看启动日志，确认出现 Started 字样后再去访问页面。从那以后我每次启动新环境都用 run 模式先确认能跑起来，再切换成服务方式。

5.2 修改 admin 密码后登录提示凭据错误

现象：第一次登录时提示修改密码，设置完新密码后立刻退出，再次登录时显示用户名或密码错误。

原因：Nexus 3.45 的密码修改机制是先登录到强制改密页面，设置新密码后需要等会话刷新完成。如果设置完看到成功提示就立刻关闭页面，旧会话可能还没完全失效，新密码又因为某些原因没写进用户存储。

解决：建议修改密码后不要马上退出，先进入仓库管理页面确认能正常访问，再用新密码重新登录测试。如果确实出现新密码无法登录的情况，可以删除 sonatype-work 下相关用户数据后重启，或者恢复 admin.password 文件后重新走初始化流程。

5.3 上传第三方 jar 包时提示 413 或请求体过大

现象：通过管理界面上传一个较大的 jar 包，比如 200MB 的 SDK 包，上传过程中提示请求体过大，上传失败。

原因：Jetty 默认对 HTTP 请求体大小有限制，Nexus 自身也有文件大小限制参数。管理界面走的是 HTTP 协议，大文件容易触发这个限制。

解决：对于大文件，我一般不会走管理界面，而是用 Maven 的 deploy 命令上传。执行mvn deploy:deploy-file指定仓库地址和文件路径，命令行方式不走 HTTP 表单上传，限制少很多。这个操作比界面点来点去可靠很多，也方便写进脚本批量上传。

5.4 其他机器的 Maven 构建连不上私服

现象：私服所在机器本地访问正常，但局域网内另一台机器配置了镜像地址后构建报 connection refused 或 timeout。

原因：八成是 Nexus 监听地址还是默认的 127.0.0.1，只在本地回环地址上监听，其他机器当然连不上。

解决：检查 nexus-default.properties 里 application-host 是否为 0.0.0.0，改完重启服务。顺带确认 Windows 防火墙有没有放行 8081 端口的入站规则，这个漏了也会导致外部访问超时。

6. 最终验证：这套私服到底能不能正常干活

装完环境后，我会习惯性地跑一遍完整验证流程，而不是只看管理页面能打开就收工。管理页面能打开只说明 Nexus 这个程序起来了，Maven 构建能正常拉取和上传依赖才是私服真正能用的证明。

第一步验证客户端下载依赖。找一台干净环境的机器，在 settings.xml 中配好镜像地址后执行一个最简单的 Maven 项目构建：

mvn clean compile

执行过程中观察控制台日志，确认 Maven 是从私服拉取依赖而不是直连中央仓库。构建完成后再去 Nexus 管理界面的 maven-central 仓库里找刚才下载的构件，如果能看到缓存记录，说明 proxy 功能正常。这一步同时验证了 8081 端口通不通、认证信息对不对、group 仓库聚合是否有效。

第二步验证内网构建提速效果。同一台机器上第二次执行mvn clean compile，构建时间应该明显缩短，因为依赖已经缓存在私服本地了。这个对比能直观说明私服的价值，也方便你向团队汇报效果。

第三步验证 hosted 仓库的上传功能，也就是 mvn deploy 流程。在项目 pom.xml 中配置好 distributionManagement 节点，指向 maven-releases 或 maven-snapshots 对应地址，然后执行：

mvn deploy

执行成功后去 maven-releases 仓库里看有没有出现你上传的 jar 包，然后新建一个依赖这个 jar 的测试项目，确认能从私服拉取到刚上传的构件。这一步验证的是团队内部私有构件的发布和消费链路，如果平时不用 deploy 也可以跳过。验证完这三步，这套私服才算真正达到了可以投入使用的水准。从那以后我每次搭建或迁移 Nexus，都会强制自己把这三步走一遍，确认没有遗漏配置再安心交付给团队。希望这篇笔记能帮到你节省排查时间。

本文还有配套的精品资源，点击获取