OpenBSD Gitea, can't push : curl 52 Empty reply from server


I’ve set up Gitea (sqlite) on my OpenBSD box with https & httpd and imported some projects from gitlab. Oddly enough, when I try to push from my laptop, I get a very long timeout after trying to push and then:

Username for ‘’:
Password for ‘’:
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 321 bytes | 321.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
error: RPC failed; curl 52 Empty reply from server
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly
Everything up-to-date

Gitea logs don’t show anything on Debug or Error. Pf doesn’t show any blocked requests, and when attempting an edit in the browser, I get the same timeout before it cancels out…

How would I go about debugging this issue? Any ideas on the cause?

Thanks a lot for the help!

Sounds like it may be an issue with reverse proxy or network connection. What does the httpd config look like? Is OpenBSD box on same network as your laptop?

Sorry for the late reply!
Yes it is on the same network, but I’ve never had trouble accessing my website through my domain name.

server "" {
	listen on * tls port 443
	hsts subdomains
	tcp nodelay
	tls {
		certificate "/etc/ssl/"
		key "/etc/ssl/private/"
	location "/.well-known/acme-challenge/*" {
		root "/acme"
		request strip 2
	# don't serve static files from cgit CGI: cgit.css and cgit.png
        location "/*" {
		fastcgi socket tcp 3000

and gitea:

; ; Overwrite the automatically generated public URL. Necessary for proxies and docker.
; ; when STATIC_URL_PREFIX is empty it will follow ROOT_URL
; ;
; ; The address to listen on. Either a IPv4/IPv6 address or the path to a unix socket.
HTTP_ADDR        =
; ;
; ; The port to listen on. Leave empty when using a unix socket.
HTTP_PORT        = 3000
SSH_DOMAIN       =
ROOT_URL         =
DISABLE_SSH      = false
OFFLINE_MODE     = false

It seems so weird, as I said, even through the UI it won’t save any changes. Could it be missing a key package?

Weirdly, the /var/gitea/gitea-repositories folder wasn’t created, so I made it and chowned it to _gitea.

The default SCRIPT_TYPE was configured to sh, but I got a messaged complaining about missing bash, so I installed it and switched the var to bash.

Still no :confused:

Make sure [app] PROTOCOL is set to fcgi, although I assume it is because you are able to access the UI.

It looks like you are running into this issue which happens when [app] LOCAL_ROOT_URL is not set properly when using FastCGI. I believe it should be set to fcgi:// in your use case.

Note: the default currently listed for APP_LOCAL_URL in Config Cheat Sheet documentation is incorrect when PROTOCOL is fcgi, it actually defaults to ROOT_URL. I filed an issue to clarify this here.


Wow, thanks a lot!

I will try and report back if it works when I get home.

The error seems gone :partying_face:

I however see a new one:

remote: Gitea: Internal Server Error
remote: Unable to contact gitea: Post "fcgi://": unsupported protocol scheme "fcgi"
 ! [remote rejected] main -> main (pre-receive hook declined)
error: failed to push some refs to ''

Hmm, it looks like LOCAL_ROOT_URL is used differently than I thought. Gitea uses that config option to send internal HTTP requests to itself (and the library net/http used to do so does not support FCGI), but since Gitea’s listening using FCGI it can’t send them to itself, and the push fails. I can think of a few possible solutions:

  1. Create an internal HTTP server on httpd just for Gitea’s operations like:

    server "*" { # I think this name will work, but not sure
        listen on port 3001
        tcp nodelay
        location "/*" {
            fastcgi socket tcp 3000

    And then set LOCAL_ROOT_URL =

  2. You could have Gitea listen on HTTP instead of FCGI and then use something like relayd, nginx, or Apache, to reverse proxy it. Then LOCAL_ROOT_URL would be set properly from its default and would work since it’s HTTP.

    If relayd, to replace the location "/.well-known... rule, I think you could create a symlink like [gitea custom]/public/.well-known/acme-challenge -> /acme and have Gitea follow it, but I haven’t tried so not sure if it will work.

  3. File an issue on GitHub to see if they will add support for fcgi URLs in LOCAL_ROOT_URL

1 Like

Thank you very much for your help. It (solution 1) works very well!

If I understand correctly, LOCAL_ROOT_URL doesn’t understand fastcgi requests so this translates it to http to communicate with gitea, right?

It’s probably quite inefficient as a result though it seems plenty fast for my small needs. What would have been the canonical way of setting it up? Make a reverse proxy?


Yeah, it’s not optimal. I don’t think you’ll ever run into any issues with it unless you get a ton of users. Before ever hitting that issue, I think you’d run into latency issues with using SQLite.

I’d say the most common setup is Gitea listening with HTTP via TCP or HTTP via a unix socket, and then reverse proxying Gitea using an HTTP server capable of reverse proxying those setups (nginx, relayd, Apache, others).