您好,登錄后才能下訂單哦!
本篇內容主要講解“git push到遠程服務器出現RPC failed問題怎么解決”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“git push到遠程服務器出現RPC failed問題怎么解決”吧!
error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413fatal: the remote end hung up unexpectedlyfatal: the remote end hung up unexpectedlyEverything up-to-date
解決方案
方案一:修改本地git postbuffer大小
git config --global http.postbuffer 524288000
方案二:修改項目.git/config文件,增加如下內容
[http] postBuffer = 524288000
方案三:用管理賬號在gitlab中的Account and limit加大Maximum attachment size (MB)和Maximum push size (MB)
error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413
對我們有效的信息,預計就是413這個狀態碼,我們可以先從這個狀態碼入手
這個狀態碼的含義是
413 Request Entity Too Large
服務器拒絕解決當前請求,由于該請求提交的實體數據大小超過了服務器愿意或者者能夠解決的范圍。此種情況下,服務器可以關閉連接以免用戶端繼續發送此請求。
由狀態碼的含義,我們可以得出上傳的代碼可能過大。于是我讓小伙伴看下,他上傳的代碼量有多少,好家伙,一共有4,50M的大小
方案一:代碼進行分批上傳,不要一次性上傳
小伙伴按這個方案果然處理了問題,但是他說這樣好麻煩,總不能以后每次都要分批上傳,這樣提交代碼的效率很低
方案二:增大http方式上傳的大小
這個方案就是最開始的設置postbuffer,但問題就是不論用。后面就懷疑說是不是由于配置域名的起因,于是我就采用內網ip的方式直接去push代碼,結果竟然可以了。
接著去ping下gitlab的域名,發現那個ip不是gitlab的內網ip,當然ping出來的也可能是外網ip,于是我就把ping出來的ip通過百度一下,顯示該ip是本地局域網。
而后很自然的想到項目的gitlab是不是配置了代理商,接著就去問搭這個gitlab的前同事。果然他之前搭建這套gitlab采用nginx做了代理商,于是衍生出了第三種方案
方案三:修改nginx配置
在http的server節點中增加client_max_body_size,形如下
http: { server: { client_max_body_size: 200m; }}
方案四:用ssh提交代碼
到此,相信大家對“git push到遠程服務器出現RPC failed問題怎么解決”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。