💡 Preface: The original intention of technical selection
Today, when microservices are prevalent and container deployment is gradually becoming normalized,"Dynamic Reverse Proxy"It seems particularly important.
Traefik once became my first choice with its "advanced features" such as Docker support, automatic routing generation, integration of Let's Encrypt automatic certificates, and Dashboard visualization.
I was looking forward to it and wanted to use it in a small project in a production environment. But who would have thought that this journey made me doubt life for a time.
⚡ First meet Traefik: Everything is beautiful
Traefik is a modern, high-performance reverse proxy and load balancer designed for cloud-native architectures. It naturally supports mainstream service discovery mechanisms such as Docker, Kubernetes, Consul, and Etcd, which can automatically identify changes in back-end services and dynamically update routing rules. Compared with traditional Nginx or Apache, Traefik pays more attention to automation and simplicity of configuration. Its declarative configuration and Dashboard visual interface greatly simplify the deployment and maintenance process of reverse proxy. Whether it is automatically issuing SSL certificates, supporting HTTP/2, WebSocket, or built-in middleware system, Traefik demonstrates the elegance and power of the next generation of gateways with the concept of "less is more".
It's really elegant to configure:
- 🧠 Automatically identify Docker service, no need for cumbersome manual configuration
- 🔐 Automatic HTTPS, one line of configuration can be used to access Let's Encrypt
- 📈 comes with a Dashboard to see the routing and service status at a glance
- 🔄 Natively support hot updates, zero restart state loading configuration
I once sighed:“Isn’t this the ideal form of reverse proxy?”
Deploy traefik services
This scenario is used in intranet services, and https is not required, so you can only map port 80.
services:
traefik:
image: traefik:latest
container_name: traefik
restart: always
Ports:
- "80:80"
- "8080:8080" # Traefik dashboard port (optional)
Command:
- "--=true" # Enable Dashboard
- "--"
Volumes:
- /var/run/:/var/run/:ro
networks:
default:
name: traefik
driver: bridgeService access traefik
The service to be accessed this time is a springboot application, and other unrelated containers are omitted below.
services:
app:
build: .
container_name: hub_project
environment:
- SPRING_PROFILES_ACTIVE=prod
depends_on:
- redis
ports:
- 13080:13080
networks:
- default
- traefik
labels:
- "=Host()"
- "=13080"
networks:
default:
name: hub_project
traefik:
external: true
You can see that the access is very simple, you only need to add one to the service.labelsConfiguration
Just specify the domain name and port in it.
🧱 The reality is skinny: the price of dynamics is complexity
From one day, my service visit suddenly returned404, I can't figure it out. Later, after investigation, I found that:
🔍 Another container reuses the same routers and services names, resulting in a conflict!
After correction, it returned to normal, and soon it appeared againGateway Timeout——This time, the backend service only monitors127.0.0.1, Traefik can't connect at all. Later, I didn't rejoin it after a certain restarttraefikInternet, Traefik cannot catch the service.
These questions made me realize:
| question | reason |
|---|---|
| 404 Not Found | label conflict, service not loading, network not joined |
| 504 Gateway Timeout | Backend monitoring127.0.0.1Instead0.0.0.0
|
| The route disappears | The container is not joined to the traefik network or the Docker event is not triggered |
| Exception after restart | Traefik does not perceive changes in time or the status is not refreshed |
🌀 Nothing is Traefik's fault, but it'sToo easy to get into a trap。
🔧 Why is this happening? Traefik's "dynamic design" is a double-edged sword
The core philosophy of Traefik is:
“You are responsible for labels, and I will be the automatic agent.”
Although this greatly reduces the amount of configuration, it also brings several uncontrollable factors:
- Container roomNetwork isolationMust be configured correctly
- Each service/router'sName cannot be repeated
- The application must listen to the correct address (
0.0.0.0) Only Traefik can access it - Container status, restart, and network changes may cause Traefik to "cannot catch the service"
In addition, Traefik itself does not cache state, everything is loaded dynamically.debug became metaphysics: serving everything is normal, but access is timeout/404.
😮💨 It’s not easy to say that loving you: My heart is tired for a moment
- The configuration has been changed but the Dashboard has not changed, so I can only restart the container repeatedly
- The service can curl, but Traefik cannot access it, but the listening address is wrong
- The dashboard clearly shows that the router is activated, but the front-end is loading
- Configure label forgot to add
.entrypoints=web, debug for half an hour
Every investigation is like a practice. I even doubt: Did I do something wrong?
🍃 Final switch: Caddy, although simple but more secure
Just when I was tortured to almost give up, I decided to give it a try.
Its configuration is surprisingly simple:
{
reverse_proxy hub_project:13080
}
- ✅ Automatic HTTPS painless access
- ✅ No label No network configuration
- ✅ Determinism and controllability brought by static configuration
- ✅ debug is simpler, configuration is the truth
Although the subsequent scalability is slightly poor,It's perfect for a lightweight project like me.
✅ Summary: Traefik is worthy of respect, but not necessarily suitable for everyone
Traefik is a double-edged sword. It's perfect for:
- Kubernetes environment
- Docker Compose Teamwork project with high service complexity and frequent changes
- DevOps team familiar with Docker network model and service health status
And for a light deployer with small projects like me + Docker Compose:
❝ Static reverse proxy + explicit configuration, it is a kind of relaxation. ❞
If Nginx is a steady and good-looking guy, Traefik is like a maverick geek. It does not play according to common sense, rejects cumbersome configuration files, claims that "automatic discovery, everything is automatic". It can be equipped with a reverse proxy with Docker label. Doesn't it sound very elegant? But when you really pull it up, you find that the container is clearly online and the Dashboard is displayed normally, but the page is 404, and the SSL certificate application is not moving at all. If you restart it, it will suddenly get better, looking like "I'm fine, you don't understand me." Traefik is sometimes like a cold lover, with strong functions and high looks, but it is always tiring to communicate. The process of using it is either debugging the configuration or obtaining "metaphysical repair" during restarting, which makes people sigh: Traefik, it is not easy to say that loving you.
✍️ Postscript: Don’t reject, see each other again
I still have a respect for Traefik, which has so many great design ideas, but this time I chose to put it down first.
Maybe in the future,In a more mature CI/CD pipeline, or Kubernetes, I'll reselect it.