400 bad request in shlink links from public network

Currently reading
400 bad request in shlink links from public network

104
7
NAS
DS918+
Operating system
  1. Windows
Mobile operating system
  1. Android
Despite resolving the issues I had by accessing via shlink namely, connection refused on most browsers, as described here. But this time, there is a 400 bad request in every browser call from public network only. Shlink calls from private network are not affected.

Some searching leads me to a section in shlink documentation but refers a 404 error. There is no references for exact 400 errors. So this is the closest help I got: Shlink - The URL shortener — Documentation.

But maybe my thoughts are wrong. Maybe the issue is related with this situation where 400 bad request is mentioned: Shlink - The URL shortener — Documentation

I did read somewhere else that shlink must be configured additionally to handle non-common domains as is in the case by reverse proxy with .cc domain. Don't know if this make sense.

Again, I gathered some info here and there, but don't have tech knowledge enough put a solution in practice.
Please, I need help to get rid of this issue in particular to I finally put shlink to serve to something real.

Thank you.
 
Solution
bjsa.cc points to the same IP address as bjamsa.myds.me now. However, using bjsa.cc gives a warning that its not safe but if accept it, I can reach your web station. It’s because of the certificate. It’s issued for bjamsa.myds.me
Look it is issued.
1617650095599.png


Which one do you want to use?

View attachment 3358
-- post merged: --

View attachment 3359
-- post merged: --

Sorry. What I meant above is that if I use https://s1.bjsa.cc I can get to your web station after I accept the risk.

View attachment 3360
-- post merged: --

Here’s a suggestion (since I remember you saying that don’t care if it’s http).

Change the Reverse Proxy settings (your screenshot above) under source to:
Protocol http...
Despite resolving the issues I had by accessing via shlink namely, connection refused on most browsers, as described here. But this time, there is a 400 bad request in every browser call from public network only. Shlink calls from private network are not affected.
So you have this over reverse proxy or not? If so what reverse proxy platform? Also, error 400 could mean that you are trying to get to the address using a protocol that is not configured, for example, HTTP instead of HTTPS, or vice versa.
 
Upvote 0
I think if you use https it works while with http the browser complains that the “The plain HTTP request was sent to HTTPS port”.
So I think it has something to do with redirection configuration. Or you can try configuring the source on your reverse proxy to be https/443 and force the use of https.
I didn't buy a ssl certificate yet, and don't want to (too risky not to work at all at the end) until the functionality is restored to the date it worked one day from the start, but suddenly from nothing showed up issues like those described in earlier thread, and now, these 400 bad request errors. Very frustrating.
Nevertheless, I forced a https as suggested, but "refused connection" error in browser.

Any other tips?
 
Upvote 0
I can visit the website when using https. It gives a warning (no certificate) and when I tell it to go ahead, I get to the web station page (iPad Safari)

I’m not aware of the history and the other thread, so maybe whatever I’m suggesting doesn’t apply. But can’t you use an LE certificate for free?
Yes, I can replicate the same experience as you. But is this an evidence that it should only work if I buy a ssl certificate?
Then why it doesn't work without a sll certificate in the first place?.

If it worked as of the first day w/o ssl, why should I need one now to prove it has to work with a ssl certificate? In fact it has to work w/o a ssl first, and then if evrything is ok, a ssl certificate would be afterwards reasonable come to an use. Cause if there is something wrong behind the scenes, then a ssl certificate would be a waste of money/hope, EXCEPT if an ssl implementation is a guarantee of functionality.
The first issue encountered is described in this thread. Summary: there was a dns issue.

Since the first day of shlink implementation it worked flawlessly for about 3 months, then arose the issue of dns mentioned before. After fixing it it worked for some more weeks. Now what would be reason of this new issue?.

I would appreciate every tip to solve this enigma.

PS.: A LE certificate does not work via synology, cause the domain used in shlink is not the server domain used.
A LE certificate implemented onto docker is beyond my knowledge. Anything here you could share about?
 
Upvote 0
If it worked as of the first day w/o ssl, why should I need one now to prove it has to work with a ssl certificate?
Then use it over port 80/http as you have it configured in reverse proxy. Do you get any errors in that case?

A LE certificate does not work via synology, cause the domain used in shlink is not the server domain used.
Not sure what that means, but LE work just fine with Syno for 3rd party domains
 
Upvote 0
Last edited:
Then use it over port 80/http as you have it configured in reverse proxy. Do you get any errors in that case?
Yes, the famous 400 bad request.
1616962340841.png

Not sure what that means, but LE work just fine with Syno for 3rd party domains
I meant that thru synology control panel is not allowed to get more than one certificate, is that right?
1616949322488.png

As you can see above, I already have a certificate registered for that domain (server domain). Additional domain can be added, but not certificated via LE in synology control panel. As I heard, it is possible buy one elsewhere, or implement a LE into the server via docker. Make this any sense?
 
Upvote 0
Last edited:
For port 80 without redirection make sure HSTS is not enabled. HSTS forces https.
What do you mean with redirection in that case?
As you can see on screeshot above, even if I wished set the HTST I couldn't because it it deactivated.
I got the idea, so this is strange how the request was sent to https port. o_O
1616962524896.png
 
Upvote 0
Are you using Web Station virtual host?
There’s an HSTS setting there.

Edit:
If you’re not using Virtual Host.
Under Control Panel > Network > DSM Settings > Domain
Did you enable customized domain and checked HSTS?
Web Station:
No virtual host set.
Pesrsonal Website enabled.

Network DSM settings:
Customized domain is disabled.
 
Upvote 0
Since it worked before then there must be a change somewhere that caused this. But I’m running out of ideas.

Personal websites are limited to Apache. So the website is under a user in their home folder?
Have you configured .htaccess by any chance? Or can you check if there's an .htaccess file?

Edit:
What about your router? Are you forwarding 80 to 80?
 
Upvote 0
Last edited:
Since it worked before then there must be a change somewhere that caused this. But I’m running out of ideas.

Personal websites are limited to Apache. So the website is under a user in their home folder?
Yes, under each user there is a www folder but no user have data on it, no .htaccess. Empty.
However, there is a exclusive folder for website, not under homes.
1616969561020.png

Have you configured .htaccess by any chance? Or can you check if there's an .htaccess file?
Wordpress generated a .htaccess.

Code:
# BEGIN WordPress
# As diretrizes (linhas) entre `BEGIN WordPress` e` END WordPress` são
# geradas dinamicamente e só devem ser modificadas através de filtros do WordPress.
# Quaisquer alterações nas diretivas entre esses marcadores serão sobrescritas.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress
Edit:
What about your router? Are you forwarding 80 to 80?
1616969103283.png
 
Upvote 0
I was looking for a redirect in htaccess but it seems that you don’t have one.

Like this:

I suggest that you wait and see if anyone else has any ideas. I can’t think of anything else at the moment 🙁
Ok, I thank you so far for your support. cy. (y)
 
Upvote 0
Yes, the famous 400 bad request.
View attachment 3323

I meant that thru synology control panel is not allowed to get more than one certificate, is that right?
View attachment 3322
As you can see above, I already have a certificate registered for that domain (server domain). Additional domain can be added, but not certificated via LE in synology control panel. As I heard, it is possible buy one elsewhere, or implement a LE into the server via docker. Make this any sense?
Could someone reply me if that I wrote above make sense? If not, how I could add a second certificate to the server with an additional domain, in this case, a 3rd party domain just for use for shlink?
 
Upvote 0
Within DSM you can generate many LE certificates. They have to resolve to a domain that is valid for reaching the NAS and then the Subject Alternative Name (SAN) field can be used to add more server names that you use for NAS services, e.g.:
  • Domain name: mynas.synology.me
    • SAN permits:
      • *.mynas.synology.me wildcard
      • mydomain1.com
      • mydomainN.com
      • myservice.mydomain1.cm
      • anotherservice.mydomainN.com
      • myothernas.synology.me
      • serviceon.myothernas.synology.me
  • Domain name: mydomain1.com
    • SAN permits:
      • mydomainN.com
      • myservice.mydomain1.cm
      • anotherservice.mydomainN.com
      • myothernas.synology.me
      • serviceon.myothernas.synology.me
The SAN is limited to around 255 characters including the delimiting commas. You then assign certificates to NAS services (including Reverse Proxy and Wed Station virtual hosts) using the Configure button.


The client web request will be received by the reverse proxy as HTTPS and then the reverse proxy can use either HTTPS or HTTP to the protected destination web server. The client's web session is to the reverse proxy, not the destination web server.
 
Upvote 0
Within DSM you can generate many LE certificates. They have to resolve to a domain that is valid for reaching the NAS and then the Subject Alternative Name (SAN) field can be used to add more server names that you use for NAS services, e.g.:
  • Domain name: mynas.synology.me
    • SAN permits:
      • *.mynas.synology.me wildcard
      • mydomain1.com
      • mydomainN.com
      • myservice.mydomain1.cm
      • anotherservice.mydomainN.com
      • myothernas.synology.me
      • serviceon.myothernas.synology.me
  • Domain name: mydomain1.com
    • SAN permits:
      • mydomainN.com
      • myservice.mydomain1.cm
      • anotherservice.mydomainN.com
      • myothernas.synology.me
      • serviceon.myothernas.synology.me
The SAN is limited to around 255 characters including the delimiting commas. You then assign certificates to NAS services (including Reverse Proxy and Wed Station virtual hosts) using the Configure button.


The client web request will be received by the reverse proxy as HTTPS and then the reverse proxy can use either HTTPS or HTTP to the protected destination web server. The client's web session is to the reverse proxy, not the destination web server.
Thanks for reply, but I can´t get a certificate for the domain I entered. Following your statement it had to work.

1617301370178.png


Am I missing anything here? What do you exactly mean with "have to resolve to a domain that is valid for reaching the NAS"? How can I test if domain is reaching my NAS?

Thanks.
 
Upvote 0

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

Yep this section. I would have expected to see the digest instead of {repo}:{tag}. With the repo digest...
Replies
5
Views
2,139

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top