1、這是因為在eureka server的實現中存在一個web請求過濾器，其url模式就是【/eureka/*】。注意這不並是過濾應用的上下文路徑，而是過濾剩下的請求路徑，所以即使將【server.context-path】設置為【/eureka】，各個節點之間還是無法連通，只有將defaultZone設置為【http://eureka00.com/eureka/eureka】才行。
2、eureka集群的各個節點是通過一系列接口進行通信的。
3、但【spring-cloud-netflix-eureka-server】包中存在下圖的【spring.factories】文件，根據SpringBoot加載規則，在應用啟動時會加載配置類【EurekaServerAutoConfiguration】。
4、在該配置類中先通過方法【jerseyApplication】收集被【Path】和【Provider】注釋的資源類，然后在方法【jerseyFilterRegistration】中將資源類放入到過濾器【ServletContainer】中，再生成一個包含【徑濾過濾】的注冊類【FilterRegistrationBean】，隨后SpringBoot會將該過濾器加入對web請求的過濾器鏈中。
5、該過濾器的url過濾模式為常量【DEFAULT_PREFIX】即“/eureka”。
6、SpringBoot執行配置過濾器注冊Bean。
7、tomcat將其加入到自己上下文過濾器集合中。
8、tomcat在處理請求是將通過方法【createFilterChain】建立過濾器鏈，對於不符合url模式的請求將跳過前面提到的包含接口資源類的過濾器容器【ServletContainer】。
9、在tomcat過濾器鏈【ApplicationFilterChain】的方法【internalDoFilter】中，對於非/eureka請求，比如/eureka1/apps請求，由於沒有沒有匹配其url模式的接口資源類，所以被當做普通靜態資源的請求，由於也沒有對應的資源，所以返回【404】錯誤。
10、關於tomcat的過濾器鏈。
由於采取了某種設計模式，將由總鏈【ApplicationFilterChain】開始執行各個子過濾器，由於子過濾器持有對總鏈的引用，所以子過濾器執行完畢后，繼續執行后續的子過濾器。當總鏈上的所有子過濾器都執行完畢后，將會執行【servlet instance】的方法【service】，即作為靜態資源請求處理。但如果子過濾器執行完畢后不再調用總鏈的方法【doFilter】，則總鏈的子過濾器調用將中斷，也意味着總鏈的調用完成。
11、關於接口資源類的過濾器容器【ServletContainer】。
在執行該容器的過濾方法【doFilter】時，如果它配置了靜態資源的url模式且當前請求正好符合，則通過方法【chain.doFilter】繼續回到總鏈執行后續子過濾器。
當請求不符合靜態資源的url模式模式時，將通過方法【service】找到請求路徑在接口資源類中對應的方法並執行，執行完成后將不再執行總鏈的【doFilter】方法即終止執行總鏈的后續子過濾器。如果在接口資源類中未找到對應的方法，則返回的【status】為404，如果【forwardOn404】為true則還需要繼續執行總鏈的【chain.doFilter】方法。
