企业官网建设流程全解析

简介：用于搭建Maven私服的nexus-3.15.2-win64.rar压缩包，面向需要管理Java依赖仓库的开发、运维或架构师。在具备外网权限的Windows主机上部署后，可充当依赖中枢代理中央仓库与第三方源，解决开发人员频繁直连远程仓库造成的下载缓慢、带宽浪费与版本管理混乱等问题，省去每位成员重复等待远程拉取的时长，适合企业内网或团队协作场景。压缩包采用rar格式，整体约149.78MB，内含主程序及默认配置，基本无需额外依赖即可启动试用；使用者需具备Maven settings.xml与仓库组的基本认知。目前已有145人学习浏览，适用于从零搭建到生产配置的一站式需求。安装后可创建release、snapshot仓库组，配置代理策略与访问权限，并将各项目统一指向该私服地址，从而统一依赖管理、提升构建效率，也能更好地规范外部依赖的引入与版本策略。

1. nexus-3.15.2-win64.rar 是什么：一个包背后的私服基础设施

某个周二下午，mvn clean package卡在 “Downloading from central” 上十分钟，最后直接 timeout。老同事面无表情丢过来一个nexus-3.15.2-win64.rar，说解压跑起来，以后依赖都走它。这个 rar 解压后，就是 Sonatype Nexus Repository Manager 3.15.2 的 Windows 64 位运行包。多数人管它叫 Maven 私服，但它真正解决的不只是“下载变快”这件事：它给团队提供了一个内网二进制存档点，你半夜发布的 SNAPSHOT 不会因为 CI 机器重装就消失，中央仓库里某天被下线的构件也能从这里拿回来。

这篇文章写给被 Maven/Gradle 下载速度折磨的 Java 团队，也写给需要在内网统一管理 npm 包的前端和运维。新手可以照着从解压一路跑到接入构建工具，熟手建议直接跳到第 5 章避坑清单，那几条是我反复翻车后记下来的。

2. Nexus 3 的组件结构：几个必须先搞明白的概念

2.1 Repository 三兄弟：proxy、hosted、group 各管什么

在 Nexus 3.15.2 里新建仓库时，你会看到三种类型：proxy、hosted、group。刚上手的人最容易在这三个名字上绕进去，其实理解起来就一句话：

• proxy：给远程仓库做缓存转发。比如 maven-central，本地没有的依赖会从中央仓库拉一份，缓存在这台机器上，下次再有相同请求直接命中。
• hosted：私有托管仓库。团队内部封装的公共 jar、二次开发的 SDK、不想提交到中央仓库的三方包，都放这里。
• group：把多个 proxy 和 hosted 聚合到一个对外访问入口。下游只用一个地址，不用关心某个包到底在 central 还是 company-repo。

新手最常见的错误是直接把 proxy 仓库地址填进 Maven 的settings.xml。第一次构建确实能正常下载，但每次少个依赖都会去远程探测一遍，中央仓库一抖照样失败，而本地明明已经有缓存。Nexus 预置了一个maven-public的 group，聚合了 maven-central 和两个 hosted 仓库，所以接入 Maven 时直接用maven-public这个地址就好。

如果你以前玩过 Nexus 2.x，会发现 3.x 的思路更接近插件化。每种 format（maven2、npm、raw、nuget）都有自己的代理配置和页面，仓库建好后在 UI 里能看到对外的仓库地址。3.15.2 的 UI 虽然比新版朴素，但该有的东西都在。

2.2 Blob Store 与数据目录：构件在磁盘上怎么落

2.x 时代，构件按仓库分目录躺在文件系统里，目录结构就是给人看的。3.x 改成了 blob 存储，所有构件被抽象成二进制块，元数据交给数据库索引。在 Windows 上解压nexus-3.15.2-win64.rar后，你首先看到的是安装目录，首次启动后会自动生成一个sonatype-work目录，默认的 File Blob Store 就在sonatype-work/nexus3/blobs下面。

为什么要改成 blob？因为仓库数量多了以后文件数量巨大，传统目录结构在删除、迁移、快照备份时都很痛苦，blob 方式迁移起来更像“搬一个整体”。3.15.2 里可以在 UI 的 Settings → Blob Stores 里再建一个 File 类型的 store，指定放到 D 盘或独立数据盘，之后新建仓库时把 Blob Store 指过去。

提示：blob store 建好之后，仓库可以改指向别的 store，但旧构件不会自动搬过去。初始化之前就要把磁盘路径规划好。

2.3 为什么 3.15.2 是 3.x 里一个值得落地的版本

现在官方主推的 Nexus 版本通常更新到 3.4x、3.5x 甚至更高，回头来看 3.15.2，它在两个问题上特别稳：一是配置还在etc目录下，改端口、改 context-path 直接编辑etc/nexus.properties再重启就生效；二是对 Maven 格式的处理很成熟，预置的 maven-central、maven-releases、maven-snapshots、maven-public 开箱即用。

更晚的版本把部分配置移到了 data 目录，网上大量“修改 nexus.properties 改端口”的旧教程在新版本上失效，而 3.15.2 恰好卡在这个分界点之前，教程匹配度很高。如果团队还在用 Nexus 2.x，或者这是第一次装私服，3.15.2 是一个足够老但足够稳的起点。新版本功能更多，但对老机器的要求也更高，3.15.2 在低配置 Windows 服务器上跑起来很轻盈。

3. 从下载安装到开机自启：在 Windows 64 位跑通 Nexus 3.15.2

3.1 解压前的准备：JDK 版本、路径规划与端口侦查

Nexus 3.15.2 需要 JDK 1.8 及以上，官方推荐 JDK 8。我一般直接装 OpenJDK 8u202，版本太新的 JDK 反而容易踩坑，这点后面避坑清单会细说。先检查环境：

java -version netstat -ano | findstr ":8081"

java -version确认 JDK 在位，netstat确认 8081 没被占用。8081 是 Nexus 默认端口，如果机器上已经跑着其他服务占了这个端口，后面会给你演一出“双击后一闪而过”的戏。

解压路径有讲究：不能带中文，不能带空格。比如D:\nexus-3.15.2-win64这种路径没问题，但D:\软件\nexus 3.15.2这种就会在启动脚本上翻车。rar 包解压完后，目录结构大致是bin、etc、lib、public，和官方 zip 包一致。

3.2 修改 nexus.properties：端口、主机和 context-path 三个必调参数

用编辑器打开etc/nexus.properties，默认内容大概是下面这个样子：

application-port=8081 application-host=0.0.0.0 nexus-context-path=/

这三个参数是部署时最常动的。application-port是访问端口，默认 8081，如果内网有约定俗成的端口规范就改掉；application-host填0.0.0.0表示监听所有网卡，别为了图安全改成127.0.0.1，否则局域网里其他机器的构建工具根本连不上这台私服；nexus-context-path是访问路径前缀，默认/就是http://localhost:8081/，如果公司要求挂在子路径下才改它。

提示：改 context-path 要慎重，改完后 UI 和所有仓库地址都会带上前缀，旧地址全部失效，本地settings.xml也得同步更新。

3.3 安装为 Windows 服务并拿到初始 admin 密码

第一次启动我不建议直接注册服务，先在前台跑，把日志看明白再说：

D:\nexus-3.15.2-win64\bin\nexus.exe /run

前台运行时日志会不断刷屏，主要日志在D:\nexus-3.15.2-win64\sonatype-work\nexus3\log\nexus.log。看到类似Started Sonatype Nexus OSS 3.15.2的字样，就说明启动成功。这时浏览器打开http://localhost:8081，应该能看到 Nexus 的 Web 界面。

确认能正常启动后，再安装为 Windows 服务：

D:\nexus-3.15.2-win64\bin\nexus.exe /install net start nexus

/install会把 Nexus 注册成名为nexus的 Windows 服务，之后开机自启，不再依赖当前登录的终端会话。net start nexus手动拉起服务，之后在 Windows 服务管理器里能看到它。

首次登录需要的 admin 初始密码不在 UI 上，而是写在一个临时文件里：

type D:\nexus-3.15.2-win64\sonatype-work\nexus3\admin.password

用admin加这个密码登录，系统会强制要求改密码。改完密码这个admin.password文件会自动删除。如果部署完后局域网内其他机器连不上，记得放行防火墙端口：

netsh advfirewall firewall add rule name="Nexus 8081" dir=in action=allow protocol=TCP localport=8081

这一步需要管理员权限运行命令提示符，很多团队私服能本机访问、别人访问不了，就是栽在防火墙规则上。

4. 私服接入 Maven 与 npm：settings.xml 和 .npmrc 的写法

4.1 Maven settings.xml 配 mirror：让中央仓库依赖彻底走内网

Nexus 装好只是第一步，构建工具接进来才算真正干活。Maven 的接入点有两个：一个是依赖下载，一个是依赖发布。

依赖下载靠settings.xml里的 mirror 配置。打开~/.m2/settings.xml，加一段：

<mirror> <id>nexus</id> <name>Nexus Repository Manager</name> <mirrorOf>*</mirrorOf> <url>http://192.168.1.20:8081/repository/maven-public/</url> </mirror>

mirrorOf写*表示把所有的远程仓库请求都指向 Nexus，这样 Maven 不会直接连中央仓库，全部走私服的maven-public这个 group。url里的 IP 要换成你 Nexus 所在机器的实际内网 IP，别写localhost，除非你确定本地 Maven 和私服在同一台机器上。

依赖发布需要在项目pom.xml里加 distributionManagement：

<distributionManagement> <repository> <id>nexus-releases</id> <url>http://192.168.1.20:8081/repository/maven-releases/</url> </repository> <snapshotRepository> <id>nexus-snapshots</id> <url>http://192.168.1.20:8081/repository/maven-snapshots/</url> </snapshotRepository> </distributionManagement>

然后在settings.xml里给仓库 id 配账号密码：

<server> <id>nexus-releases</id> <username>admin</username> <password>你改过的密码</password> </server>

这里有个容易忽略的细节：<server>里的<id>必须和 distributionManagement 里的<id>完全一致，Maven 是靠这个 id 去匹配账号的。改完之后跑mvn deploy，看到 BUILD SUCCESS，说明发布链路通了。

4.2 用 npm group 仓库做统一 registry

前端项目接入 Nexus 的逻辑和 Maven 一样，核心也是 group。先在 UI 的 Repository 里分别创建npm(proxy)仓库指向 npm 官方源，再建一个npm-hosted的 hosted 仓库，最后建一个npm-group的 group 仓库，把 proxy 和 hosted 都加进去。

接依赖时，项目的.npmrc配：

registry=http://192.168.1.20:8081/repository/npm-group/

这样npm install时依赖优先从私服缓存拿，私服没有才去官方源缓存一份。发布自己的 npm 包时，npm 的publish和 install 最好是两个 registry：

npm config set registry http://192.168.1.20:8081/repository/npm-hosted/ npm login npm publish

安装走 group，发布走 hosted。两件事分开，而不是把 proxy 地址拿去 npm publish，否则发布操作会直接打到远程源上去，这在团队协作里是灾难。

4.3 从构建日志和 UI 验证私服真的“拦截”到了

配置完成后怎么确认依赖真的走了私服而不是还在偷偷连外网？最简单的方法是看构建日志。Maven 构建时如果下载请求命中 Nexus，日志里会出现一行Downloaded from nexus，后面跟着具体 URL。

更狠一点的验证方式：先把内网到中央仓库的访问权限断开，再清空本地~/.m2/repository重新构建。如果能正常构建，说明所有依赖都从私服拿到了；如果构建失败，说明某个依赖还没被缓存进私服。在 UI 的 Search 里搜一下刚构建过的组件，能看到它们的来源和缓存状态，这就是私服价值的直观体现。

5. 踩了半年私服才换来的避坑清单

5.1 现象：双击 nexus.exe 一闪而过，服务起不来

第一次部署时很容易遇到这个场景：双击nexus.exe，窗口闪了一下就消失，以为没装上，再双击还是这样。

原因：通常不是“没装上”，而是启动过程报错后退出了。常见的原因有三个：JDK 版本不匹配、8081 端口被占用、解压路径里有中文或空格。窗口闪太快，你根本来不及看报错。

解决：不要双击，改用命令nexus.exe /run在前台跑。前台模式会把日志直接打到控制台，真正的报错信息会显示在窗口里，或者去sonatype-work\nexus3\log\nexus.log里看最后几行。排查顺序是：先确认java -version能输出，再确认 8081 没被占用，最后检查路径。我的经验是半数情况出在路径有中文上，Windows 下的脚本对路径里的非 ASCII 字符非常敏感，玄学一样。

5.2 现象：Maven 发布构件时返回 401 Unauthorized

mvn deploy跑到一半报 401，账号密码确认没错，UI 里也能正常登录。

原因：Nexus 的匿名访问权限默认只覆盖读取，对 hosted 仓库的写入操作是需要认证的。Maven 发布时用的是settings.xml里 server 节点的账号，但这个<id>和 pom 里 distributionManagement 的<id>如果对不上，Maven 就找不到对应账号，把请求当成匿名用户发出去。

解决：检查两处。第一，pom.xml里<repository>和<snapshotRepository>的<id>是否与settings.xml里<server>的<id>完全一致，大小写都算；第二，确认仓库本身没有在管理界面被设置成只读。这个坑特别容易在“复制粘贴别人的 pom 然后改 URL”时踩到。

5.3 现象：本机能打开私服页面，局域网其他机器连不上

这几乎是 Windows 部署私服的经典坑：同一台机器上用浏览器访问http://localhost:8081一切正常，换到隔壁工位的机器访问http://192.168.1.20:8081就是超时。

原因：Windows 防火墙默认拦住了入站 8081 端口，Nexus 自己又不会自动添加防火墙规则。很多人排查半天，最后发现是防火墙没放行。

解决：管理员身份运行命令提示符，执行前面写的netsh advfirewall firewall add rule那一行命令，放行 TCP 8081。顺手检查一下application-host是不是被改成了127.0.0.1，如果是，改成0.0.0.0再重启服务。

5.4 现象：依赖能拉但不能稳定访问，日志里出现大量超时

私服运行一段时间后，内网机器偶发拉取超时，重试又好了。去 UI 看 proxy 仓库，远程索引老在报错。

原因：proxy 仓库的远程超时配置太保守。Nexus 默认对远程仓库的连接和读取超时都设置得比较短，一旦中央仓库响应慢，私服也跟着超时，Cache 里没缓存过的构件就拉不下来了。

解决：在 UI 打开对应的 proxy 仓库配置，把 Connection timeout 和 Read timeout 适当调大。我一般设 30 秒连接、60 秒读取。这一步对公网链路质量不稳定的内网环境尤其重要，属于一次调完受益很久的参数。

5.5 现象：C 盘飘红，私服仓库页面加载越来越慢

默认安装时 sonatype-work 在安装盘，很多人直接装在 C 盘，仓库里的构件越来越多，C 盘空间被吃光，UI 也开始卡顿。这个不算程序 bug，但属于最常见的部署事故。

解决：UI 里新建一个指向数据盘的 Blob Store，然后把这个 Blob Store 分配给后续新建的所有仓库。已有的旧仓库没法一键迁移到新 store，所以最好从第一天就把默认的 Blob Store 路径指到数据盘。如果你的私服已经在 C 盘下长了很多构件，趁数据量还小及早导出迁移，等到卡到不能动再搬就晚了。

6. 进阶：备份与调优的两板斧

6.1 用拷贝与导出任务保住私服

Nexus 的数据不是只靠导出配置就能完整备份的，blob store 里躺着全部构建产物，最稳妥的离线备份方式是停服后直接拷贝整个sonatype-work目录：

net stop nexus Copy-Item D:\nexus-3.15.2-win64\sonatype-work E:\backup\nexus-work -Recurse net start nexus

然后可以把E:\backup\nexus-work打成压缩包存档。在线备份使用 Admin 里的 Export 任务，会生成一个包含配置和仓库元数据的 zip 包，但断电场景下不如停服拷贝完整。迁移到新机器时，把整个sonatype-work目录复制过去，再改一下新机器上的application-host等环境参数即可。

6.2 内存与线程参数：把私服的响应速度提起来

3.15.2 默认 JVM 堆是 1G，对小型团队够用，但构件多了之后搜索和索引会明显变慢。编辑bin\nexus.vmoptions，把这两个值调大：

-Xms4G -Xmx4G -XX:MaxDirectMemorySize=2G

-Xms和-Xmx都设成 4G，避免 JVM 动态伸缩带来的停顿；MaxDirectMemorySize是 Nexus 处理 IO 缓冲用的直接内存，2G 配给一般场景足够。你的服务器内存如果只有 8G，-Xmx就不要超过 4G，给操作系统和磁盘缓存留出余量。

最后聊一个我自己的习惯：部署 Nexus 之前，先写下三行笔记——端口多少、sonatype-work放在哪个盘、JDK 路径指向哪里。这听起来多余，但等半年后要升级迁移时，这三行字比任何 UI 截图都管用。希望帮到你。

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