![关联弹性 IP 后,Amazon EC2 实例重定向到旧的公共 DNS](https://linux22.com/image/698706/%E5%85%B3%E8%81%94%E5%BC%B9%E6%80%A7%20IP%20%E5%90%8E%EF%BC%8CAmazon%20EC2%20%E5%AE%9E%E4%BE%8B%E9%87%8D%E5%AE%9A%E5%90%91%E5%88%B0%E6%97%A7%E7%9A%84%E5%85%AC%E5%85%B1%20DNS.png)
我有一个 EC2 实例,它运行良好。昨天,我创建了一个新的 Elastic IP 并将其与这个工作实例关联。
现在,如果我在浏览器中输入 Elastic ip 地址,它会重定向到原始公共 DNS,而它并未与弹性 ip 关联。
如果我从实例本身 curl 我的站点,我会得到以下信息:
* Rebuilt URL to: 127.0.0.1/
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 302 Found
< Server: nginx/1.10.0 (Ubuntu)
< Date: Mon, 13 Feb 2017 08:27:44 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Location: http://ec2-35-165-45-84.us-west-2.compute.amazonaws.com/ (This is wrong!)
我在我的网站上使用 NGINX,这是我的配置文件:
server {
listen 80 default_server;
listen [::]:80 default_server;
# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
#root /var/www/html;
root /usr/share/nginx/html/prestashop;
# Add index.php to the list if you are using PHP
index index.html index.php index.htm index.nginx-debian.html;
server_name _;
# Logs
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
location = /robots.txt {
auth_basic off;
allow all;
log_not_found off;
access_log off;
}
# Gzip Settings
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 1;
gzip_buffers 16 8k;
gzip_http_version 1.0;
gzip_types application/json text/css application/javascript;
rewrite ^/api/?(.*)$ /webservice/dispatcher.php?url=$1 last;
rewrite ^/([0-9])(-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+.jpg$ /img/p/$1/$1$2$3.jpg last;
rewrite ^/([0-9])([0-9])(-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+.jpg$ /img/p/$1/$2/$1$2$3$4.jpg last;
rewrite ^/([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+.jpg$ /img/p/$1/$2/$3/$1$2$3$4$5.jpg last;
rewrite ^/([0-9])([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+.jpg$ /img/p/$1/$2/$3/$4/$1$2$3$4$5$6.jpg last;
rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+.jpg$ /img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6$7.jpg last;
rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7$8.jpg last;
rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8$9.jpg last;
rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$7/$8/$1$2$3$4$5$6$7$8$9$10.jpg last;
rewrite ^/c/([0-9]+)(-[.*_a-zA-Z0-9-]*)(-[0-9]+)?/.+.jpg$ /img/c/$1$2$3.jpg last;
rewrite ^/c/([a-zA-Z_-]+)(-[0-9]+)?/.+.jpg$ /img/c/$1$2.jpg last;
rewrite ^/images_ie/?([^/]+).(jpe?g|png|gif)$ /js/jquery/plugins/fancybox/images/$1.$2 last;
rewrite ^/order$ /index.php?controller=order last;
# Admin URL
location /admin-dev/ { #Change this to your admin folder
if (!-e $request_filename) {
rewrite ^/.*$ /admin-dev/index.php last; #Change this to your admin folder
}
}
location / {
if (!-e $request_filename) {
rewrite ^/.*$ /index.php last;
}
}
# location / {
# # First attempt to serve request as file, then
# # as directory, then fall back to displaying a 404.
# try_files $uri $uri/ =404;
# }
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
location ~ \.php$ {
include snippets/fastcgi-php.conf;
# With php7.0-cgi alone:
# fastcgi_pass 127.0.0.1:9000;
# With php7.0-fpm:
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}
client_max_body_size 10M;
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}
答案1
这可能是因为数据库缓存了 URL 名称。
只需几个 SQL 命令即可轻松解决此问题。您的三个表需要更改:
wp_options,wp_posts和wp_postmeta
UPDATE wp_options SET option_value = replace(option_value, 'http://www.oldurl', 'http://www.newurl') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET guid = replace(guid, 'http://www.oldurl','http://www.newurl');
UPDATE wp_posts SET post_content = replace(post_content, 'http://www.oldurl', 'http://www.newurl');
UPDATE wp_postmeta SET meta_value = replace(meta_value,'http://www.oldurl','http://www.newurl');
参考:https://wpbeaches.com/updating-wordpress-mysql-database-after-moving-to-a-new-url/
希望这可以帮助。
和平。
答案2
我终于搞明白了。原来 Prestashop 重定向到了之前的域名。为了修复它,我必须:
- 更新数据库表中的
PS_SHOP_DOMAIN
内容PS_SHOP_DOMAIN_SSL
ps_configuration
- 更新
ps_shop_url
表格