阿里云igate使用教程

阿里云iGate不是阿里网关硬件，而是使用一套跑在ECS上的反向代理方案。我第一次接触它是教程在一个混合云项目里——客户内网有十几台老旧Windows Server，不想装Agent，阿里又必须通过阿里云SLB暴露HTTP服务。使用iGate就是教程在那时候被翻出来的。

它本质是阿里一个轻量级Nginx封装，但配置方式跟原生Nginx差别不小。使用阿里云给它的教程定位是“智能接入网关”的软件版，实际用下来更像一个带健康检查和动态路由的阿里反向代理。安装很简单，使用一条命令：

wget https://igate-release.oss-cn-hangzhou.aliyuncs.com/install.sh bash install.sh --mode=server

装完默认监听8080端口，教程管理界面在http://ip:8080/igate。阿里默认账号admin，使用密码是教程实例ID后六位。这个设计挺坑——如果你用的是自定义镜像或者改了实例ID，密码就得去/usr/local/igate/conf/auth.conf里翻。

配置路由比想象中麻烦

iGate的路由规则不是写在配置文件里的，得通过管理界面或者API提交。我试过直接改routes.json，重启服务后配置被覆盖了。正确做法是用igate-cli：

igate-cli route add --name=web1 --domain=test.example.com --upstream=192.168.1.10:80 --health=/status

健康检查路径必须返回200，否则iGate会直接把后端摘掉。有个细节：如果后端是HTTPS，upstream要写成https://192.168.1.10:443，但iGate默认不校验证书。想开启校验得在global.conf里加ssl_verify=on，然后重启。重启命令是systemctl restart igate，不是service igate restart，后者会报错。

日志和排错

访问日志在/var/log/igate/access.log，格式跟Nginx的combined差不多，但多了个upstream_status字段。有次客户反馈502，我看日志发现upstream_status是“-”，说明请求根本没到后端。查了半天是安全组没放行iGate到后端的端口。iGate本身不报这个错，只在管理界面的“后端健康”里标红。

错误日志更直接：/var/log/igate/error.log。常见错误是no live upstreams，意思是所有后端都被健康检查判死了。这时候要么改健康检查路径，要么把检查间隔调长。默认间隔是5秒，超时3秒，连续失败2次就摘。对老旧服务来说太激进，我一般改成10秒间隔、5秒超时、失败3次再摘。

性能上的坑

iGate默认worker进程数是CPU核数，但连接数限制是1024。如果并发高，得改/usr/local/igate/conf/nginx.conf里的worker_connections。改完别急着重启，先igate-cli config test，通过后再systemctl reload igate。reload不会断连接，restart会。

还有个隐藏问题：iGate的会话保持是基于cookie的，但cookie名固定为IGATE_SESSION。如果后端应用自己也用了同名cookie，会冲突。解决办法是在路由配置里加--session-cookie=CustomName。这个参数文档里没写，我是抓包看出来的。

到底适不适合你

如果你只需要简单的HTTP反向代理，且后端不超过20个，iGate够用。但要是需要WebSocket、gRPC或者动态服务发现，别折腾了，直接上Nginx Plus或者Traefik。iGate的WebSocket支持是半残的——需要手动在路由里加--websocket=true，而且超时时间固定60秒，改不了。

我最后一次用iGate是去年双十一前，帮客户扛住了峰值8000 QPS。没出大问题，但管理界面卡得没法看。后来换成了MSE云原生网关。iGate还在维护，但更新频率明显慢了。如果你现在要选，建议先跑个POC，重点测健康检查的灵敏度和日志的完整性。