Invalid response from 204

I ran this command: I wanted to install a SSL certificate with let's encrypt

It produced this output: Domain could not be validated, error message: error type: urn:ietf:params:acme:error:unauthorized, error detail: 2001:8d8:100f:f000::200: Invalid response from Buying and selling domains by experts | Hire a broker today! | Sedo 204
Invalid response from Buying and selling domains by experts | Hire a broker today! | Sedo 204

My web server is (include version): NGINX

The operating system my web server runs on is (include version): Ubuntu 22.04

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): cloud panel

For test purpose I created a test file and this file can be accessed successfully over HTTP. Moreover the domain and subdomain are pointing correctly to the IP address where the website is hosted.

This is my server configuration

server {

listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
root /home/user/htdocs/basic/web;
index index.php;

if ($scheme != "https") {
rewrite ^ https://$host$uri permanent;

location ~ /.well-known {
auth_basic off;
allow all;


location / {
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_hide_header X-Varnish;
proxy_redirect off;
proxy_max_temp_file_size 0;
proxy_connect_timeout 720;
proxy_send_timeout 720;
proxy_read_timeout 720;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 256k;

location ~* ^.+.(css|js|jpg|jpeg|gif|png|ico|gz|svg|svgz|ttf|otf|woff|woff2|eot|mp4|ogg|ogv|webm|webp|zip|swf|map)$ {
add_header Access-Control-Allow-Origin "*";
expires max;
access_log off;

if (-f $request_filename) {

server {
listen 8080;
listen [::]:8080;

root /home/user/htdocs/basic/web;
index index.php;

try_files $uri $uri/ /index.php?$args;
index index.php index.html;

location ~ .php$ {
include fastcgi_params;
fastcgi_intercept_errors on;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
try_files $uri =404;
fastcgi_read_timeout 3600;
fastcgi_send_timeout 3600;
fastcgi_param HTTPS "on";
fastcgi_param SERVER_PORT 443;
fastcgi_param PHP_VALUE "{{php_settings}}";

if (-f $request_filename) {

It seems the Let's Encrypt validation server only allows HTTP 200 status codes as valid (next to some redirects that is).

Your server is sending HTTP 204 status codes for some reason. For the challenge file and your test file that is. For your main site, it's returning a 404 file not found :thinking:


204 is a successful code but it also means "nothing to see here"

Clients don't usually expect a response body, with 204.


Interestingly enough the Baseline Requirements only require a 2xx response, so instead of 200, a status of 204 would be just fine.

The ACME protocol (RFC 8555) does not specify anything with regard to the HTTP status code.

1 Like

It assumes a response body, tho

A 204 response is terminated by the end of the header section; it cannot contain content or trailers.


True true, you'd need some content for a successful challenge anyway :grin:

1 Like

What shoul I do now?

By the way, there's an Apache webserver responding on your IP addresses. Not nginx.


Is there any suggestion changes that I can make in the server configuration?

Show us the full nginx config. There's something that makes these 204s. It's either nginx or your application.

nginx -T

And use backticks

Like this

The full nginx configuration is in my description of the issue on the top

It doesn't look that full. But also read above, you have Apache responding. Check your Apache config, assuming it's on the same machine.


That's not going to help if an Apache server is responding. But weirdly enough there's an nginx responding for the challenge, but Apache for the main server.


Why do you think that there is apache server responding for main server?

Because that's how the webserver identifies itself:

osiris@erazer ~ $ curl -Lv
*   Trying [2001:8d8:100f:f000::200]:80...
* Connected to (2001:8d8:100f:f000::200) port 80 (#0)
> GET / HTTP/1.1
> Host:
> User-Agent: curl/8.1.2
> Accept: */*
< HTTP/1.1 404 Not Found
< Content-Type: text/html
< Content-Length: 601
< Connection: keep-alive
< Keep-Alive: timeout=15
< Date: Mon, 11 Sep 2023 17:02:13 GMT
< Server: Apache
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html lang="en" xml:lang="en" xmlns="">
   Error 404 - Not found
  <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  <meta content="no-cache" http-equiv="cache-control">
 <body style="font-family:arial;">
  <h1 style="color:#0a328c;font-size:1.0em;">
   Error 404 - Not found
  <p style="font-size:0.8em;">
   Die angegebene Seite konnte nicht gefunden werden.
* Connection #0 to host left intact
osiris@erazer ~ $
1 Like

We should've known.

❯ curl -IL -4
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Mon, 11 Sep 2023 17:04:07 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Permitted-Cross-Domain-Policies: master-only
Referrer-Policy: same-origin

curl: (60) SSL certificate problem: self-signed certificate
More details here:

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

❯ curl -IL -6
HTTP/1.1 404 Not Found
Content-Type: text/html
Connection: keep-alive
Keep-Alive: timeout=15
Date: Mon, 11 Sep 2023 17:04:17 GMT
Server: Apache

IPv6 and IPv4 go to different machines.


Not from my point of view, I get the same 404 error for IPv4 and IPv6.


There are two A records. I got


Ah, that would explain a lot indeed. For some reason I'm only connecting to

But that wouldn't fix the 204 error, unless the IPv6 address is also not correct.


How should be normally the Ipv6 adress configured normally? the Domain and subdomain were only connected to the ipv4 address of the host.