github-for-jira 对接 GitHub Enterprise Server：Nginx 反向代理部署实战（附完整配置）

github-for-jira 对接 GitHub Enterprise ServerNginx 反向代理部署实战附完整配置【免费下载链接】github-for-jiraDEPRECATED (moved to private repository) - Connect your code with your project management in Jira项目地址: https://gitcode.com/gh_mirrors/gi/github-for-jiragithub-for-jira 是 Atlassian 开源维护的官方集成工具用于把 GitHub 代码与 Jira 项目管理无缝连接。当企业使用部署在内网的GitHub Enterprise ServerGHE时云端 Jira 无法直接访问内网地址此时通过Nginx 反向代理即可安全打通双方通信。本文将基于官方示例 docs/sample-reverse-proxy-nginx.conf 逐段拆解配置带你完成一次可落地的反向代理部署实战。为什么需要 Nginx 反向代理打通 GHE 与 Jira CloudJira Cloud 运行在 Atlassian 的云端服务器上而 GitHub Enterprise Server 通常部署在公司内网两者之间存在两个核心障碍网络不可达云端无法路由到内网 IP需要一台公网可达的代理服务器作为中转。地址与校验不一致内网主机名、公网主机名不同且 Jira 回调时会校验来源 IP必须确保来自 Atlassian 的合法请求才能放行。Nginx 反向代理恰好承担了「翻译官 守门员」的双重角色对外暴露统一域名对内转发到 GHE同时完成请求头、响应内容中的地址改写与来源鉴权。反向代理的工作流程一次请求如何流转整个代理链路可以概括为四个步骤Jira Cloud 向公网域名public-ghe-hostname.mycompany.com发起请求Nginx 校验来源 IP 是否为 Atlassian 白名单或携带合法 API Key通过校验后代理将请求转发到内网private-ghe-hostname.intranet.local返回的响应中所有内网地址会被自动替换为公网地址Jira 才能正确识别。这套流程在配置文件中通过map、proxy_set_header、sub_filter与 Lua 过滤器协作完成。部署前的准备工作开始配置前请确认以下三件事使用带 Lua 模块的 Nginx推荐 OpenResty配置中的header_filter_by_lua_block依赖ngx_http_lua_module普通 Nginx 需要额外编译该模块准备内外网两套域名内网域名如private-ghe-hostname.intranet.local公网域名如public-ghe-hostname.mycompany.com并在 DNS 中做好解析申请 SSL 证书示例中预留了 443 端口监听生产环境必须配置 HTTPS 证书配置中已标注 TODO。完整 Nginx 反向代理配置详解下面按配置文件的顺序逐段讲解完整文件可直接参考 docs/sample-reverse-proxy-nginx.conf。第一步定义内网与外网主机名映射配置开头用四个map指令定义了内网、外网的主机名与基础 URLmap $http_host $internal_ghe_hostname { default private-ghe-hostname.intranet.local; } map $http_host $internal_ghe_baseurl { default http://$internal_ghe_hostname; } map $http_host $public_ghe_hostname { default public-ghe-hostname.mycompany.com; } map $http_host $public_ghe_baseurl { default https://$public_ghe_hostname; }这段配置的核心作用是把「外网可见地址」与「内网真实地址」解耦。后续所有改写逻辑都引用这四个变量后续维护只需改这一处即可。第二步重写 Referer 与请求头Jira 发起请求时携带的Referer是公网地址转发到内网后 GHE 可能因域名不匹配而拒绝。配置通过map将公网 Referer 改写为内网地址map $http_referer $new_referer { default $http_referer; ~^$public_ghe_baseurl(.*)$ $internal_ghe_baseurl$1; }同时在location /中重写Host、Referer头并禁用压缩以方便后续内容改写proxy_set_header Host $internal_ghe_hostname; proxy_set_header Referer $new_referer; proxy_set_header Accept-Encoding ; proxy_redirect ~^($internal_ghe_baseurl)(/.*)?$ $public_ghe_baseurl$2;第三步Atlassian IP 白名单鉴权安全核心安全是反向代理的重中之重。官方配置只允许两类来源访问Atlassian 官方 IP 段104.192.138.240~255与13.52.5.96~127在map $remote_addr $is_atlassian_ip中定义公司内网 IP 段示例为192.168.0.*用于内部调试携带自定义 API Key 的请求请求头X-MySecretHeader值与配置一致时放行。鉴权逻辑位于location /末尾if ($remote_addr ~ ^(192\.168\.0\.)) { proxy_pass $internal_ghe_baseurl; break; } if ($is_atlassian_ip 0) { return 401 Not allowed; } if ($http_x_mysecretheader MY_API_KEY) { proxy_pass $internal_ghe_baseurl; break; } return 401 Not allowed;任何不满足条件的请求都会被直接返回401 Not allowed从源头杜绝非法访问。第四步响应内容与头部的地址改写GHE 返回的响应中可能包含内网地址例如Location跳转、HTML 链接如果直接透传Jira 将无法识别。配置采用双重改写响应头改写通过 Lua 块遍历所有响应头将内网主机名替换为公网主机名响应体改写通过sub_filter将正文中的内网主机名全局替换sub_filter $internal_ghe_hostname $public_ghe_hostname; sub_filter_once off;注意header_filter_by_lua_block中的 Lua 代码同时处理了字符串与数组类型的响应头覆盖了 Cookie、Set-Cookie 等场景这正是推荐使用 OpenResty 的原因。安全加固与常见问题排查部署上线后建议再做以下加固更换 API Key将MY_API_KEY改为强随机字符串并妥善保管更新 IP 白名单Atlassian 的 IP 段可能调整建议关注官方 IP 白名单文档并及时同步开启 HTTPS为 443 端口配置 TLS 证书与ssl_protocols。常见报错与解决思路报错信息可能原因解决办法401 Not allowed来源 IP 不在白名单、Key 错误检查请求头与来源 IP 段no resolver defined to resolve代理未配置 DNS 解析器在http块启用resolver填入公司 DNS参考配置注释页面跳转到内网域名sub_filter或 Lua 改写未生效确认 Nginx 已加载 Lua 模块且关闭了压缩总结让 Jira 与内网 GHE 稳定握手通过这份 Nginx 反向代理配置github-for-jira 得以在内网 GitHub Enterprise Server 与云端 Jira 之间建立一条安全、可控的通道公网域名对外统一暴露内网地址在代理层完成双向改写Atlassian IP 白名单与 API Key 双保险保障安全。对于想要快速体验的开发者也可以先 clone 仓库获取完整配置示例git clone https://gitcode.com/gh_mirrors/gi/github-for-jira然后参照 docs/sample-reverse-proxy-nginx.conf 逐项替换域名与密钥即可在自己的环境中完成 github-for-jira 对接 GitHub Enterprise Server 的反向代理部署。【免费下载链接】github-for-jiraDEPRECATED (moved to private repository) - Connect your code with your project management in Jira项目地址: https://gitcode.com/gh_mirrors/gi/github-for-jira创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考