Neo4j新手搭建本地因果集群遇Browser查询转圈问题求助

Hey there! It's super frustrating when the Neo4j Browser gets stuck loading nonstop during write operations, especially when :sysinfo shows your cluster looks healthy and cypher-shell works perfectly. Let’s walk through the most likely causes and fixes to get you back on track:

1. You’re connected to a read-only secondary node #

Causal clusters only let write operations happen on primary (core) nodes. If you’re accessing a secondary node via its browser port, the write request tries to route to the primary—but misconfigurations can make this routing hang indefinitely.

• Fix:
  • Run :sysinfo in the browser to spot which node is marked as primary.
  • Directly access that primary node’s browser port (e.g., localhost:7474 if it’s the primary) and retry creating nodes.
  • Double-check your neo4j.conf files to ensure secondary nodes are set up to properly forward write requests to the primary.

2. WebSocket issues with older Firefox #

CentOS 6.6 usually comes with an older Firefox version that has spotty WebSocket support. Neo4j Browser relies on WebSockets for real-time communication with the database, and a broken WebSocket connection will cause write operations to freeze.

• Fix:
  • Upgrade Firefox to a newer compatible version, or test with Chrome (it tends to have more reliable WebSocket support for older operating systems).
  • Verify your CentOS firewall (iptables) allows traffic on the Bolt port (7687) for all cluster nodes. You can temporarily open it with:

    iptables -A INPUT -p tcp --dport 7687 -j ACCEPT
    iptables -A OUTPUT -p tcp --dport 7687 -j ACCEPT
    

  • Check SELinux status with sestatus—if it’s enforcing, temporarily disable it with setenforce 0 to test. If the issue goes away, add a permanent SELinux rule to allow Neo4j’s network traffic.

3. Cluster transaction synchronization misconfiguration #

Even if cypher-shell works, the Browser’s transaction handling might hit snags if your cluster sync settings are off.

• Fix:
  • Inspect each node’s neo4j.conf for correct causal cluster settings:
    • Make sure dbms.mode=CORE is set for all core nodes.
    • Verify causal_clustering.minimum_core_cluster_size_at_formation=3 (for a 3-node cluster) and causal_clustering.minimum_core_cluster_size_at_runtime=2 are configured properly.
    • Confirm causal_clustering.discovery_listen_address, causal_clustering.transaction_listen_address, and causal_clustering.raft_listen_address are correctly set and reachable between all nodes.
  • Check the Neo4j log files (data/logs/neo4j.log) for errors related to transaction sync, raft consensus, or node connectivity—these logs will almost always point you to the root issue.

4. Browser cache or stale session #

Sometimes leftover cache or session data can cause weird connection glitches when switching between cluster nodes.

• Fix:
  • Clear your browser’s cache and cookies, or open a private/incognito window to access the primary node’s browser interface.
  • Disconnect the current browser session (click the "Disconnect" button in the top-right) and re-login to the primary node.

内容的提问来源于stack exchange，提问作者Newbie