☰

关联弹性 IP 后，Amazon EC2 实例重定向到旧的公共 DNS

tag-icon • tag-icon amazon-ec2 redirect amazon-elastic-ip
关联弹性 IP 后，Amazon EC2 实例重定向到旧的公共 DNS

我有一个 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 重定向到了之前的域名。为了修复它，我必须：

  1. 更新数据库表中的PS_SHOP_DOMAIN内容PS_SHOP_DOMAIN_SSLps_configuration
  2. 更新ps_shop_url表格

相关内容