Dngr.us unnesacaraly redirects 3 times

When loading a url like dngr.us/next it redirects through 3 urls before getting to the right one, which each take upwards of 0.5s to load

Custom links like dngr.us/next and dngr.us/next only redirect from HTTP to https

I’ve found I use these URLs a lot and it’s a bit annoying having to wait sometimes 5 seconds before it even starts to load the page I want. I understand all the steps it’s taking, but would it be possible to optimise? (I’d be happy to help because I know it’s not a priority for you, but I’m a stranger on the internet :frowning: )


Interesting… I see two places I could optimize

1 Like

Those intermediate steps are on purpose:

The first redirect switches to HTTPS (as it should) but gives your IP to the DT mind control server - or DTMC for short.

The second redirect tells the DTMC which page you want, to put you in the right mood: dribbling mode for the forum, impulse-purchase mode for the webshop.

The third redirect simply pauses for the DTMC’s effect to fully take on before you hit the page.


oh, sorry. Don’t worry then, it’s doing it’s job for me :stuck_out_tongue:

this can be skipped… there’s nothing secure about this site and it could easily skip this redirect all together.

in the case of the storefront, for some reason there seems to be an extra / which then redirects to the product page with the right amount of / … this can be fixed…

In short a call to NExT RFID + NFC Chip Implant | RFID & NFC Chip Implants and Biohacking products should redirect straight to NExT RFID + NFC Chip Implant | RFID & NFC Chip Implants and Biohacking products

1 Like

On my own server at home - which has nothing secure on either and I happily left running as a dumb HTTP server for 15 years - I had to install Nginx as a HTTPS wrapper around it, for one single reason: modern browsers give you increasingly ungodly amounts of shit when you connect to “insecure” sites nowadays.

This annoys me no end, as it’s my own server, it’s running inside my house behind my firewall, and it’s for my family. But now they’re being served with “connection insecure” pages that they can’t even override anymore, with no option to disable it. So… HTTPS and dealing with valid certificates even when you don’t need any of this.

1 Like

Yes by setting HSTS (Strict Transport Security) header so we directly connect to https. TLS all the things, even if they seem to not need it. There’s at least the threat of man in the middles redirecting to IAR! TLS with HSTS prevents that, it forces TLS even when requesting http links. After loading the page once, browsers will only connect over https.

I’m just happy the main DT site loads much faster than it has in the past. It used to be so slow.

still requires an extra hit to the server to get that header, then a new TCP pipe for SSL.

buuuttt whhyyyyyy? seriously though, why? in this case the traffic will be a redirect. is that sensitive? i guess it could be … for certain people… maybe… i might reconsider.

should be fixed now. calls to http or https now redirect straight to the product in question with the proper following / so the main site doesn’t have to redirect either… two hops;


I may reconsider the HTTPS thing with HSTS … if a compelling reason can be given for this specific use case :slight_smile:


Yes once, but that will be cached by browsers (for as long as you specify) and then it wont try http again.
So it’s always just 1 request, but almost only https.

Why should there be anything unencrypted?
There is no reason not to do that.

  • no extra request, like explained above
  • it’s not much work

No in all honesty, this isn’t really a vulnerability, so I dont care too much, but it’s a security enhancement. It might stop a man in the middle attack, a little bit less clear text traffic in the world is good.


Not if you put the site in the HSTS preload list. Make sure HSTS is set up properly, then submit it here and it’ll ship out as an HSTS-enabled site with every browser.


Another possibility (maybe a bit finicky) could we make addresses that could take you to a 404 page (like dngr.us/m1) take us to a search for that string?

A search on the site for products or a search here on the forum?

on the site I think

anyone have any idea how to deal with nginx redirects using regex and rewrite to strip off the leading / from $request_uri or $uri before redirecting?

I have done it before a few years ago. Let me see if I can find some of my notes. (Probably tomorrow while I am supposed to be working.)

1 Like

I have absolutely no experience with Nginx, but I’m a great hack and I survive at work thanks to my Googlefingers. What I’m trying to say is that this seems like it’s super relevant, but I can’t be sure since I don’t… damnit, I’m rambling.

regex - How to replace characters in an nginx variable string? - Stack Overflow

If you have examples it might be a bit easier, but it should be something like…

rewrite ^/(.*)$ $1;

I haven’t tested it yet as I didn’t feel like installing nginx.

The regex matches things starting / (^/) and captures everything else ((.*)) to the end ($) as $1. It then passes it on to the next rewrite rule.

I hope that this helps.

I think I understand this… but how do you indicate that you want to feed in $request_uri into that regex? What would it be performing the regex on without specifying the source?

I’ll check your Googlefinger results shortly!

hah! I used a combination of both of your input…

> https://f.dngr.us/blinky

now redirects to

> https://forum.dangerousthings.com/search?q=blinky


1 Like