我来给你几个实用的解决办法，都是实际场景中验证过的，你可以根据自己的需求选择：

1. 用内网穿透工具快速打通公网访问 #

这是测试或个人项目最便捷的临时方案，推荐用Ngrok（或者FRP这类工具）：

• 操作步骤：
  1. 下载安装Ngrok后，在终端运行命令：ngrok http 8080（这里8080是Jenkins默认端口，根据你的实际配置修改）
  2. 运行后会生成一个类似https://abc123.ngrok.io的临时公网域名
  3. 去GitLab的Webhook配置页面，填入这个域名加上Jenkins的Webhook路径，比如https://abc123.ngrok.io/jenkins/gitlab-webhook/（路径要和Jenkins GitLab插件配置的保持一致）
• 注意点：
  • 免费版Ngrok的域名每次重启都会变化，需要重新更新GitLab的Webhook地址
  • 如果需要固定域名，可以考虑Ngrok付费版，或者用FRP自己搭建穿透服务（需要一台有公网IP的服务器）

2. 把Jenkins部署到公网可访问环境 #

这是生产环境最稳定的长期方案：

• 将Jenkins迁移到云服务器（比如阿里云、AWS）或者有公网IP的本地服务器上
• 给Jenkins配置固定公网IP或域名，确保GitLab.com能正常访问这个地址
• 直接在GitLab Webhook里填写Jenkins的公网地址+Webhook路径即可
• 优势：长期稳定，无需依赖第三方工具，还能通过防火墙规则限制只有GitLab的IP能访问Jenkins，提升安全性

3. 用Jenkins Poll SCM功能替代Webhook #

如果对构建实时性要求不高，这个方案配置最简单：

• 打开你的Jenkins流水线项目配置，找到「Build Triggers」板块，勾选「Poll SCM」
• 设置定时表达式，比如H/5 * * * *（表示每5分钟随机时间检查一次代码仓库的更新）
• 原理：Jenkins会定期主动拉取GitLab仓库的代码，检测到变化就触发构建
• 优势：不需要暴露Jenkins到公网，配置零成本；缺点：存在一定延迟，不适合需要实时构建的场景

4. 借助本地GitLab Runner触发Jenkins构建 #

如果你已经部署了本地GitLab Runner（和Jenkins在同一内网），可以用这个方法：

• 在GitLab仓库根目录创建.gitlab-ci.yml文件，添加触发Jenkins的阶段：

  trigger_jenkins:
    stage: trigger
    script:
      - curl -X POST "http://localhost:8080/jenkins/job/你的项目名称/build?token=你的Jenkins触发令牌"
    only:
      - main # 可根据需求指定触发的分支
  

• 确保本地Runner能访问到Jenkins的localhost地址
• 优势：利用GitLab CI的灵活触发规则，同时无需暴露Jenkins到公网；缺点：需要维护本地GitLab Runner

内容的提问来源于stack exchange，提问作者Alessandro Bardini