当前位置：首页 > news >正文

Windows本地部署Jira并实现安全外网访问实战指南

news 2026/7/3 9:03:49

1. 项目概述：为什么要在 Windows 上本地部署 Jira 并打通外网访问

Jira 这个名字在研发、测试、项目管理团队里几乎等同于“事务管理”的代名词。但很多人一听到“部署 Jira”，第一反应是点开 atlassian.com，注册账号、选套餐、填信用卡——这确实是最快上手的方式。可现实里，我见过太多团队卡在这一步：财务流程走不通、数据合规红线碰不得、定制字段要改十次、权限模型和公司组织架构死活对不上。这时候，“本地部署”就不是备选方案，而是刚需。而标题里特意强调“Windows 版本”，恰恰戳中了国内大量中小企业的实际环境：服务器是 Windows Server 2019，运维同事最熟的是远程桌面和 PowerShell，连 Linux 基础命令都要查文档。这不是技术偏见，是真实的人力结构和历史包袱。

所谓“本地部署”，本质是把 Jira 的服务程序、数据库、附件存储全部装进你自己的物理机或虚拟机里，数据不出内网，配置完全自主。但光“本地”还不够——很多团队需要让外包测试人员提交 bug、让客户查看迭代进度、让异地协作的销售同步需求状态。这就引出了第二个关键动作：“实现外网访问”。它不是简单地把防火墙端口打开就完事，而是涉及 DNS 解析、反向代理、HTTPS 加密、身份认证加固等一系列连环操作。我去年帮一家做医疗 SaaS 的客户落地这个方案时，光是说服他们接受“用 Nginx 做反向代理而非直接暴露 Tomcat 端口”就花了整整两天会议。因为对方安全团队的 checklist 里第一条就是：“禁止任何应用服务器直面公网”。

标题里的“事务管理软件”四个字也值得拆解。Jira 的核心能力远不止是“写个 bug 单”：它能建多套工作流（比如研发用敏捷看板，客服用工单系统，法务用合同审批），能配复杂的权限方案（细粒度到“只能编辑自己创建的子任务”），还能通过插件接入 Confluence 做知识沉淀、连 Jenkins 做构建触发、接 Slack 推送状态变更。所以这次部署不是搭一个静态网站，而是为整个研发协作体系打地基。如果你正被“jira里面怎么写周报”这类问题困扰，说明你可能还没摸到 Jira 自动化能力的边——真正的周报，应该是每周一早八点自动从 Jira 导出 PDF 发到部门邮箱，而不是人工复制粘贴。

适合谁来参考这篇内容？第一类是 Windows 环境下的中小型企业 IT 管理员，你不需要会写 Java，但得懂 Windows 服务管理、IIS 或 Nginx 配置、SQL Server 安装；第二类是刚接手 Jira 运维的初级 DevOps 工程师，你可能熟悉 Linux，但面对客户那台跑着 Windows Server 2016 的老服务器时有点发怵；第三类是技术决策者，你想知道本地部署的真实成本——不是 Atlassian 官网标价，而是人力投入、维护复杂度、升级风险这些隐性账。接下来所有内容，都基于一台实测环境：Windows Server 2019 标准版（16GB 内存 / 4 核 CPU / 500GB SSD），全程不依赖 Docker，不使用 WSL2，所有组件原生 Windows 兼容。

2. 整体设计与思路拆解：为什么放弃云版、绕过 Docker、坚持原生 Windows

很多人看到“本地部署 Jira”，第一反应是拉个 Ubuntu 虚拟机，docker-compose up -d 一把梭。这在技术上完全可行，但放到国内企业真实场景里，会踩三个隐形大坑。我必须先说清楚为什么我们选择一条更“笨”但更稳的路。

第一个坑是Windows 生态的不可替代性。客户服务器上已经跑着 SQL Server 2017、Active Directory 域控、以及一套老旧但不能停的 .NET Framework 4.7.2 应用。如果硬上 Linux+Docker，意味着你要额外维护一套容器编排、处理 Windows 和 Linux 文件权限映射、调试跨平台日志路径（比如 Jira 默认日志写在 C:\Program Files\Atlassian\Jira\logs，而 Docker 卷挂载后路径变成 /var/atlassian/application-data/jira/logs）。我试过用 WSL2 模拟，结果发现 Windows 防火墙策略和 WSL2 的 iptables 规则会打架，某次安全扫描直接把 WSL2 的 eth0 网卡识别成“未知高危设备”。最终方案是：Jira 服务本身跑在 Windows 服务里，数据库用本地 SQL Server，反向代理用 Windows 原生 Nginx，所有路径、权限、日志都遵循 Windows 命名规范。这样运维同学双击“服务”管理器就能看到 Jira 进程状态，不用学新命令。

第二个坑是Atlassian 官方对 Windows 的支持态度。很多人不知道，Atlassian 官网文档里明确写着：“Jira Software 支持在 Windows Server 2012 R2 及更高版本上运行，但生产环境推荐使用 Linux”。这句话的潜台词是：Windows 版安装包、服务脚本、升级补丁都是官方提供的，不是社区魔改；但遇到冷门问题（比如 Windows 权限继承导致附件上传失败），官方技术支持可能会优先让你复现到 Linux 环境再受理。所以我们的设计原则是：用官方支持的路径，避开非标准操作。比如绝不手动修改 catalina.bat 里的 JVM 参数去适配 Windows 内存管理，而是用 Atlassian 提供的 config.bat 工具；数据库连接字符串严格按官方文档格式写，不加任何 Linux 风格的斜杠转义。

第三个坑是外网访问的安全闭环逻辑。标题里“实现外网访问”不是目的，而是手段。真正目标是：让外部人员能安全、可控、可审计地访问特定功能。如果直接把 Jira 的 8080 端口映射到公网，等于把后台管理入口、数据库连接池、甚至未授权的 REST API 全部暴露。我们采用四层过滤：第一层是云服务商（如阿里云）的安全组，只放行 443 端口；第二层是 Windows 防火墙，限制源 IP 段（比如只允许合作方固定出口 IP）；第三层是 Nginx 反向代理，强制 HTTPS、添加 Basic Auth 认证头、过滤恶意 User-Agent；第四层才是 Jira 自身的权限体系，比如给外包测试员分配“只读项目角色”，连“创建问题”按钮都不显示。这种层层递进的设计，比单纯“打开端口”多花三倍配置时间，但上线后半年没发生过一次未授权访问事件。

工具链选型上，我们放弃 Docker 是因为：Windows Server 2019 的 Docker Desktop 对 Hyper-V 依赖太重，而客户服务器上 Hyper-V 已被另一套虚拟化平台占用；放弃 IIS 是因为 IIS 的 URL 重写模块对 WebSocket 支持不稳定（Jira 的实时通知依赖 WebSocket），测试时发现页面刷新后通知图标一直转圈；最终选定 Nginx for Windows，原因很实在：它的 Windows 版本编译包是官方直接提供的，配置语法和 Linux 版完全一致，未来迁移到 Linux 时配置文件零修改。数据库选 SQL Server 而非 PostgreSQL，是因为客户已有 SQL Server 许可证，且 DBA 熟悉备份策略（每天凌晨全量 + 每小时日志备份），不用额外培训。

3. 核心细节解析与实操要点：Windows 环境下的关键避坑指南

在 Windows 上部署 Jira，表面看是下载安装包、点下一步，但真正决定成败的，是那些藏在安装向导背后的细节。我整理了过去三年踩过的 12 个高频坑，按发生阶段排序，每个都附带原理说明和实操验证方法。

3.1 Java 环境：别信“已安装 JDK”，必须亲手验证

Jira 8.x 要求 Java 11，9.x 开始要求 Java 17。但 Windows 服务器上常有多个 Java 版本共存：Oracle JDK、OpenJDK、甚至旧版 JRE。你以为 set JAVA_HOME=C:\Program Files\Java\jdk-17 就万事大吉？错。Jira 启动脚本（start-jira.bat）会优先读取注册表项 HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\CurrentVersion，而不是环境变量。我遇到过最诡异的案例：环境变量指向 jdk-17，但注册表里 CurrentVersion 是 1.8，结果 Jira 启动时报 “Unsupported Java version”，日志里却只显示 “Java version: 1.8.0_301”，根本没提注册表的事。

实操验证步骤：

以管理员身份打开 CMD，执行reg query "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment" /v CurrentVersion
执行java -version和%JAVA_HOME%\bin\java -version，对比输出是否一致
修改注册表：reg add "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment" /v CurrentVersion /t REG_SZ /d "17" /f
重启服务器（重要！注册表修改需重启生效）

提示：Jira 安装包自带 JRE，但官方明确不建议用于生产环境。必须用独立 JDK，并确保 JAVA_HOME 指向 JDK 根目录（含 bin、lib 子目录），而非 jre 子目录。

3.2 数据库配置：SQL Server 的 ANSI_NULLS 必须开启

Jira 要求 SQL Server 数据库启用 ANSI_NULLS 和 QUOTED_IDENTIFIER。很多 DBA 习惯用 SSMS 图形界面新建数据库，但默认设置里 ANSI_NULLS 是 OFF。后果是：Jira 初始化数据库时能成功建表，但插入第一条数据就报错 “Cannot insert the value NULL into column 'ID'”，因为 Jira 的自增主键生成逻辑依赖 ANSI_NULLS ON 的行为。

正确创建数据库的 T-SQL 脚本：

CREATE DATABASE [jiradb] ON PRIMARY (NAME = N'jiradb', FILENAME = N'D:\SQLData\jiradb.mdf') LOG ON (NAME = N'jiradb_log', FILENAME = N'D:\SQLData\jiradb_log.ldf') COLLATE SQL_Latin1_General_CP1_CI_AS; -- 关键：必须在此后立即执行 ALTER DATABASE [jiradb] SET ANSI_NULLS ON; ALTER DATABASE [jiradb] SET QUOTED_IDENTIFIER ON; -- 创建专用登录用户（非 sa） USE [master] CREATE LOGIN [jira_user] WITH PASSWORD = 'StrongPass@2024'; USE [jiradb] CREATE USER [jira_user] FOR LOGIN [jira_user]; EXEC sp_addrolemember 'db_owner', 'jira_user';

注意：不要用ALTER DATABASE [jiradb] SET ANSI_NULLS ON WITH NO_WAIT，NO_WAIT 在某些 SQL Server 版本下会报错。必须分步执行。

3.3 Windows 服务权限：Local System 还是专用账户？

Jira 安装向导默认用 Local System 账户运行 Windows 服务。这看似省事，但埋下两个雷：第一，Local System 无法访问网络共享路径（比如你把附件存储在 NAS 上）；第二，当 Jira 需要调用外部脚本（如发送邮件的 PowerShell 脚本）时，Local System 的环境变量和证书存储区与普通用户不同，常出现“找不到 smtp 证书”错误。

推荐方案：创建专用服务账户

在 Windows 服务器上新建本地用户svc_jira，密码永不过期
将该用户加入 “Performance Monitor Users” 和 “Event Log Readers” 组（便于监控）
在服务管理器中右键 Jira 服务 → 属性 → 登录 → 选择此账户
赋予C:\Program Files\Atlassian\Jira目录的“完全控制”权限（右键属性 → 安全 → 编辑）

实测心得：用专用账户后，Jira 的邮件通知成功率从 73% 提升到 100%，因为 SMTP 证书能正常加载。但切记：该账户不能是域管理员，最小权限原则。

3.4 文件路径陷阱：空格、中文、长路径的三重绞杀

Windows 路径里的空格是经典坑。Jira 安装向导默认路径是C:\Program Files\Atlassian\Jira，其中 “Program Files” 包含空格。某些插件（如 ScriptRunner）在解析 classpath 时会把空格当成分隔符，导致 “ClassNotFoundException”。更隐蔽的是中文路径：如果你把 Jira 安装到D:\项目管理\Jira，启动时 JVM 参数里的-Djira.home=D:\项目管理\Jira会被 Windows 命令行截断为-Djira.home=D:\项目，后续全崩。

终极解决方案：全部使用无空格、纯英文、短路径

安装路径：C:\jira
Jira Home 路径：D:\jira-home
数据库文件路径：D:\sql-data\jiradb.mdf

验证方法：启动 Jira 后，访问http://localhost:8080/secure/admin/ViewSystemInfo.jspa，检查 “JIRA Home” 和 “JIRA Installation” 路径是否与你设置的一致。不一致？立刻停止服务，修改C:\jira\conf\server.xml中的<Context docBase="..."和C:\jira\bin\setenv.bat中的JIRA_HOME。

3.5 外网访问的 HTTPS 强制跳转：Nginx 配置里的魔鬼细节

很多人以为 Nginx 配置 HTTPS 只是加个 ssl_certificate 就完事。但在 Windows 环境下，有两个 Windows 特有的坑：第一，Nginx for Windows 不支持ssl_protocols TLSv1.3（官方 issue #127），必须降级到TLSv1.2；第二，Windows 的时间同步机制可能导致 SSL 证书校验失败，因为 Nginx 依赖系统时间验证证书有效期，而 Windows 默认每 7 天同步一次时间，误差可能达 5 分钟。

安全的 Nginx 配置片段（nginx.conf）：

upstream jira_backend { server 127.0.0.1:8080; } server { listen 443 ssl; server_name jira.yourcompany.com; # Windows 时间同步兼容：放宽证书时间校验窗口 ssl_verify_client off; ssl_session_cache shared:SSL:10m; ssl_protocols TLSv1.2; # 禁用 TLSv1.3，避免 Windows 兼容问题 ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256; ssl_certificate C:/nginx/ssl/jira.crt; ssl_certificate_key C:/nginx/ssl/jira.key; location / { proxy_pass http://jira_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 关键：告诉 Jira 当前是 HTTPS，否则重定向会跳回 http:// proxy_set_header X-Forwarded-Port 443; proxy_set_header X-Forwarded-Proto https; } } # HTTP 强制跳转（注意：不是 rewrite，是 return） server { listen 80; server_name jira.yourcompany.com; return 301 https://$server_name$request_uri; }

注意：proxy_set_header X-Forwarded-Proto https;这行必须存在，否则 Jira 后台会认为请求是 HTTP，导致登录后重定向到 http:// 地址，浏览器报 “不安全连接”。这是 Windows 部署外网访问最常被忽略的一行。

4. 实操过程与核心环节实现：从零开始的完整部署流水线

现在进入实操阶段。以下步骤基于 Windows Server 2019，全程使用管理员权限的 PowerShell（非 CMD），所有路径、参数、命令均经实测验证。我会把每个环节拆解为“操作指令 + 原理说明 + 验证方法”，确保你能照着做，也能理解为什么这么做。

4.1 环境初始化：关闭干扰项，准备纯净土壤

在动手前，必须清理 Windows 系统里可能冲突的服务。这不是多此一举，而是血泪教训——我曾因 IIS 的 World Wide Web Publishing Service 占用 80 端口，导致 Nginx 启动失败，排查了 3 小时才发现。

PowerShell 初始化脚本（以管理员身份运行）：

# 1. 停止并禁用 IIS 相关服务（即使没装 IIS，也要检查） Get-Service | Where-Object {$_.Name -match "W3SVC|WAS|AppHostSvc"} | Stop-Service -Force Get-Service | Where-Object {$_.Name -match "W3SVC|WAS|AppHostSvc"} | Set-Service -StartupType Disabled # 2. 检查 8080 和 443 端口占用 netstat -ano | findstr :8080 netstat -ano | findstr :443 # 3. 如果被占用，查 PID 对应进程 # tasklist | findstr "PID号" # 4. 关闭 Windows 防火墙临时规则（部署完成后重新配置） Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled False # 5. 创建必要目录结构 New-Item -ItemType Directory -Path "C:\jira", "D:\jira-home", "C:\nginx", "C:\nginx\ssl" -Force

原理说明：Windows Server 默认启用 IIS 相关服务，它们会监听 80/443 端口。即使你没装 IIS，这些服务也可能被其他软件（如 Skype）意外启用。Set-NetFirewallProfile关闭防火墙是为了一次性排除网络策略干扰，部署完成后再精细化配置。

验证方法：执行netstat -ano | findstr :8080应无输出；执行Get-Service W3SVC应返回 “Stopped” 状态。

4.2 Java 与 JDK 部署：用 PowerShell 自动化安装

手动下载 JDK 安装包、点下一步、配环境变量，效率低且易出错。我们用 Chocolatey（Windows 的包管理器）自动化安装 OpenJDK 17。

PowerShell 安装 JDK 步骤：

# 1. 安装 Chocolatey（如果未安装） Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1')) # 2. 安装 OpenJDK 17 choco install openjdk17 -y # 3. 设置 JAVA_HOME（Chocolatey 会自动设好，但需验证） $env:JAVA_HOME = "C:\Program Files\OpenJDK\openjdk-17.0.1_12" [System.Environment]::SetEnvironmentVariable('JAVA_HOME', $env:JAVA_HOME, 'Machine') # 4. 验证 java -version javac -version

原理说明：Chocolatey 安装的 JDK 会自动注册到 Windows 注册表，且路径不含空格（C:\Program Files\OpenJDK\...），完美避开路径陷阱。SetEnvironmentVariable用'Machine'参数确保系统级生效，而非仅当前会话。

验证方法：打开新 PowerShell 窗口，执行echo $env:JAVA_HOME，应输出C:\Program Files\OpenJDK\openjdk-17.0.1_12；执行java -version应显示openjdk version "17.0.1"。

4.3 Jira 安装与数据库连接：图形化向导的隐藏开关

Jira 官网下载 Windows Installer（.exe 格式），但安装过程中有两个关键选项必须手动干预：

安装类型选择 “I will set it up myself”：不要选 “Set it up for me”，后者会强行用 H2 内置数据库，无法对接 SQL Server。
数据库配置页，点击 “Configure Database” → “SQL Server” → “Direct JDBC connection”：这里必须手动输入 JDBC URL，不能用向导自动生成。

正确的 SQL Server JDBC URL 格式：

jdbc:sqlserver://localhost:1433;databaseName=jiradb;encrypt=false;trustServerCertificate=true;sendStringParametersAsUnicode=false;

为什么参数这么写？

encrypt=false：SQL Server 默认不启用加密，设 true 会报 “The driver could not establish a secure connection”。
trustServerCertificate=true：跳过证书验证，适用于自签名证书环境（开发/测试）。
sendStringParametersAsUnicode=false：Jira 8.x+ 的已知 Bug，设 true 会导致中文字段乱码（官方 KB 文章 JRASERVER-72101）。

验证方法：安装完成后，启动 Jira 服务，在浏览器访问http://localhost:8080，应看到 Jira 配置向导页面。输入管理员账户后，进入 “System Info” 页面，检查 “Database Type” 是否为 “Microsoft SQL Server”。

4.4 Nginx 反向代理配置：Windows 版本的启动与守护

Nginx for Windows 没有服务管理器，需手动注册为 Windows 服务。我们用 NSSM（Non-Sucking Service Manager）工具实现。

NSSM 配置 Nginx 服务步骤：

下载 nssm.exe（官网 nssm.cc），放入C:\tools\nssm.exe
以管理员身份运行 CMD：

C:\tools\nssm.exe install nginx

在弹出窗口中填写：
- Path:C:\nginx\nginx.exe
- Startup directory:C:\nginx
- Service name:nginx
- Service description:Nginx reverse proxy for Jira
点击 “Install service”

Nginx 启动与验证：

# 启动服务 Start-Service nginx # 检查服务状态 Get-Service nginx | Select-Object Status, Name # 检查 Nginx 是否监听 443 netstat -ano | findstr :443

原理说明：NSSM 是 Windows 服务封装的标准工具，比自己写 bat 脚本可靠得多。它能捕获 Nginx 的 stdout/stderr 日志，当 Nginx 崩溃时自动重启，符合生产环境要求。

验证方法：访问http://localhost，应看到 Nginx 默认欢迎页；访问https://localhost（忽略证书警告），应看到 “502 Bad Gateway”，证明 Nginx 已启动但后端 Jira 未连通。

4.5 外网访问打通：DNS、SSL 证书与安全组的三方协同

外网访问不是单点配置，而是 DNS 解析、云服务商安全组、本地防火墙的三角联动。

具体操作清单：

DNS 解析：在你的域名服务商（如阿里云 DNS）添加 A 记录：
- 主机名：jira
- 记录值：你的服务器公网 IP（如123.123.123.123）
- TTL：600 秒（便于快速回滚）
云服务商安全组（以阿里云为例）：
- 入方向规则：端口443，协议TCP，授权对象0.0.0.0/0（或限定合作方 IP 段）
- 出方向规则：全放开（Jira 需要访问邮件服务器、更新检查等）
Windows 防火墙入站规则：

# 创建新规则 New-NetFirewallRule -DisplayName "Allow HTTPS for Jira" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow -Profile Domain,Private,Public

SSL 证书获取（使用 Let's Encrypt）：
- 下载 win-acme（Windows ACME 客户端）
- 运行wacs.exe --target manual --host jira.yourcompany.com --validation dns-01
- 按提示在 DNS 添加 TXT 记录，等待验证通过
- 证书自动存入C:\windows\system32\certsrv\certificates\

关键验证点：

在手机 4G 网络下访问https://jira.yourcompany.com，应能打开 Jira 登录页
使用 SSL Labs（ssllabs.com）检测，评级应为 A 或 A+
查看浏览器地址栏，应显示绿色锁图标，证书颁发者为 “Let's Encrypt”

实操心得：DNS 解析生效通常需 5-30 分钟，不要一添加就刷新。用nslookup jira.yourcompany.com命令确认解析已生效。如果解析正确但打不开，90% 是安全组或防火墙没放行 443 端口。

5. 常见问题与排查技巧实录：来自真实生产环境的故障快查表

部署不是一锤子买卖，上线后的日常运维才是重点。我把过去两年处理过的 15 个典型问题，按发生频率排序，每个问题包含“现象描述 → 根本原因 → 三步排查法 → 永久修复”。

5.1 问题：Jira 启动后页面空白，F12 控制台报 “Failed to load resource: net::ERR_CONNECTION_REFUSED”

现象：访问http://localhost:8080显示空白页，浏览器开发者工具 Network 标签页里所有 JS/CSS 请求状态为(failed)。

根本原因：Jira 服务进程已启动，但 Tomcat 嵌入式服务器未真正监听 8080 端口。常见于 JVM 内存不足（Windows 默认只分配 512MB），导致 Tomcat 初始化超时退出。

三步排查法：

检查 Windows 服务状态：Get-Service Jira，确认状态为 “Running”
查看 Jira 日志：Get-Content "C:\jira\logs\catalina.out" -Tail 50，搜索 “SEVERE” 或 “Exception”
检查端口占用：netstat -ano | findstr :8080，确认是否有 PID 列出

永久修复：

编辑C:\jira\bin\setenv.bat，找到set JVM_MINIMUM_MEMORY=512m行，改为set JVM_MINIMUM_MEMORY=2048m
同样修改set JVM_MAXIMUM_MEMORY=1024m为set JVM_MAXIMUM_MEMORY=4096m
重启 Jira 服务：Restart-Service Jira

注意：内存设置不能超过物理内存的 75%。我的 16GB 服务器设为 4GB，留足空间给 SQL Server 和 Windows 系统。

5.2 问题：外网访问显示 “502 Bad Gateway”，但本地`http://localhost:8080`正常

现象：内网能访问，外网 Nginx 返回 502，Nginx 错误日志（C:\nginx\logs\error.log）里有 “connect() failed (10061: No connection could be made...)”。

根本原因：Nginx 配置里的proxy_pass指向了错误地址。常见错误是写成proxy_pass http://localhost:8080;，而 Windows 的 localhost 解析可能受 hosts 文件影响，或 IPv6/IPv4 优先级问题。

三步排查法：

在 Nginx 服务器上执行ping localhost，确认解析为127.0.0.1（不是::1）
执行Test-NetConnection 127.0.0.1 -Port 8080，确认端口连通
检查C:\nginx\conf\nginx.conf，确认proxy_pass行是http://127.0.0.1:8080;（用 IP 而非 localhost）

永久修复：

将proxy_pass改为http://127.0.0.1:8080;
在C:\Windows\System32\drivers\etc\hosts文件末尾添加127.0.0.1 localhost（强制 IPv4）
重启 Nginx：Restart-Service nginx

5.3 问题：登录后重定向到`http://`地址，浏览器报 “不安全连接”

现象：输入用户名密码后，页面跳转到http://jira.yourcompany.com/secure/Dashboard.jspa，地址栏显示不安全警告。

根本原因：Jira 不知道前端是 HTTPS，它根据server.xml里的 connector 配置生成重定向 URL，默认用 HTTP。

三步排查法：

访问http://localhost:8080/secure/admin/ViewSystemInfo.jspa，搜索 “Base URL”，确认值为http://jira.yourcompany.com
检查C:\jira\conf\server.xml，确认<Connector>标签里有scheme="https"和secure="true"
检查 Nginx 配置，确认proxy_set_header X-Forwarded-Proto https;已存在

永久修复：

编辑C:\jira\conf\server.xml，找到<Connector port="8080"行，在其后添加：

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" scheme="https" secure="true" proxyName="jira.yourcompany.com" proxyPort="443"/>

编辑 Jira 管理后台：http://localhost:8080/secure/admin/GeneralConfiguration.jspa→ “Base URL” 改为https://jira.yourcompany.com
重启 Jira 服务

5.4 问题：附件上传失败，提示 “Error occurred while uploading attachment”

现象：点击 “Attach files” 选择文件后，进度条卡住，最终报错。

根本原因：Windows 权限问题。Jira 服务账户（如svc_jira）对D:\jira-home\attachments目录没有写入权限，或目录所在磁盘空间不足。

三步排查法：

检查磁盘空间：Get-PSDrive D | Select-Object Used, Free
检查目录权限：右键D:\jira-home\attachments→ 属性 → 安全 → 高级，确认svc_jira用户有 “修改” 权限
查看 Jira 日志：搜索 “attachment” 或 “IOException”

永久修复：

确保D:\jira-home\attachments目录存在，且svc_jira用户有 “完全控制” 权限
在 Jira 管理后台：http://localhost:8080/secure/admin/GeneralConfiguration.jspa→ “Attachment Settings” → “Maximum attachment size” 设为100（MB）
重启 Jira 服务

5.5 问题：邮件通知不发送，日志显示 “Authentication failed”

现象：在 Jira 里配置 SMTP 服务器（如腾讯企业邮箱），测试邮件发送失败。

根本原因：腾讯企业邮箱等服务商要求 SMTP 使用 OAuth2 认证，而 Jira 8.x 默认只支持密码认证。且 Windows 系统时间误差超过 5 分钟会导致 OAuth2 Token 签名失效。

三步排查法：

检查系统时间：Get-Date，对比北京时间，误差是否 > 5 分钟
检查 SMTP 配置：Jira 后台 → “Outgoing Mail” → 确认 “SMTP Username” 是完整邮箱地址（如admin@yourcompany.com）
检查腾讯邮箱设置：是否开启 “IMAP/SMTP 服务”，是否生成了 “专用密码”（非登录密码）

永久修复：