RewriteCond %{ENV:HTTPS} !on
RewriteRule ^(.*)$ https://www.zeugmarket.com%{REQUEST_URI} [L,R=301]
There would seem to be "something else" that is adding the additional slash - it's not happening because of these directives.
at the end of my website URL like this: //
The double slashes are actually at the start of the URL-path, not strictly at the end. eg. If you request http://example.com/foo
then it returns https://example.com//foo
.
However, this redirect response is actually coming from an Nginx server, not Apache. Nginx is probably being used as a front-end (reverse) proxy - hence the requirement to use ENV:HTTPS
(environment variable) and not HTTPS
(server variable) in the RewriteCond
directive.
I would look for a config issue with the Nginx proxy, as it's most probably this that is adding the additional slash.
RewriteRule ^(.*)$ https://www.zeugmarket.com%{$1} [L,R=301]
Incidentally, in this example (from your comment) %{$1}
is not strictly valid and will always result in an empty string - so the double slash is definitely not coming from Apache.
However, you appear to have a single-page-website. You do not have any URL-path on any URLs? There is only one visible URL, and that's https://www.example.com/
, so your directives can be simplified:
RewriteCond %{ENV:HTTPS} !on
RewriteRule ^ https://www.example.com/ [L,R=301]
Note that there should be a slash after the hostname (at the start of the URL-path). If you omit it then (ordinarily) the browser will append the slash in the redirected request. (But it seems that Nginx is actually appending these slash(es) in the redirect response - before it gets to the browser.)
For a bit more information about the browser and the trailing slash after the hostname, see the following question on the Webmasters stack:
https://webmasters.stackexchange.com/questions/35643/is-trailing-slash-automagically-added-on-click-of-home-page-url-in-browser