因为一些未知的起因（猜测应该是 gitlab 的证书主动 renew)，近期自部署的 gitlab-ce 呈现了证书问题。
索性咱们禁用 gitlab 的 https 性能，将期复原为 http。前期咱们再在部署一个 nginx 进行数据转发，而后在 nginx 上起用 https 并设置证书。这样应该就躲避了 gitlab 的证书谬误问题。
配置
gitlab-ce 的配置文件位于：/etc/gitlab/gitlab.rb中。而将 https 变更为 http 的办法很简略，只须要配置 external_url 为 http 打头即可。
- external_url 'https://gitlab.yourdomain.com:8888'
+ external_url 'http://gitlab.yourdomain.com:8888'而后应用执行命令：sudo gitlab-ctl reconfigure使其失效。
配置尽管简略，但测试的时候却每每产生问题，导致开始狐疑人生。
测试
应用 chrome 关上地址：http://gitlab.yourdomain.com:8888，却发现产生了 307，转向的地址为：https://gitlab.yourdomain.com:8888，这会使得咱们开始狐疑后面的配置是否失效了。
即便开启了 chrome 或 firefox 的禁用缓存性能，拜访原地址依然是 307。这是因为禁用缓存性能并没有禁用浏览器的redirects，所以如果在浏览器上间接进行测试，则须要先清空浏览器的缓存。
比方咱们将地址输出地址栏后，而后关上控制台，接着左键点住刷新按钮：
抉择 清空缓存并且硬加载(Empty cache and hard reload)，此时便能够禁用 chrome 的 redirects 的缓存后实现加载了。
其实除了应用浏览器间接测试外，更靠谱的办法是应用一些脚本，比方 curl。curl 反对应用 -I 参数来显示返回的状态码及响应头。
雷同的地址，如果 curl 并没有返回 307 而浏览器却是 307 则能够确认是浏览器的缓存问题而不是 gitlab 的配置问题了。
panjie@panjies-Mac-Pro ~ % curl -I http://gitlab.yourdomain.com:8888
HTTP/1.1 302 Found
Server: nginx
Date: Tue, 27 Dec 2022 04:33:50 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Cache-Control: no-cache
Location: http://gitlab.yourdomain.com:8888/users/sign_in
Pragma: no-cache
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Request-Id: 01GN8XQC4NVMGZ7VA4S5QRRX2E
X-Runtime: 0.029655
X-Ua-Compatible: IE=edge
X-Xss-Protection: 1; mode=block
Strict-Transport-Security: max-age=63072000
Referrer-Policy: strict-origin-when-cross-origin此时首页返回 302，回跳地址为：http://gitlab.yourdomain.com:8888/users/sign_in，持续申请该地址：
panjie@panjies-Mac-Pro ~ % curl -I http://gitlab.yourdomain.com:8888/users/sign_in
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 27 Dec 2022 04:35:02 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Vary: Accept-Encoding
Cache-Control: max-age=0, private, must-revalidate
Content-Security-Policy:
Etag: W/"7aefc583df813a9b66e476d0c11736b1"
Link: </assets/application_utilities-f86a7caa76c1a2f00550828a9303a66e38d2f043e5f21c2bade17a6ddafe50ab.css>; rel=preload; as=style; type=text/css,</assets/application-f8ba2470fbf1e30f2ce64d34705b8e6615ac964ea84163c8a6adaaf8a91f9eac.css>; rel=preload; as=style; type=text/css,</assets/highlight/themes/white-14ba9f209d5cc375d065606896b08ef3d4dc7be19e5b5800958b390d7ab2bd40.css>; rel=preload; as=style; type=text/css
Permissions-Policy: interest-cohort=()
Pragma: no-cache
Set-Cookie: _gitlab_session=e3d88869c1f709d08bb1887a9da8fb9f; path=/; expires=Tue, 27 Dec 2022 06:35:02 GMT; HttpOnly
Vary: Accept
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Request-Id: 01GN8XSJQC57ANRBDYY8J9P8HF
X-Runtime: 0.068342
X-Ua-Compatible: IE=edge
X-Xss-Protection: 1; mode=block
Strict-Transport-Security: max-age=63072000
Referrer-Policy: strict-origin-when-cross-origin可见状态码为 200，非 307。此时便能够请释怀的去钻研浏览器的缓存问题了。
总结
始终认为浏览器的禁用缓存用禁用所有缓存，没想到 redirects 却是始终走的缓存。这导致原本一个非常简单，早早就曾经解决的问题最终却破费了大略一天的工夫。有时候就是这样，一旦陷入了某个常识陷阱，凭着本能爬出来便会显示非常不容易。而咱们一旦爬出来，当前再有此类问题时，大脑便会产生踊跃的信号来通知你历史上咱们已经陷入过。
所以在教学过程中，根据本人的教训来设置更好的设置陷阱也是优化教学的一个方向。