Can not change HTTPS to HTTP on Nginx
I have a web server running by nginx. I registered a free domain name .tk
and installed Let's Encrypt certificate. The following configuration is my HTTPS:
if ($ssl_protocol = "") {
rewrite ^ https://$server_name$request_uri? permanent;
}
But now I remove all of HTTPS configuration in Nginx then it can not access to http://mysite.tk. I also clear cache on browser but it does not work.
Update
My nginx.conf
#user nobody;
worker_processes 4;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
pid logs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
keepalive_timeout 65;
gzip on;
server {
listen 80;
# listen 443 ssl;
server_name xxx.tk;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
# TLS configurations
# ssl_certificate /etc/letsencrypt/live/xxx.tk/fullchain.pem;
# ssl_certificate_key /etc/letsencrypt/live/xxx.tk/privkey.pem;
# ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# ssl_prefer_server_ciphers on;
# ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4";
# add_header Strict-Transport-Security max-age=15768000;
# if ($ssl_protocol = "") {
# rewrite ^ https://$server_name$request_uri? permanent;
# }
location / {
index index.php index.html index.htm;
}
location /files {
autoindex on;
}
location ~ .php$ {
root /home/tester/local/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
}
From comments:
I restarted daemon after modifying configuration.
Nginx is also listening on port 80, confirmed with:
netstat -pltun
I cleaned everything on my browser. But it still does not work.
nginx http https
add a comment |
I have a web server running by nginx. I registered a free domain name .tk
and installed Let's Encrypt certificate. The following configuration is my HTTPS:
if ($ssl_protocol = "") {
rewrite ^ https://$server_name$request_uri? permanent;
}
But now I remove all of HTTPS configuration in Nginx then it can not access to http://mysite.tk. I also clear cache on browser but it does not work.
Update
My nginx.conf
#user nobody;
worker_processes 4;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
pid logs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
keepalive_timeout 65;
gzip on;
server {
listen 80;
# listen 443 ssl;
server_name xxx.tk;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
# TLS configurations
# ssl_certificate /etc/letsencrypt/live/xxx.tk/fullchain.pem;
# ssl_certificate_key /etc/letsencrypt/live/xxx.tk/privkey.pem;
# ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# ssl_prefer_server_ciphers on;
# ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4";
# add_header Strict-Transport-Security max-age=15768000;
# if ($ssl_protocol = "") {
# rewrite ^ https://$server_name$request_uri? permanent;
# }
location / {
index index.php index.html index.htm;
}
location /files {
autoindex on;
}
location ~ .php$ {
root /home/tester/local/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
}
From comments:
I restarted daemon after modifying configuration.
Nginx is also listening on port 80, confirmed with:
netstat -pltun
I cleaned everything on my browser. But it still does not work.
nginx http https
add a comment |
I have a web server running by nginx. I registered a free domain name .tk
and installed Let's Encrypt certificate. The following configuration is my HTTPS:
if ($ssl_protocol = "") {
rewrite ^ https://$server_name$request_uri? permanent;
}
But now I remove all of HTTPS configuration in Nginx then it can not access to http://mysite.tk. I also clear cache on browser but it does not work.
Update
My nginx.conf
#user nobody;
worker_processes 4;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
pid logs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
keepalive_timeout 65;
gzip on;
server {
listen 80;
# listen 443 ssl;
server_name xxx.tk;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
# TLS configurations
# ssl_certificate /etc/letsencrypt/live/xxx.tk/fullchain.pem;
# ssl_certificate_key /etc/letsencrypt/live/xxx.tk/privkey.pem;
# ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# ssl_prefer_server_ciphers on;
# ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4";
# add_header Strict-Transport-Security max-age=15768000;
# if ($ssl_protocol = "") {
# rewrite ^ https://$server_name$request_uri? permanent;
# }
location / {
index index.php index.html index.htm;
}
location /files {
autoindex on;
}
location ~ .php$ {
root /home/tester/local/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
}
From comments:
I restarted daemon after modifying configuration.
Nginx is also listening on port 80, confirmed with:
netstat -pltun
I cleaned everything on my browser. But it still does not work.
nginx http https
I have a web server running by nginx. I registered a free domain name .tk
and installed Let's Encrypt certificate. The following configuration is my HTTPS:
if ($ssl_protocol = "") {
rewrite ^ https://$server_name$request_uri? permanent;
}
But now I remove all of HTTPS configuration in Nginx then it can not access to http://mysite.tk. I also clear cache on browser but it does not work.
Update
My nginx.conf
#user nobody;
worker_processes 4;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
pid logs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
keepalive_timeout 65;
gzip on;
server {
listen 80;
# listen 443 ssl;
server_name xxx.tk;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
# TLS configurations
# ssl_certificate /etc/letsencrypt/live/xxx.tk/fullchain.pem;
# ssl_certificate_key /etc/letsencrypt/live/xxx.tk/privkey.pem;
# ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# ssl_prefer_server_ciphers on;
# ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4";
# add_header Strict-Transport-Security max-age=15768000;
# if ($ssl_protocol = "") {
# rewrite ^ https://$server_name$request_uri? permanent;
# }
location / {
index index.php index.html index.htm;
}
location /files {
autoindex on;
}
location ~ .php$ {
root /home/tester/local/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
}
From comments:
I restarted daemon after modifying configuration.
Nginx is also listening on port 80, confirmed with:
netstat -pltun
I cleaned everything on my browser. But it still does not work.
nginx http https
nginx http https
edited 1 min ago
Rui F Ribeiro
40.1k1479136
40.1k1479136
asked May 10 '16 at 9:59
K.LotusK.Lotus
4616
4616
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
The most probable cause for inability to reverse HTTPS back to HTTP is the following line:
# add_header Strict-Transport-Security max-age=15768000;
Now, it is commented out, but it is probable you have tested it.
Your mistake, though, because every HSTS guide should tell you, that you shall increase the time value as per your confidence in being able to deliver the domain on HTTPS.
add a comment |
Browsers often cache http 301, http://getluky.net/2010/12/14/301-redirects-cannot-be-undon/ is a good read.
Does it work in a browser that you haven't used before on the site?
Also open your browser dev tools to see if it's still receiving the redirect after you clear your cache
add a comment |
It's helpful to remember first that if is evil.
Also, any incoming https requests will go to port 443 by default. Incoming requests will normally be talking ssl as well, so you may want to turn this off for the rewrite. Rather than using if, a block like this will point everything at your http listener:
server {
listen 443;
server_name _;
ssl off;
rewrite ^ http://$server_name$request_uri?$args permanent;
}
Best practice is to have your http and https servers separately defined— one per port you're listening on. It makes troubleshooting much easier, and will give you fewer headaches down the road.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f282209%2fcan-not-change-https-to-http-on-nginx%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
The most probable cause for inability to reverse HTTPS back to HTTP is the following line:
# add_header Strict-Transport-Security max-age=15768000;
Now, it is commented out, but it is probable you have tested it.
Your mistake, though, because every HSTS guide should tell you, that you shall increase the time value as per your confidence in being able to deliver the domain on HTTPS.
add a comment |
The most probable cause for inability to reverse HTTPS back to HTTP is the following line:
# add_header Strict-Transport-Security max-age=15768000;
Now, it is commented out, but it is probable you have tested it.
Your mistake, though, because every HSTS guide should tell you, that you shall increase the time value as per your confidence in being able to deliver the domain on HTTPS.
add a comment |
The most probable cause for inability to reverse HTTPS back to HTTP is the following line:
# add_header Strict-Transport-Security max-age=15768000;
Now, it is commented out, but it is probable you have tested it.
Your mistake, though, because every HSTS guide should tell you, that you shall increase the time value as per your confidence in being able to deliver the domain on HTTPS.
The most probable cause for inability to reverse HTTPS back to HTTP is the following line:
# add_header Strict-Transport-Security max-age=15768000;
Now, it is commented out, but it is probable you have tested it.
Your mistake, though, because every HSTS guide should tell you, that you shall increase the time value as per your confidence in being able to deliver the domain on HTTPS.
answered Jul 18 '18 at 21:27
VlastimilVlastimil
8,0661464138
8,0661464138
add a comment |
add a comment |
Browsers often cache http 301, http://getluky.net/2010/12/14/301-redirects-cannot-be-undon/ is a good read.
Does it work in a browser that you haven't used before on the site?
Also open your browser dev tools to see if it's still receiving the redirect after you clear your cache
add a comment |
Browsers often cache http 301, http://getluky.net/2010/12/14/301-redirects-cannot-be-undon/ is a good read.
Does it work in a browser that you haven't used before on the site?
Also open your browser dev tools to see if it's still receiving the redirect after you clear your cache
add a comment |
Browsers often cache http 301, http://getluky.net/2010/12/14/301-redirects-cannot-be-undon/ is a good read.
Does it work in a browser that you haven't used before on the site?
Also open your browser dev tools to see if it's still receiving the redirect after you clear your cache
Browsers often cache http 301, http://getluky.net/2010/12/14/301-redirects-cannot-be-undon/ is a good read.
Does it work in a browser that you haven't used before on the site?
Also open your browser dev tools to see if it's still receiving the redirect after you clear your cache
answered May 10 '16 at 10:07
theblazehentheblazehen
991
991
add a comment |
add a comment |
It's helpful to remember first that if is evil.
Also, any incoming https requests will go to port 443 by default. Incoming requests will normally be talking ssl as well, so you may want to turn this off for the rewrite. Rather than using if, a block like this will point everything at your http listener:
server {
listen 443;
server_name _;
ssl off;
rewrite ^ http://$server_name$request_uri?$args permanent;
}
Best practice is to have your http and https servers separately defined— one per port you're listening on. It makes troubleshooting much easier, and will give you fewer headaches down the road.
add a comment |
It's helpful to remember first that if is evil.
Also, any incoming https requests will go to port 443 by default. Incoming requests will normally be talking ssl as well, so you may want to turn this off for the rewrite. Rather than using if, a block like this will point everything at your http listener:
server {
listen 443;
server_name _;
ssl off;
rewrite ^ http://$server_name$request_uri?$args permanent;
}
Best practice is to have your http and https servers separately defined— one per port you're listening on. It makes troubleshooting much easier, and will give you fewer headaches down the road.
add a comment |
It's helpful to remember first that if is evil.
Also, any incoming https requests will go to port 443 by default. Incoming requests will normally be talking ssl as well, so you may want to turn this off for the rewrite. Rather than using if, a block like this will point everything at your http listener:
server {
listen 443;
server_name _;
ssl off;
rewrite ^ http://$server_name$request_uri?$args permanent;
}
Best practice is to have your http and https servers separately defined— one per port you're listening on. It makes troubleshooting much easier, and will give you fewer headaches down the road.
It's helpful to remember first that if is evil.
Also, any incoming https requests will go to port 443 by default. Incoming requests will normally be talking ssl as well, so you may want to turn this off for the rewrite. Rather than using if, a block like this will point everything at your http listener:
server {
listen 443;
server_name _;
ssl off;
rewrite ^ http://$server_name$request_uri?$args permanent;
}
Best practice is to have your http and https servers separately defined— one per port you're listening on. It makes troubleshooting much easier, and will give you fewer headaches down the road.
answered May 19 '16 at 13:09
RyderRyder
27618
27618
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f282209%2fcan-not-change-https-to-http-on-nginx%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown