简介Jexus 7.1.x 是为 64 位 Linux 环境准备的高性能 Web 服务器与负载均衡网关安装包主要面向需要在 Linux 上运行 ASP.NET 应用、或希望构建高并发服务分发体系的开发者和运维人员。该版本重点支持 ASP.NET 生态同时也能反向代理多个后端服务适合做站点迁移或分布式部署时的服务器层组件。资源包共包含 545 个文件压缩后约 41.71MB其中 443 个 dll 构成 .NET 应用运行所需的程序集12 个 so 动态库提供 Linux 底层依赖另有 exe 可执行程序、config/conf 配置文件以及 aspx 示例页面属于解压后即可部署的完整方案。内置的 so 库覆盖图形处理、加密协议等常见依赖有助于降低环境配置成本。已有 119 人学习下载适合希望快速搭建 Linux ASP.NET 实验环境、评估 Jexus 负载均衡能力或研究其内部结构的读者通过解压包内文件可以直观了解服务器组件的组成方式并据此调整配置、部署自己的网站或反向代理场景。 看到jexus-7.1.x-x64.tar.gz这个文件名估计很多常年混 Linux 服务器的人都会心一笑这不就是那个专门为 .NET Core 量身定做的国产 Web 服务器吗只要你在腾讯云或阿里云的小机器上解压过这个包基本上就知道它是一个不依赖其他组件、装完就能跑的精简运行时。这篇文章我以一个老用户的身份把这个 tar.gz 包背后的部署思路、配置细节和踩坑记录完完整整梳理一遍给正准备尝试或者已经在用 Jexus 的朋友一份能直接照着做的参考。1. 这个tar.gz包到底解决了什么问题1.1 Jexus在Web服务器里是个什么角色Jexus 是一款运行在 Linux/Unix 系统上的 Web 服务器最核心的卖点就是和 ASP.NET Core也包括基于 Mono 的老 ASP.NET MVC结合得非常紧。很多小团队在服务器选型阶段就两个候选Nginx 或者 Jexus。Nginx 本身不执行 .NET 代码你想跑 .NET Core 应用就得让 Kestrel 先监听一个内网端口再用 Nginx 做反向代理把请求转发过去链路是两层。Jexus 的优势在于它可以少一层它能把 HTTP 请求直接交给 ASP.NET Core 应用处理少一层就意味着少一个可故障点配置项也更少对非专业运维出身的人来说非常友好。我个人的理解是Jexus 本质上就想做 Linux 上的 IIS它知道 .NET 应用需要什么所以把路由、进程管理、请求转发这些整合到一个进程里。你用 Nginx 的时候要自己到处查location 怎么配才能把动态请求转发给 Kestrel而 Jexus 的默认配置往往已经能跑通你只需要改改端口和域名。这一点对刚把 .NET 应用搬上 Linux 的团队来说省掉的不只是几小时配置时间还有排查联调时的心力。1.2 为什么选7.1.x而不是更早的5.x/6.xJexus 早期版本是依赖 Mono 的跑老 ASP.NET 项目还行但 .NET Core 出来以后Mono 这条线就显得很鸡肋。7.x 版本把 Mono 依赖彻底去掉核心逻辑专门面向 ASP.NET Core 重写启动速度更快内存占用也降下来了非常适合 2C4G 这种常见的小规格云服务器。我之前在 5.x 版本上部署过一个老项目光装 Mono 环境就折腾了半天一会儿缺依赖库一会儿中文编码不对。到了 7.x发布 .NET Core 应用之后直接把 tar.gz 包解压到服务器dotnet运行时本来就在系统里Jexus 这边根本不需要额外装组件。选型的时候只要判断你的应用是 .NET Core 2.x 以上就可以直接考虑 7.1.x不必再碰老版本。另外Jexus 7.x 的整个包压缩下来就几十MB对比全套 LNMP 那一堆依赖小了不止一个量级这也符合现代运维轻量优先的思路。2. 部署之前先把架构和包体检查这关过了2.1 确认服务器架构x64还是ARM64文件名里明确写了 x64对应的是 AMD64 架构在 Linux 下通常显示为x86_64别当成通用包。拿到服务器第一件事就是跑这条命令uname -m输出如果带x86_64或者amd64就说明这份 tar.gz 包可以直接用。最近 ARM 架构的云主机越来越流行服务商会给你分配aarch64的机器这时候就不适合装 x64 的包需要找官方提供的 ARM 版本。另外顺带看一眼发行版CentOS 7、Ubuntu 16.04、Debian 9 这些常见环境我都装过没遇到什么坑但如果你用的是比较偏门的发行版建议先看下官方文档的兼容列表。2.2 解压前的包体校验与目录规划tar.gz 是先把目录结构用 tar 打包再用 gzip 压缩所以也要在 Linux 环境里解压。Windows 上虽然也可以用 7-Zip 打开但解压出来的文件经常丢失 Unix 权限位导致后面 install 脚本报错。下载完包以后不要急先校验一下完整性最简单的办法是看 MD5 或 SHA256md5sum jexus-7.1.x-x64.tar.gz sha256sum jexus-7.1.x-x64.tar.gz我早期踩过一次坑下载过程中断包解压到一半报错我还以为是版本 bug折腾了好久才反应过来文件本身是坏的。从那以后我养成一个习惯任何 tar.gz 包拿到手先验一次再解压。路径规划上建议把安装包放在/opt或/usr/local/src这类约定俗成的软件源码目录解压出来的目录名别改安装脚本通常会用它来定位文件。3. 从解压到HTTPS完整安装配置记录3.1 安装脚本与目录结构把包放到/opt下然后执行cd /opt tar -zxvf jexus-7.1.x-x64.tar.gz cd jexus-7.1.x-x64 sudo ./installinstall 脚本会把运行文件放到/usr/jexus下同时生成启动脚本和服务配置。安装完成后/usr/jexus目录里最重要的东西有这几个jws是主管理程序所有启停操作都靠它siteconf存放站点配置每个站点一个文件文件名就是站点名log是日志目录线上出问题时第一现场。日常管理服务就三条命令sudo /usr/jexus/jws start sudo /usr/jexus/jws restart sudo /usr/jexus/jws status这里解释一下为什么安装到/usr/jexus而不是软件源的位置Jexus 的安装包自带了一套完整的运行形态它不希望和你系统里的包管理器打架。你把整个目录备份走就能原样迁移到另一台机器上这对快速扩容很有帮助。3.2 编写一个典型站点配置站点的配置文件都在/usr/jexus/siteconf目录默认有一个名为default的文件。我提供一个非常常见的生产配置示例port80 root/var/www/mysite hostsmydomain.com,*.mydomain.com processes2逐行说一下背后的设计逻辑port监听端口80 是默认 HTTP 端口。如果本机还跑着 Nginx 之类的服务要确保端口没冲突。root网站物理路径。Jexus 工作进程对这个目录必须有可执行权限不然访问时会出现 403 或 500。hosts域名绑定多个域名用英文逗号分隔支持通配符。很多人以为填了 IP 就能访问其实如果你用域名访问就必须把域名写进去这样 Jexus 才能按域名匹配站点。processes进程数。默认是 1多核服务器上可以调到 2 或 4 来提吞吐量。但要注意processes 调大的同时后端 Kestrel 端口也要有相应规划不能冲突。保存配置后执行一次sudo /usr/jexus/jws restart然后用 curl 试一下本机访问curl -I http://127.0.0.1如果返回 HTTP/1.1 200 OK说明站点配置已经生效接下来把域名解析指向这台服务器就行了。3.3 托管ASP.NET Core应用的正确姿势很多人第一次用 Jexus会误以为装了它就能直接跑 .NET Core 应用。其实 Jexus 只负责接收和处理 HTTP 请求ASP.NET Core 应用本身还是要通过 Kestrel 启动。也就是说服务器上需要先安装对应版本的 .NET 运行时然后把发布好的应用放到root指定的目录。比较标准的做法是应用目录内执行dotnet YourApp.dll让 Kestrel 监听本机某个端口比如 5000然后 Jexus 做反向代理把外部请求转发过去。对应的配置大致如下port80 hostsmydomain.com reproxy/,http://127.0.0.1:5000这条reproxy指令的意思是把来自 80 端口的请求全部转发给本机 5000 端口。对客户端来说整条链路是透明的用户只看到一个 80 端口并不知道后面还有 Kestrel 在跑。这里有个容易踩的点如果你在应用里配置了 HTTPS 重定向而 Jexus 这一层只是 HTTP很容易出现无限重定向的问题。正确的做法是把 TLS 的终结层和应用的判断逻辑对齐要么在 Jexus 层就启用 SSL要么关掉应用里的 HTTPS 强制跳转。我见过不少同事在这个问题上绕了很久最后发现是 Kestrel 那边强制跳转导致的。3.4 HTTPS与反向代理实践建议现在上 HTTPS 属于标配Jexus 7.x 本身支持直接挂证书配置对应端口和证书路径即可。但如果你的站点不止一个或者还想用 HTTP/2、更灵活地更新证书我更建议在前面放一层 Nginx 专门做 SSL 终结Nginx 把解密后的请求转发给 Jexus 的 HTTP 端口。这样证书续期、OCSP 装订等操作都可以复用成熟的 Nginx 生态Jexus 侧配置保持简单也方便后续扩容。我实践下来最舒服的组合是Nginx 监听 443配置 SSL 证书和 HTTP/2然后proxy_pass到 Jexus 的 80 端口。Jexus 只处理业务逻辑不关心证书。这种分层的好处是Jexus 升级或重启时Nginx 可以先返回一个维护页用户不会直接看到连接失败。4. 部署中的常见问题与排查技巧4.1 端口被占用的排查思路这是新手最常遇到的问题。Jexus 启动时提示Address already in use十有八九是 80 端口被 Nginx 或 Apache 占用。排查命令很简单ss -lnp | grep :80看到占用进程以后要么停掉它要么让 Jexus 换端口。我的原则是生产环境多个 Web 服务不要抢同一个端口最好统一由反代入口管理。比如 Nginx 占 80/443Jexus 只监听内网端口这样即便未来要扩容改的是 Nginx 的上游列表不用动 Jexus 配置。4.2 403和404的权限与路径问题访问站点时如果是 403先检查 root 目录权限。Jexus 工作进程需要能进入这个目录也就是执行权限。网上查到的命令大多建议chmod 755但实际生产环境我更推荐按用户授权给 Jexus 运行用户单独设置目录权限而不是无脑把目录打成 777。如果是 404先确认 root 路径是不是绝对路径再检查文件有没有放对位置。还有一个容易被忽略的点hosts 配置里没有包含你访问所用的域名。比如你在本机用curl http://127.0.0.1测试但配置里 hosts 只写了域名Jexus 按域名匹配不到站点也会返回 404。这时候把 hosts 改成*或者加上访问入口就能解决。4.3 反向代理502问题Jexus 做反代时核心故障是 502 Bad Gateway。这个状态码说明 Jexus 把请求转到后端 Kestrel但 Kestrel 没有响应。排查顺序很简单curl http://127.0.0.1:5000如果这条命令都返回失败那就是应用没起来或者监听的端口不对得去应用日志里看崩溃原因。如果本机能通但通过域名访问还是 502多半是 Jexus 转发目标写错了检查 reproxy 配置里的 IP 和端口是否匹配。还有一个相对少见的点后端应用启动特别慢Jexus 等待超时时间不够也会偶尔出现 502。遇到这种情况先看后端启动日志确认应用要多久才能就绪再决定要不要调整超时参数。4.4 快速排查对照表现象可能原因处理思路启动失败提示 Address already in use端口被占用用 ss 找到占用进程并处理或改 Jexus 端口访问返回 403 Forbiddenroot 目录权限不足给运行用户授权读和执行权限避免 777访问返回 404 Not Foundroot 路径错误或 hosts 未包含域名检查绝对路径和 hosts 绑定反向代理返回 502Kestrel 未启动或转发目标错误curl 验证后端再查 reproxy 配置500 Internal Server Error应用自身抛异常查 log 目录下的应用日志定位异常堆栈这张表是我每次帮同事处理 Jexus 问题时的基本路径90% 的情况都能在表里找到答案。剩下 10% 属于程序本身的 bug那就乖乖去翻日志别乱改配置。4.5 老用户的排查顺序建议遇到问题先别动手改配置按这套顺序来第一步看日志第二步测端口第三步改配置。Jexus 的日志在 log 目录下每个站点一个日志文件里面记录了访问状态码和错误信息。很多朋友一遇到问题就怀疑是 Jexus 的 bug直接重装其实回头翻日志几行字就能定位到是后端应用崩溃了还是某个路径没配好。另外提醒一句改配置之前先把原文件复制一份。Jexus 的站点配置是纯文本改起来非常方便但改错了恢复起来也麻烦。养成备份习惯尤其是线上环境这个习惯能帮你少踩非常多的坑。最后再分享一个小习惯每次升级 Jexus 前我都会先把/usr/jexus/siteconf整个目录备份出来然后在测试环境跑一周确认日志没有新增异常再上生产。Jexus 本身很稳但系统环境千差万别多备份一步总没坏处。这个 tar.gz 包我前后用了好几年从最初几 MB 的 v5.x 跟到现在的 7.x几乎每个版本都参与过测试。配置思路一直没变底层对 .NET 生态的支持则越来越顺滑。如果你也在 Linux 上部署 .NET Core 应用不妨拿这个包试一次应该会体会到解压即用的痛快感。本文还有配套的精品资源点击获取 Jexus 7.1 tar.gz部署全攻略：Linux下托管.NET Core应用的配置与排错
简介Jexus 7.1.x 是为 64 位 Linux 环境准备的高性能 Web 服务器与负载均衡网关安装包主要面向需要在 Linux 上运行 ASP.NET 应用、或希望构建高并发服务分发体系的开发者和运维人员。该版本重点支持 ASP.NET 生态同时也能反向代理多个后端服务适合做站点迁移或分布式部署时的服务器层组件。资源包共包含 545 个文件压缩后约 41.71MB其中 443 个 dll 构成 .NET 应用运行所需的程序集12 个 so 动态库提供 Linux 底层依赖另有 exe 可执行程序、config/conf 配置文件以及 aspx 示例页面属于解压后即可部署的完整方案。内置的 so 库覆盖图形处理、加密协议等常见依赖有助于降低环境配置成本。已有 119 人学习下载适合希望快速搭建 Linux ASP.NET 实验环境、评估 Jexus 负载均衡能力或研究其内部结构的读者通过解压包内文件可以直观了解服务器组件的组成方式并据此调整配置、部署自己的网站或反向代理场景。 看到jexus-7.1.x-x64.tar.gz这个文件名估计很多常年混 Linux 服务器的人都会心一笑这不就是那个专门为 .NET Core 量身定做的国产 Web 服务器吗只要你在腾讯云或阿里云的小机器上解压过这个包基本上就知道它是一个不依赖其他组件、装完就能跑的精简运行时。这篇文章我以一个老用户的身份把这个 tar.gz 包背后的部署思路、配置细节和踩坑记录完完整整梳理一遍给正准备尝试或者已经在用 Jexus 的朋友一份能直接照着做的参考。1. 这个tar.gz包到底解决了什么问题1.1 Jexus在Web服务器里是个什么角色Jexus 是一款运行在 Linux/Unix 系统上的 Web 服务器最核心的卖点就是和 ASP.NET Core也包括基于 Mono 的老 ASP.NET MVC结合得非常紧。很多小团队在服务器选型阶段就两个候选Nginx 或者 Jexus。Nginx 本身不执行 .NET 代码你想跑 .NET Core 应用就得让 Kestrel 先监听一个内网端口再用 Nginx 做反向代理把请求转发过去链路是两层。Jexus 的优势在于它可以少一层它能把 HTTP 请求直接交给 ASP.NET Core 应用处理少一层就意味着少一个可故障点配置项也更少对非专业运维出身的人来说非常友好。我个人的理解是Jexus 本质上就想做 Linux 上的 IIS它知道 .NET 应用需要什么所以把路由、进程管理、请求转发这些整合到一个进程里。你用 Nginx 的时候要自己到处查location 怎么配才能把动态请求转发给 Kestrel而 Jexus 的默认配置往往已经能跑通你只需要改改端口和域名。这一点对刚把 .NET 应用搬上 Linux 的团队来说省掉的不只是几小时配置时间还有排查联调时的心力。1.2 为什么选7.1.x而不是更早的5.x/6.xJexus 早期版本是依赖 Mono 的跑老 ASP.NET 项目还行但 .NET Core 出来以后Mono 这条线就显得很鸡肋。7.x 版本把 Mono 依赖彻底去掉核心逻辑专门面向 ASP.NET Core 重写启动速度更快内存占用也降下来了非常适合 2C4G 这种常见的小规格云服务器。我之前在 5.x 版本上部署过一个老项目光装 Mono 环境就折腾了半天一会儿缺依赖库一会儿中文编码不对。到了 7.x发布 .NET Core 应用之后直接把 tar.gz 包解压到服务器dotnet运行时本来就在系统里Jexus 这边根本不需要额外装组件。选型的时候只要判断你的应用是 .NET Core 2.x 以上就可以直接考虑 7.1.x不必再碰老版本。另外Jexus 7.x 的整个包压缩下来就几十MB对比全套 LNMP 那一堆依赖小了不止一个量级这也符合现代运维轻量优先的思路。2. 部署之前先把架构和包体检查这关过了2.1 确认服务器架构x64还是ARM64文件名里明确写了 x64对应的是 AMD64 架构在 Linux 下通常显示为x86_64别当成通用包。拿到服务器第一件事就是跑这条命令uname -m输出如果带x86_64或者amd64就说明这份 tar.gz 包可以直接用。最近 ARM 架构的云主机越来越流行服务商会给你分配aarch64的机器这时候就不适合装 x64 的包需要找官方提供的 ARM 版本。另外顺带看一眼发行版CentOS 7、Ubuntu 16.04、Debian 9 这些常见环境我都装过没遇到什么坑但如果你用的是比较偏门的发行版建议先看下官方文档的兼容列表。2.2 解压前的包体校验与目录规划tar.gz 是先把目录结构用 tar 打包再用 gzip 压缩所以也要在 Linux 环境里解压。Windows 上虽然也可以用 7-Zip 打开但解压出来的文件经常丢失 Unix 权限位导致后面 install 脚本报错。下载完包以后不要急先校验一下完整性最简单的办法是看 MD5 或 SHA256md5sum jexus-7.1.x-x64.tar.gz sha256sum jexus-7.1.x-x64.tar.gz我早期踩过一次坑下载过程中断包解压到一半报错我还以为是版本 bug折腾了好久才反应过来文件本身是坏的。从那以后我养成一个习惯任何 tar.gz 包拿到手先验一次再解压。路径规划上建议把安装包放在/opt或/usr/local/src这类约定俗成的软件源码目录解压出来的目录名别改安装脚本通常会用它来定位文件。3. 从解压到HTTPS完整安装配置记录3.1 安装脚本与目录结构把包放到/opt下然后执行cd /opt tar -zxvf jexus-7.1.x-x64.tar.gz cd jexus-7.1.x-x64 sudo ./installinstall 脚本会把运行文件放到/usr/jexus下同时生成启动脚本和服务配置。安装完成后/usr/jexus目录里最重要的东西有这几个jws是主管理程序所有启停操作都靠它siteconf存放站点配置每个站点一个文件文件名就是站点名log是日志目录线上出问题时第一现场。日常管理服务就三条命令sudo /usr/jexus/jws start sudo /usr/jexus/jws restart sudo /usr/jexus/jws status这里解释一下为什么安装到/usr/jexus而不是软件源的位置Jexus 的安装包自带了一套完整的运行形态它不希望和你系统里的包管理器打架。你把整个目录备份走就能原样迁移到另一台机器上这对快速扩容很有帮助。3.2 编写一个典型站点配置站点的配置文件都在/usr/jexus/siteconf目录默认有一个名为default的文件。我提供一个非常常见的生产配置示例port80 root/var/www/mysite hostsmydomain.com,*.mydomain.com processes2逐行说一下背后的设计逻辑port监听端口80 是默认 HTTP 端口。如果本机还跑着 Nginx 之类的服务要确保端口没冲突。root网站物理路径。Jexus 工作进程对这个目录必须有可执行权限不然访问时会出现 403 或 500。hosts域名绑定多个域名用英文逗号分隔支持通配符。很多人以为填了 IP 就能访问其实如果你用域名访问就必须把域名写进去这样 Jexus 才能按域名匹配站点。processes进程数。默认是 1多核服务器上可以调到 2 或 4 来提吞吐量。但要注意processes 调大的同时后端 Kestrel 端口也要有相应规划不能冲突。保存配置后执行一次sudo /usr/jexus/jws restart然后用 curl 试一下本机访问curl -I http://127.0.0.1如果返回 HTTP/1.1 200 OK说明站点配置已经生效接下来把域名解析指向这台服务器就行了。3.3 托管ASP.NET Core应用的正确姿势很多人第一次用 Jexus会误以为装了它就能直接跑 .NET Core 应用。其实 Jexus 只负责接收和处理 HTTP 请求ASP.NET Core 应用本身还是要通过 Kestrel 启动。也就是说服务器上需要先安装对应版本的 .NET 运行时然后把发布好的应用放到root指定的目录。比较标准的做法是应用目录内执行dotnet YourApp.dll让 Kestrel 监听本机某个端口比如 5000然后 Jexus 做反向代理把外部请求转发过去。对应的配置大致如下port80 hostsmydomain.com reproxy/,http://127.0.0.1:5000这条reproxy指令的意思是把来自 80 端口的请求全部转发给本机 5000 端口。对客户端来说整条链路是透明的用户只看到一个 80 端口并不知道后面还有 Kestrel 在跑。这里有个容易踩的点如果你在应用里配置了 HTTPS 重定向而 Jexus 这一层只是 HTTP很容易出现无限重定向的问题。正确的做法是把 TLS 的终结层和应用的判断逻辑对齐要么在 Jexus 层就启用 SSL要么关掉应用里的 HTTPS 强制跳转。我见过不少同事在这个问题上绕了很久最后发现是 Kestrel 那边强制跳转导致的。3.4 HTTPS与反向代理实践建议现在上 HTTPS 属于标配Jexus 7.x 本身支持直接挂证书配置对应端口和证书路径即可。但如果你的站点不止一个或者还想用 HTTP/2、更灵活地更新证书我更建议在前面放一层 Nginx 专门做 SSL 终结Nginx 把解密后的请求转发给 Jexus 的 HTTP 端口。这样证书续期、OCSP 装订等操作都可以复用成熟的 Nginx 生态Jexus 侧配置保持简单也方便后续扩容。我实践下来最舒服的组合是Nginx 监听 443配置 SSL 证书和 HTTP/2然后proxy_pass到 Jexus 的 80 端口。Jexus 只处理业务逻辑不关心证书。这种分层的好处是Jexus 升级或重启时Nginx 可以先返回一个维护页用户不会直接看到连接失败。4. 部署中的常见问题与排查技巧4.1 端口被占用的排查思路这是新手最常遇到的问题。Jexus 启动时提示Address already in use十有八九是 80 端口被 Nginx 或 Apache 占用。排查命令很简单ss -lnp | grep :80看到占用进程以后要么停掉它要么让 Jexus 换端口。我的原则是生产环境多个 Web 服务不要抢同一个端口最好统一由反代入口管理。比如 Nginx 占 80/443Jexus 只监听内网端口这样即便未来要扩容改的是 Nginx 的上游列表不用动 Jexus 配置。4.2 403和404的权限与路径问题访问站点时如果是 403先检查 root 目录权限。Jexus 工作进程需要能进入这个目录也就是执行权限。网上查到的命令大多建议chmod 755但实际生产环境我更推荐按用户授权给 Jexus 运行用户单独设置目录权限而不是无脑把目录打成 777。如果是 404先确认 root 路径是不是绝对路径再检查文件有没有放对位置。还有一个容易被忽略的点hosts 配置里没有包含你访问所用的域名。比如你在本机用curl http://127.0.0.1测试但配置里 hosts 只写了域名Jexus 按域名匹配不到站点也会返回 404。这时候把 hosts 改成*或者加上访问入口就能解决。4.3 反向代理502问题Jexus 做反代时核心故障是 502 Bad Gateway。这个状态码说明 Jexus 把请求转到后端 Kestrel但 Kestrel 没有响应。排查顺序很简单curl http://127.0.0.1:5000如果这条命令都返回失败那就是应用没起来或者监听的端口不对得去应用日志里看崩溃原因。如果本机能通但通过域名访问还是 502多半是 Jexus 转发目标写错了检查 reproxy 配置里的 IP 和端口是否匹配。还有一个相对少见的点后端应用启动特别慢Jexus 等待超时时间不够也会偶尔出现 502。遇到这种情况先看后端启动日志确认应用要多久才能就绪再决定要不要调整超时参数。4.4 快速排查对照表现象可能原因处理思路启动失败提示 Address already in use端口被占用用 ss 找到占用进程并处理或改 Jexus 端口访问返回 403 Forbiddenroot 目录权限不足给运行用户授权读和执行权限避免 777访问返回 404 Not Foundroot 路径错误或 hosts 未包含域名检查绝对路径和 hosts 绑定反向代理返回 502Kestrel 未启动或转发目标错误curl 验证后端再查 reproxy 配置500 Internal Server Error应用自身抛异常查 log 目录下的应用日志定位异常堆栈这张表是我每次帮同事处理 Jexus 问题时的基本路径90% 的情况都能在表里找到答案。剩下 10% 属于程序本身的 bug那就乖乖去翻日志别乱改配置。4.5 老用户的排查顺序建议遇到问题先别动手改配置按这套顺序来第一步看日志第二步测端口第三步改配置。Jexus 的日志在 log 目录下每个站点一个日志文件里面记录了访问状态码和错误信息。很多朋友一遇到问题就怀疑是 Jexus 的 bug直接重装其实回头翻日志几行字就能定位到是后端应用崩溃了还是某个路径没配好。另外提醒一句改配置之前先把原文件复制一份。Jexus 的站点配置是纯文本改起来非常方便但改错了恢复起来也麻烦。养成备份习惯尤其是线上环境这个习惯能帮你少踩非常多的坑。最后再分享一个小习惯每次升级 Jexus 前我都会先把/usr/jexus/siteconf整个目录备份出来然后在测试环境跑一周确认日志没有新增异常再上生产。Jexus 本身很稳但系统环境千差万别多备份一步总没坏处。这个 tar.gz 包我前后用了好几年从最初几 MB 的 v5.x 跟到现在的 7.x几乎每个版本都参与过测试。配置思路一直没变底层对 .NET 生态的支持则越来越顺滑。如果你也在 Linux 上部署 .NET Core 应用不妨拿这个包试一次应该会体会到解压即用的痛快感。本文还有配套的精品资源点击获取